Про comprehension debt

На прошлой неделе в посте про оргдизайн я вспоминал замечательную книгу Team Topologies. Одна из мыслей, которые мне очень запали в душу – это то, что зону ответственности команды надо проектировать с учетом ее ограниченной когнитивной емкости, а не просто закидывать в нее ответственность за все рядом лежащие компоненты.

Когнитивная емкость – это способность команды переварить когнитивную нагрузку. К такой нагрузке относится все, что команда должна понимать, чтобы самостоятельно безопасно обслуживать и менять свой продукт: бизнесовые правила, доменный язык, архитектура, устройство инфраструктуры и пайплайнов, интеграции с другими сервисами, особенности пользователей.

Когнитивная нагрузка появляется от двух видов сложности:

👉Intrinsic, неотъемлимая сложность предметной области. Как код ни упрощай, биллинг всегда будет сложным.
👉Extraneous, случайная сложность. Плохо организованный ручной пайплайн деплоя, много разных форматов конфигурации, лишние слои абстракции.

Так вот, агентская разработка, при всем ее великолепии, очень сильно влияет на когнитивную нагрузку. Во-первых, очень просто резко вырастить случайную сложность. Агенты любят оверинжинирить, писать обработчики для тридцати эдж кейсов, и городить те самые слои абстракций. Если не выстраивать правильную инженерную дисциплину, то уже этого хватит, чтобы когнитивная емкость переполнилась.

Во-вторых, разработка фичей ускоряется, и у эффективных менеджеров появляется соблазн закинуть в зону ответственности каждой команды побольше всего, или, наоборот, оставить зону ответственности такой же, а количество голов, думающих над ней, сократить. И тогда даже без учета выросшей случайной сложности, даже неотъемлимая сложность перестает помещаться в головах.

Так мы и получаем comprehension debt – головы разработчиков уже перегружены, их емкости не хватает, чтобы вместить туда что-то новое, и знание о том, как работает продукт, постепенно ускользает. Спустя короткое время, команда уже не может безопасно менять свою систему – количество инцидентов растет, а способность их предсказать падает.

С таким долгом можно бороться инструментальными способами, упрощая для человека понимание того, как работает система – ну условно показывать простые диаграммы вместо полотен кода. Но важно помнить, что, как информацию не сжимай, количество концепций, которые мы в голове можем держать – ограничено. И лучшее, что вы, как менеджер, можете в такой ситуации сделать – это удерживать количество компонентов, за которые отвечает команда, в пределах ее когнитивной емкости.

Еще про comprehension debt хорошо пишет у себя в канале Владимир Балун. Он руководил разработкой системы трейсинга с трафиком 11GB/s в Яндексе, поэтому набил руку на сложных системах, и знает, о чем говорит. Поэтому можете почитать его пост, а заодно подписаться на его канал, где он рассказывает о своем опыте программирования, разработке сложных высоконагруженных систем и просто делится своими мыслями о разработке.

Почему автономные фабрики софта не работают

Последние полгода из каждого угла говорят про то, что вот-вот агентская разработка эволюционирует до того момента, когда людей можно будет полностью убрать из этого процесса, заменив все полностью автономными фабриками. А если у вас это не получается, то skill issue. На самом деле все немного не так.

👉Модели становятся лучше только в вопросах выполнения одной конкретной задачи, но не в том, чтобы поддерживать кодовую базу в долгую. Поэтому спустя достаточно быстрое время такого развития, проект станет неподдерживаемым ни вами, ни моделью.
👉Так происходит из-за текущих механизмов reinforcement learning – определить правильное поведение и награду на горизонте атомарных задач легко, а вот на уровень выше уже очень сложно. За плохие архитектурные решения модели никак не наказываются.

Управленческие антипаттерны, характерные для России

👉Гиперцентрализация, когда все решает один человек. Иногда вырастает до культа личности основателя, который плох с двух сторон – если такой человек уходит, компания разваливается, а если остается – то компания начинает копировать все его недостатки.
👉Отсутствие стратегии и в целом короткий горизонт планирования.
👉Кумовство – при найме предпочтение может отдаваться личным отношениям, а не реальным компетенциям.
👉Недостаточная работа с людьми, из-за чего текучка получается довольно большой, а навыки и эффективность не особо растут.
👉Непрозрачная бухгалтерия. С одной стороны, это ведет к тому, что бизнес не получится продать, как не получится и найти желающих в него инвестировать. С другой – бюрократии в таких компанияз будет поменьше.
👉Рыночная конкуренция подменяется лоббированием, из-за чего игрвоое поле становится неравным. Побеждает в итоге не тот, кто работает эффективнее, а тот, у кого лучше доступ к госзаказу или политические связи.

Что общего у рынка труда журналистов и программистов

Традиционная журналистика уже достаточно давно умерла. В 2008 году в результате финансового кризиса из прессы ушли рекламодатели, и кучу штатных журналистов уволили. Они пошли во фриланс – и обнаружили, что на пару десятков заказов в месяц отзывается десятки кандидатов в день. При этом университеты продолжали выпускать новых журналистов, профессия годы до этого была на хайпе.

Рынок работодателя сразу же создал несколько довольно знакомых нам явлений. Для начала, вокруг отбора кандидатов появилось много ритуальных бессмысленных действий. Это привело к тому, что получение заказа стало отдельным искусством, и работу стали получать не лучшие авторы, а те, кто лучше всего умел под эти требования адаптироваться. Ну и, конечно же, появились волчьи сообщества, которые учили журналистов получше продавать свои питчи и проходить гейткипинг.

Что происходило с журналистами дальше:

👉Мидлы вымерли. На рынке остались начинающие фрилансеры, работающие за копейки, и завездные опытные журналисты.
👉Выжившие ушли от гейткиперов. Самые сильные авторы перестали пытаться пробиться к редакторам в издания, и стали независимыми – открыли рассылки, сделали подкасты, сколотили собственный бренд. Гейткипер при этом, конечно, остался – но теперь это не редактор-человек, а алгоритм ленты в соцсетях.
👉Сместился дефицит. Раньше им было место в журнале, теперь – доверие читателя к конкретному имени.

Что из этого можно перенести на рынок программистов – вопрос хороший, и упирается он в то, конечен ли спрос на программистов, или нет (парадокс Джевонса и вот это все). Пока все показывает на то, что на самом деле спрос конечен – люди не начинают ставить себе больше приложений на телефон, а компании не то, чтобы успешно диверсифицировали свою продуктовую линейку и запускали кучу новых успешных продуктов.

Почему CTO сейчас стало особенно тяжело

Всю прошлую неделю в Твиттере обсуждали интересный тренд – многие CTO / VP of Engineering / Head of Development в стартапах и компаниях среднего размера сейчас жестко выгорают и увольняются, проработав буквально пару месяцев. Причины называют вот такие:

👉Роль, на которую их взяли, довольно расстрельная, с нереалистичными ожиданиями из-за AI
👉У компании нет никакой стратегии и видимого будущего с учетом изменений рынка, вызванных AI
👉В этой компании не получить так называемый AI-native опыт, который им точно в будущем для карьеры понадобится
👉Человек, на замену которого их наняли, уволился из-за тех же причин
👉Начать свой стартап сейчас в целом не очень сложно, деньгами в хороших инженерных лидов готовы кидать
👉СЕО словил AI психоз, перешел в founder mode, и работать стало невозможно

Ну а вообще вакансии для инженерных руководителей сейчас как будто бы разделились на два типа:

1️⃣Наша компания умирает из-за AI, пожалуйста, спасите нас и сделайте AI трансформацию разработки. Все сильные люди уволились. Никого нового сильного нанять вы не сможете. Платить мы вам сможем примерно как стафф-инженеру в бигтехе. Но вот если все поправите, получите премию!
2️⃣У нас переоцененный AI стартап, пожалуйста, помогите нам начать делать настоящие AI штуки. У нас никогда не было технического лида, только 25 летний кофаундер, который разобрался с консолью AWS. Платить мы вам сможем примерно как стафф-инженеру в бигтехе. Но вот если все поправите, получите премию!

Короче, цитаты твита и реплаи там прямо золото, рекомендую почитать!

Огромная библиотека постмортемов

Кто-то собрал на одном сайте гигантскую подборку из 650 постмортемов от разных компаний. Использовать можно и для того, чтобы посмотреть, как деградируют ваши любимые сервисы, и для того, чтобы вдохновиться форматом и процессами.

Не понимать кодовую базу – нормально

Один из стандартных набросов на LLM – это то, что разработчики, слишком сильно полагающиеся на агентов, довольно быстро теряют понимание кодовой базы проекта. Но если задуматься – а насколько это понимание было и раньше, когда код писали руками? А если подумать не про сравнительно компактные кодовые базы, а огромные энтерпрайзные проекты?

Планируя изменение программы, мы всегда оперируем своей собственной теорией о том, как она работает. В больших кодобазах эта теория всегда будет неверной или неполной – просто невозможно все детали удержать в голове. Поэтому в любом случае нужно уметь работать в таких условиях – сжимать зубы, выдвигать гипотезы о том, как программа работает, проверять их, и обновлять свою теорию.

AI, конечно, усложняет поддержку теории об устройстве программы в собственной голове. Но, с другой стороны, он помогает гораздо быстрее поднимать контекст про незнакомые или забытые части системы, и очень быстро тестировать свои гипотезы – поэтому прямо однозначно сказать, что AI в этой части сделал все хуже, нельзя.

Про скорость ради скорости

Задумайтесь – а насколько часто, когда вы пытались ускориться сами, или просили об этом команду, это действительно было важно? В нашей индустрии уже довольно давно стало моветоном не пытаться всеми силами оптимизировать time to market. А итоги у этого не всегда положительные:

👉Предложения замедлиться и подумать по умолчанию воспринимаются как контрпродуктивные.
👉Многие ненужные фичи делаются только потому, что их можно сделать быстро. Они дают ощущение прогресса, хотя на самом деле могут быть просто броуновским движением.

Реальная скорость происходит не от бездумной спешки, а скорее от противоположного – траты лишнего времени на то, чтобы принять нужные решения, убедиться, что задача всем понятна, и нужный контекст собран. И, что еще важнее, когда потрачено время на то, чтобы ответить на сложные неудобные вопросы вроде "а нужную ли вещь мы вообще делаем?".

Золотая статья!

Как стафф инженеру найти достойные проблемы

Большинство компаний сходятся на том, что главная черта, отличающая стаффа от сеньора – это умение самостоятельно находить самые ценные точки приложения своих усилий. Вот простой алгоритм, как можно это делать:

👉Накапливайте знания о проблемах в вашей области компетенции, на которые жалуются люди.
👉Не бросайтесь на первую проблему, которая показалась важной. Дайте им накопиться, и беритесь за то, что проявляется хотя бы несколько раз для разных команд.
👉После того, как вы выбрали кластер связанных проблем, с решением тоже не спешите. Потратьте побольше времени на то, чтобы найти наилучшую форму решения, которая сможет закрыть сразу все эти проблемы.
👉До того, как начать полноценную реализацию, потратьте еще сколько-то времени на то, чтобы сделать дешевый прототип, показать его заинтересованным людям, и перепроверить, а туда ли вообще вы копаете.

Обратите внимания на классные пересечения со вчерашней статьей – ни один из этих пунктов не сработает, если главная ценность вашей компании – скорость.

Было?

LLM вознаграждают экспертизу

Все мы используем одни и те же модели, и по умолчанию получаем одни и те же усредненные ответы. Чтобы добиться от модели действительно качественного результата, нужно знать, в какую сторону ее запушить, какие ответы принимать, за какие идеи зацепиться. А именно это и требует глубокой экспертизы в вопросе.

Например, не зная хорошо своей кодовой базы, вы не сможете оценить, насколько предложенный моделью подход дублирует что-то уже существующее. Не имея собственного опыта дизайна, будет очень сложно почувствовать, что AI предложил чрезмерно упрощенное решение.

Не будьте мясным прокси

Я нашел свое новое любимое выражение – meat proxy, которым можно называть человека, который просто бездумно копирует сообщения от AI, не вкладывая туда ни ту самую экспертизу, ни просто хоть сколько-то своего внимания.

Среди разработчиков есть свой вид митпроксинга:

👉Отправить ссылку на задачу агенту без лишних слов
👉Не читая ни спеку, ни код, отправить на ревью
👉Скопировать комментарии агенту, запушить результат

Про принцип антитезиса

Мы стали как-то очень редко вспоминать Канемана и его монументальный труд по изучению когнитивных искажений – хотя я каждый день вижу, как многие из них получают новое лицо во взаимодействиях людей и AI. Но речь не об этом.

Так вот, со знанием когнитивных искажений можно делать две вещи:

1️⃣Использовать его, чтобы выстраивать свою тактику работы с людьми. Если вы можете предсказывать, как они себя поведут, вы точно сможете использовать это себе во благо.
2️⃣Использовать его, чтобы отлавливать эти же искажения в самом себе, и пытаться переопределять свое дефолтное поведение до той степени, пока оно не станет антитезисом к названному искажению.

Вот второй путь и есть принцип антитезиса. Он важен, потому что, если вы будете вести себя не как подавляющее большинство людей вокруг, вы сможете открыть для себя возможности, им недоступные.

Самый простой пример – обучение. Большинству людей проще учиться, когда образовательный контент их активно вовлекает и развлекает. Соответственно, если вы намеренно отдаете предпочтение не развлекательному способу обучения, например, читаете длинные сложные книги, то вы сможете пройти путями, которые все остальные пропустят.

Как правильно вписаться в систему промоушнов

Держите байку из мира FAANG про то, как прийти к успеху. Следите за пальцами:

👉Промо основаны на сложности задач, скоупе, независимости и лидерстве. По внутренним правилам, нельзя промоутить людей чаще, чем раз в два года. Поэтому несколько следующих циклов после повышения бесполезны.
👉Один менеджер организовал все так, чтобы на каждом полугодовом цикле 25% его команды получали повышение. Фокус простой – они приписывали себе заслуги от всего, сделанного командой, с полного согласия остальных. Затем то де самое повторялось для следующих 25%, и так далее.
👉Из-за того, что все видели, как быстро растут люди в команде этого менеджера, к нему стояла очередь из внутренних кандидатов. Хедкаунт рос, менеджера промоутили за все заслуги вместе с ним.
👉При этом команда работала где-то на 50% своего капасити, так как сразу после промо можно было отдыхать.
👉В итоге почти вся команда получает $1М+ компенсации.

Конечно, вся история может быть выдуманной, но элементы ее точно происходят во всех крупных корпорациях.

Держите идеальный пример того, как надо отвечать на вопросы сотрудников во время All Hands.

Немного контекста – Meta Days это дополнительные выходные дни для всей компании, которые ввели во время ковида, а потом отменили. И вот время последнего All Hands у CTO спросили, вернут ли их обратно.

Как не разучиться думать

Рабочие дни инженеров превращаются из длинных периодов напряженного думания над одной конкретной проблемоц в ADHDшное переключение между пятью разными сессиями и попытки вычленить из длинных сообщений, сгенерированных AI, крупицы смысла. Так как такого слопа читать приходится много, все вырабатывают свои собственные техники того, на каких кусках этих текстов сосредоточиться, а какие просмотреть по диагонали.

Такое потребление контента приводит к тому, что мы постепенно начинаем использовать похожий подход и в других областях жизни. Зачем смотреть видео доклада целиком, когда можно пробежаться по хайлайтам? Зачем думать над какой-то бытовой задачей, если можно прочитать TL;DR ответа LLM?

Есть смысл тренировать навык медленного мышления, чтобы он не атрофировался. В статье советуют два подхода:

👉Писать эссе самостоятельно, без какой-то помощи от AI – и неважно, статьи ли это в блог, какие-то рабочие пропозалы или что-то еще. Сам факт того, что вы выражаете свои довожы в виде последовательного повествования заставляет замедлиться и хорошо подумать.
👉Читать книги с высокой плотностью информации, например качественный нон-фикшн. Удовольствия от них получаешь как будто бы на порядок больше после рабочего дня, проведенного в процеживании AI слопа.

Почему менеджерам проще работать с агентами

Один из любимых аргументов AI-скептиков, который даже в нашем канале часто появляется в комментариях – "ну как же мы можем доверять агенту без того, чтобы читать весь его код – он же может ошибиться, или сделать вообще не то". У работы с живыми людьми проблемы точно такие же. Они забывают про условия задачи, совершают ошибки, ленятся, говорят неправду. И любой начинающий менеджер преодолевает эту долину отчаяния и учится работать с недетерминированной системой:

👉Нарабатывает интуицию про каждого человека в команде – в каких задачах он компетентен, а в каких нет
👉Выстраивает цикл обратной связи с людьми, и способы оценивать прогресс на пути к цели
👉Оценивает, в какие задачи надо прям глубоко погрузиться, а в какие можно не вникать
👉Декомпозирует работу так, чтобы люди могли работать автономно
👉Периодически ломает эту инкапсуляцию, чтобы происходил обмен знаниями

Те же самые практики с небольшими исправлениями работают и с агентами. И вот не надо только рассказывать про то, что люди отвечают за результат, а AI нет – да никто точно так же за свои ошибки ничем не отвечает.

Книга Александра Орлова про конфликты в открытом доступе

Книгу Александра Орлова про конструктивные конфликты я советовал еще в далеком 2022 году. Рекомендация с тех пор не изменилась – это очень дельная книга, которая поможет вам разобраться, как жить со всех сторон рабочего конфликта. Ну а самое классное – она очень прикладная, и кейсы вытащены прямо из нашей с вами реальности.

Так вот, книгу сейчас выложили в открытый доступ, поэтому, если вы с ней еще не познакомились, максимально рекомендую!