Фундаментальные истины про разработку

1️⃣Код – это обуза.
2️⃣Чем больше кода, тем больше будет багов.
3️⃣Чем сложнее становится система, тем более важную роль играет ее архитектура.
4️⃣Написать поддерживаемый код гораздо сложнее, чем просто рабочий.

Ни одна из этих истин не меняется из-за того, что код теперь пишут не кожаные мешки, а AI.

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

Почему сеньоры теперь особенно ценны

В 1985 году ученый Петер Наул написал эссе "Programming as Theory Building". Его основная идея была в том, что в основе любой программы лежит не код, а теория – общая ментальная модель того, как работает система, почему она работает именно так, и как должна развиваться дальше. При этом сам код не вмещает в себя всю ментальную модель, так как значимая часть ее остается в головах архитекторов системы.

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

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

В результате кодовые базы поначалу вроде работают, но по мере роста становятся все менее согласованными. И именно поэтому индустрию спасают опытные сеньоры:

👉Они понимают ту самую ментальную модель, умеют поддерживать и упрощать ее
👉Они следят за эволюцией архитектуры
👉Они могут научиться осознанно использовать AI (хоть и не все, как показал понедельничный рисерч)
👉Они передают знания и умения новичкам

Про важные личные качества руководителя

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

Я не буду пересказывать все качества, про которые она рассказывает, остановлюсь на одном – последовательности.

Людям не нужно, чтобы ты была идеальной. Им нужно, чтобы ты была понятной. Чтобы они знали: если ты пообещала — ты сделаешь, если косяк — ты не будешь орать, а разберешься, если ты что‑то сказала — ты так и думаешь, если ты сегодня спокойна — ты не взорвешься завтра без причины. Последовательность это и есть безопасность.

Держите небольшое пятничное напоминание про то, как важно менеджеру хотя бы иногда слышать "спасибо"!

Как OpenAI работает изнутри

За последний год OpenAI вырос в три раза, с 1000 до 3000 человек. При этом количество направлений, которыми они занимаются, выросло еще сильнее – это и собственные дата-центры, и новые семейства моделей, и куча консьюмерских продуктов, и консалтинг, и куча чего еще. Инвесторских денег – море, продукты растут безумными темпами, поэтому почитать про то, как вообще устроена их рабочая культура особенно интересно!

Держите интересные хайлайты:

👉Компания работает в bottom-up режиме. У разных людей появляются идеи, они их проверяют, и, если что-то оказывается действительно классным, оно отправляется к пользователям. Понятным образом это ведет к тому, что одновременно в разных местах компании могут разрабатывать 3-4 конкурирующие друг с другом идеи.
👉Побеждают обычно те идеи, авторам которых удается заинтересовать рисерчеров. Если идея кажется им скучной или уже кем-то решенной, ничего не полетит.
👉Очень сильно ценятся продакты и research managers, как раз за то, что могут свести друг с другом много независимых команд и инициатив, и сделать что-то большего масштаба.
👉По сравнению с влиянием цены на GPU, все остальные факторы стоимости фичи практически равны нулю, поэтому в capacity management умеют все.
👉Структура команд очень гибкая, важному проекту можно за пару дней получить в помощь нужных людей из других команд.
👉Все лидеры компании очень вовлечены в R&D и делают что-то руками.
👉Технические решения принимаются не архитекторами или комитетами, а командой, которая пишет конкретный код. Поэтому в кодовой базе очень мгого дублирующих друг друга подсистем.
👉Инженерная команда росла очень быстро, все пилили фичи, поэтому с инфрой и тулингом все очень плохо – сборки долгие, все часто отваливается.

Про сомнения в себе

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

Вот типичные паттерны проявления у нас этого синдрома:

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

Эти паттерны часто накладываются друг на друга. А из-за того, что все они рождаются из-за попыток замаскировать неуверенность в себе, со временем они только усиливаются, ведь попросить о помощи сложно.

Что на самом деле умеют AI агенты

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

Как начинать работу в новой компании

1️⃣Защитите то, что уже работает

Если в вашей зоне ответственности что-то уже работает, то задача минимум – не сломать это, задача максимум – убрать какие-то заметные проблемы и сделать так, чтобы оно работало еще лучше.

2️⃣Найдите низковисящие быстрые победы

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

3️⃣Выберите big bet, за который возьметесь

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

4️⃣Займитесь доработкой стратегии

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

А вот чего стоит избегать в первые 90 дней:

❌Не обещать слишком много ранних результатов
❌Двигаться слишком быстро без выравнивания с соседями
❌Чинить то, что не сломано

LLM не подходят для психотерапии

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

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

Про три пути тимлида

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

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

1️⃣Расти вверх по менеджерской ветке

С какими сложностями предстоит столкнуться:

👉Часто на высокие менеджерские позиции компании нанимают "варягов" снаружи. Это делается с простой целью – сломать исторически сложившиеся нормы и принести новую кровь. Единственный хороший способ этому что-то противопоставить – делать свою заинтересованность в дальнейшем росте очень явной, чтобы о ней знали и ваш менеджер, и его менеджер. Ну и не пропускать любые возможности.
👉Набор нужных скиллов будет меняться. Надо понимать, насколько вы готовы к решению задач, которые будут ждать на уровень выше, и насколько вы готовы потерять те навыки, которые есть сейчас (например, близкую работу с кодом).
👉Нужно честно ответить себе на вопрос – готовы ли вы принимать все более сложные решения, влияющие на людей – увольнения, сокращения, закрытие проектов.

2️⃣Работать в режиме маятника, и раз в два-три года переходить из менеджера в разработчика и обратно

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

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

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

3️⃣Переход обратно в разработчики

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

Про нормализацию девиаций

Если проблемы не исправляются в течение какого-то времени, то люди привыкают жить с ними и они становятся новой нормой. Скорее всего, вы сталкивались с такими историями в своем опыте:

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

Давайте разбираться, почему нормализация девиаций очень опасна:

👉Оправдание существующего порядка. Люди не любят сталкиваться с дискомфортом. Признать, что система сломана – значит принять на себя часть ответственности, и поднять неудобные вопросы, за которые могут и по шапке дать. Гораздо проще защищать существующие подходы, и находить понятные оправдания им. Поэтому любая нормализация дисфункции в перспективе приведет к тому, что отыграть все назад будет в 10 раз сложнее.
👉Система выталкивает людей, не согласных с ней, и поддерживает согласных. Соответственно все те, кто открыто называл дисфункцию дисфункцией со временем уйдут, а оставаться будут как раз таки те, кто ее поддерживает. В итоге все вокруг вообще забудут о том, как может выглядеть норма.
👉Дисфункции поддерживают друг друга, и постепенно компания, в которой не принято открыто говорить о проблемах и решать их, превращается в бессмысленного и беспощадного монстра с бесконечностью митингов, пустых дэшбордов, KPI, но без явного направления движения и без лидеров, которые готовы брать на себя ответственность.

Разница между оркестрацией и лидерством

Продуктовую работу услрвно можно разбить на шесть шагов:

1️⃣Problem Discovery: выбираем, какие проблемы существуют
2️⃣Problem Selection: выравниваемся со стейкхолдерами на тему того, какие из проблем самые важные
3️⃣Solution Discovery: ищем возможные решения для выбранной проблемы
4️⃣Solution Selection: выравниваемся со стейкхолдерами про то, какой подход к решению выберем
5️⃣Execution: запиливаем решение
6️⃣Ongoing Revision: постоянно выравниваем команду и стейкхолдеров про план действий

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

Вот признаки менеджера-оркестратора:

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

Как в AWS подходят к оценке продуктивности разработки

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

Вместо этого они взяли фреймворк Cost-to-Serve (CTS), который до этого использовался Amazon, чтобы оценивать эффективность цепочки доставки физических товаров. В чем суть:

👉CTS измеряет общую стоимость доставки unit of software. Юнит – какой-то конечный результат работы, который команда считает достаточно ценным, чтобы разработать, проверить качество, доставить до пользователей и поддерживать его. Этот юнит различается для разных команд, потому что, например, регулярность релизов мобильных приложений накладывает свои ограничения.
👉CTS расчитывается как (стоимость разработки + стоимость разработческой инфры) / количество поставленных юнитов.
👉Так как результат метрики – деньги, она хорошо привязывается к любым другим финансовым показателям, и дает хорошее представление о ценности платформенных улучшений.

Новые выпуски тимлидских подкастов

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

👉"Бреслав и Ложечкин" про то, может ли руководитель проявлять свои эмоции, и где провести грань
👉"Три тимлида заходят в бар" про то, как ужерживать в команде самых ценных и важных специалистов на высоких грейдах
👉"КОДА КОДА" про то, как тимлиду управлять собственной энергией и мотивацией
👉Подлодка про то, как AI помогает в рабочих и личных задачах за пределами разработки (например, в поиске работы и подготовке к интервью)
👉"Едим слона целиком" про то, что такое стресс в менеджерской работе, и как с ним справляться

Про культуру встреч

The goal of an exceptional meeting culture is to allow for people to constructively decline meetings by fully understanding the consequences of their action.

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

Чтобы это сломать, нужно сделать так, чтобы безопасным дефолтным выбором было отклонить встречу. Вот каких изменений это требует:

👉В описании митинга должна быть агенда встречи с примерной оценкой, сколько времени на какую тему вы хотите потратить
👉Если на встрече планируется принять решения, напишите об этом явно
👉Модератор встречи должен следить за тем, что вы придерживаетесь запланированной агенды, и ей в итоге можно верить
👉Любые отклонения от запланированных тем тормозятся и откладываются на другие обсуждения
👉Участники приходят только тогда, когда сильно заинтересованы в теме, готовятся к участию, и активно участвуют в обсуждениях
👉Те, кто отклоняет встречу, готовы к тому, что решения принимаются без них
👉Ведутся подробные meeting minutes

Никто ничего не читает

Несмотря на истории из Amazon про writing culture, реальность и бигтеха, и компаний поменьше в том, что никто не читает больших документов. В самом лучшем случае часть людей прочитает по диагонали executive summary, но и на это расчитывать не стоит.

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

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

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

Карьера вайб-кодера – это тупик

Хороший разбор нескольких тейков, которые сейчас звучат из каждого утюга:

👉Те, кто первыми научится использовать AI, получат огромное преимущество.

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

👉Главное – уметь хорошо промптить

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

👉Вайбкодинг ускоряет работу в десять раз

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

👉AI упрощает работу программиста

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

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

Быстрые и долгие проекты

Первый список вы, скорее всего, когда-то уже видели – это перечень амбициозных проектов, которые были сделаны удивительно быстро для своего масштаба. Например, Unix, написанный за три недели, JavaScript за 10 дней, или iPod, на весь цикл от идеи до продакшна которого ушло всего 290 дней.

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

Про stack ranking

Вы наверное слышали про отвратительную практику, иногда встречающуюся в корпорациях – stack ranking. В чем суть – вы должны отсортировать всех своих сотрудников по перфомансу по бакетам по какой-то спущенной сверху эвристике. Например, в Microsoft долгое время в каждой команде всегда надо было выделять 10% худших сотрудников, даже если на деле все работали примерно одинаково. Обычно эта система влияет на распределение бонусов, а иногда служит и основой для сокращений.

Так вот, в нашем втором канале "Тимлид не спит" Александр Орлов из Стратоплана разбирает кейс, в котором тимлид впервые столкнулся с такой системой и ему надо выбрать кого-то худшего в команде, в которой все молодцы.