Несколько недель назад появилась статья о том, что Twitter’s Slack и Jira упали.
С одной стороны, новость была просто еще одним примером медленно движущейся автокатастрофы, которой является Twitter в 2023 году. Но что привлекло мое внимание, так это цитата одного из оставшихся в осаде инженеров Twitter:
«После того, как все ушли, мне некому было задать вопросы, когда я застрял», — написал в Blind сотрудник, оставшийся после первого раунда увольнений. «Раньше я искал [сообщения] об ошибках в Slack и получал помощь в 99% случаев».
Что меня поразило в этой цитате, так это то, что в такой крупной компании, как Twitter, было обычным делом просто искать сообщение об ошибке в Slack, чтобы найти решение. Глядя со стороны, вы предполагаете, что в этих компаниях-гигантах коллективное знание каким-то образом фиксируется, хранится и используется ловким, изощренным способом. Оказывается, это не обязательно так.
Как человек, который создает инструмент разработчика CodeLink, чтобы помочь расширить сотрудничество между разработчиками, это небольшое открытие очаровало меня. Общее предположение состоит в том, что разработчики проверяют документацию своей компании, чтобы что-то понять, или связываются с коллегой лично, через DM или по электронной почте за советом.
То, что делал этот разработчик, было таким простым и интуитивно понятным. Просто используйте Slack, чтобы найти старые ссылки на ошибку или проблему в предыдущих чатах. Вероятно, они копируют свой журнал ошибок в поиск, а затем отправляются в прошлое, чтобы увидеть другие разговоры по конкретной проблеме или фрагменту кода.
Затем вчера, когда я забыл (я довольно забывчивый), чтобы наше расширение VSCode работало на нашем промежуточном сервере, я поймал себя на том, что делал то же самое.
Меня всегда интересовало то, как мы, как личности, действуем в грязной реальности вещей. Есть способы, которыми вещи «должны быть сделаны», но они не всегда совпадают с тем, как вещи «делаются». Есть что-то такое незаменимое человеческое в ярлыках и лайфхаках, которые мы используем, чтобы добиться цели.
В этом случае внутренняя документация Twitter может подойти, но гораздо проще искать ответы в свободном скоплении знаний, разбросанных по каналу Slack. В чатах Slack есть человеческое удобство, за которым легче следить, чем за традиционной документацией.
Вспомогательная документация: написание документов без написания документов
Сначала я подумал, что это рыхлое нагромождение знаний называется Племенные знания. По сути, Племенные знания относятся к незадокументированным знаниям. Вещи, которые мы, рабочие, носим в голове, но нигде не записываем.
Что обычно происходит, когда вещи задокументированы в «официальном, очень важном» наборе документов — о них просто забывают и игнорируют. Док-гниль начинается, потому что мы все слишком заняты, чтобы «формально» документировать наши «племенные знания». Это особенно верно, учитывая ортодоксальность Силиконовой долины в отношении разработки программного обеспечения, которую можно резюмировать как «отправлять или погибнуть».
Затем есть молчаливое знание, но неявное знание относится к знаниям, навыкам и способностям, которые человек приобретает благодаря опыту, который трудно выразить словами или иным образом передать. Так что опять "неписано".
Я говорю о том, чтобы заметить здесь что-то другое — что-то в промежуточной зоне между недокументированным «племенным/молчаливым» знанием и документированным «формальным» знанием.
Это знание, которое случайно задокументировано в разговорах в Slack, WhatsApp, электронных письмах, комментариях к PR GitHub, ваших билетах Jira или Trello и так далее. Все эти маленькие точки данных складываются в случайные задокументированные знания, все это есть в письменной форме, вам просто нужно выполнить поиск в вашем Slack или GitHub или где-то еще, чтобы найти это.
На самом деле у этого случайно задокументированного знания может быть название (пожалуйста, напишите в комментариях, если оно есть) — но пока давайте назовем его «случайная документация» (#sexynamealert🚨#patentpending #takemymoney).
Я бы сказал, что эта случайная документация, вероятно, является одной из самых ценных сведений для вашего повседневного разработчика (например, для меня!). Во-первых, она не заперта в чьих-то головах или небольшой группе людей. Во-вторых, он не полагается на то, что кто-то будет вручную обновлять каждую мелочь в официальной документации, что требует времени, рискует потерять что-то в промежутке между опытом и записью и подвержено гниению и пренебрежению документами.
Случайная документация создается немедленно (без двойной обработки) в процессе совместной работы, и она сразу же доступна через инструменты, которые мы используем каждый день (Slack/Discord/GitHub и т. д.). Это требует гораздо меньше накладных расходов, чем перескакивание и пролистывание вики компании или ридми.
Однако бесполезно то, что знания разбросаны повсюду. Поэтому вам может понадобиться выполнить поиск в Slack, перейти к старому PR, а затем просмотреть все комментарии, чтобы получить то, что вы ищете.
Иногда это может быть довольно быстро, но в других случаях это может потребовать немало археологии.
Сотрудничество и контекст: сумма составляющих
В CodeLink мы стремимся найти самый простой способ собрать воедино все невероятно богатые знания и идеи, зафиксированные в случайной документации.
Представьте себе: вы открываете фрагмент кода и сразу же в аккуратном и чистом пользовательском интерфейсе видите любую соответствующую активность Slack или Discord, комментарии VCS (GitHub, GitLab и т. д.) и обсуждение активности. Мгновенно у вас есть все эти небольшие точки контекста и совместной работы над любым фрагментом кода в одном месте. Внезапно вы окажетесь в курсе огромного количества, если не всего, мыслей, которые вошли в интересующий вас код.
Теперь, с появлением больших языковых моделей, у нас есть технические средства, чтобы начать использовать эти невероятно богатые точки сотрудничества, которые случайно возникали в течение многих лет.
Мы с нетерпением ждем следующей главы.
