Есть ли польза у code review

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

Подкину первой группе немного данных в их копилку аргументов:

👉Команды без code review работают в 2 раза быстрее, но получают в 2.5 раза больше багов.
👉Чем больше человек смотрит ревью, тем меньше шанс получить баги. Если смотреть по средним значениям, самый большой выигрыш до 0.5 ревью на PR – то есть в командах, ревью в которых проводят не на все изменения.

Пара слов про то, как проводилось исследование – смотрели на данные от 400 компаний с 3000 инженерами, к которым есть доступ у платформы измерения качества кода.

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

Про забор Честертона и техдолг

Держите забор Честертона в вашу копилочку умных названий вредных заблуждений:

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

Иначе говоря – нельзя избавляться от того, смысла чего вы не понимаете.

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

Когда коллаборация – антипаттерн

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

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

Как использовать Claude Code вне разработки

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

Вот несколько точно полезных:

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

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

Так, приближаются выходные, поэтому держите новый дайджест подкастов, которые сможете слушать ближайшие недели!

👉"Бреслав и Ложечкин" про то, как Agile постепенно превращался из здорового набора принципов в бюрократию и карго-культ
👉Подлодка про человекоцентричное управление, важность счастья сотрудников и вред от переработок
👉"Едим слона целиком" про то, как стать СТО, откуда взять нужный опыт, и из чего будут состоять трудовые будни
👉"Организованное программирование" с Александром Бындю про технический консалтинг, увольнения СТО и правильный рост разработчиков

Сюрпризы для начинающих руководителей

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

👉Ваш календарь превращается в календарь всей команды, время больше вам не принадлежит.
👉Самые сложные разговоры чаще всего не запланированы в календаре, а начинаются с сообщения в Slack "есть пять минут поговорить?"
👉Ушли те дни, когда вы могли успокаивать себя тем, что продолбался менеджер. Теперь все так думают про вас.
👉Любые победы очень отложены во времени, а вот провалы ощущаются сразу же.
👉Настоящая работа состоит не в том, чтобы решать, что делать, а в том, что не делать.
👉Команда становится зеркалом ваших привычек, как хороших, так и плохих.

Как работается в Cursor

Очень классный обзор культуры команды, которая разрабатывает Cursor:

👉Фокус на посещение офиса, малое количество митингов, и глубокую работу без отвлечений.
👉При найме думают не столько о позиции, которую надо закрыть, а о конкретном человеке, которого хочется нанять – и уже под него подбирают подходящие задачи. А подходящих людей ищут коллективно, делясь в чате, с кем хочется поработать.
👉Больше 20% команды когда-то сами были фаундерами.
👉Режим "9-9-6" не обязателен, но является негласной нормой. Новички паникуют, но потом вливаются.
👉Перед каждым релизом команда собирается в одном помещении и все вместе пытаются этот релиз сломать разными способами.
👉Фидбэк на новые идеи и фичи собирается в отдельном канале в Slack – все голосуют, оставить ли фичу или убить.
👉В найме используют тактику сюрприза. Интересующего человека зовут просто заглянуть в офис в гости, а потом организуют с ним серию неформальных бесед, после чего, если всем он нравится, присылают оффер.

Принципы фаундера Replit

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

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

Честность – лучшая политика

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

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

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

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

А еще, мы ищем экспертов, которые готовы разбирать кейсы и делиться своим опытом – так что отзывайтесь, все детали в описании канала!

Обновился OWASP Top-10

Чем бы вы ни руководили, разбираться в инфобезе вы должны хотя бы на уровне понимания основных угроз из списка OWASP Top 10.

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

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

Менеджмент через последствия

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

Давайте приземлим на конкретику, как такая коммуникация может выглядеть:

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

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

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

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

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

При этом, если покопать в Toyota Production System, откуда вообще пошла идея continuous improvement, можно найти конкретные вещи, которых не хватает сломанным ретроспективам:

👉В TPS у всех участников производственного процесса есть возможность (и более того, требование) остановить процесс разработки, когда обнаруживается проблема – вместо того, чтобы вернуться к ней только через пару недель на запланированной ретроспективе.
👉В TPS проблему пытаются исправить сразу же, не откладывая. В наших реальностях мы пытаемся быстро ее запатчить, обещая, что в будущем обязательно вернемся и поправим как надо – но приоритеты до этого никогда не доходят.
👉В TPS у результатов root cause analysis есть четкие дедлайны, ответственные и понятный ожидаемый исход. Сравните со стандартными "улучшить процесс" или "обновить документацию", которые появляются после ретроспектив.
👉В TPS действия, которые предпринимают по итогам инцидента, должны не давать повторяться исходной проблеме. Иначе говоря, это постоянные решения, а не временные.

Подьехал новый стандарт по тому, как надо писать сопроводительные письма. Ознакомьтесь, внедрить надо до конца декабря!

Вневременные навыки менеджера

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

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

👉Execution – делать так, чтобы команда приносила ожидаемые от нее результаты.
👉Team – управлять командой и ее окружением, помогая ей достигать успеха.
👉Ownership – искать способы достичь результатов даже в сложных обстоятельствах.
👉Alignment – выстраивать единую картину мира между командой и стейкхолдерами.
👉Taste – иметь сильное мнение о том, что значит "хорошо" в инженерной работе.
👉Clarity – делать так, чтобы все вокруг понимали что вы делаете и зачем.
👉Navigating Ambiguity – превращать непонятные сложные проблемы в понятные следующие шаги, подкрепленные вашим экспертным мнением.
👉Working across Timescales – показывать импакт и на коротком, и на длинном горизонтах.

Так, распространяем лучшие практики вычисления AI и на тестовые задания!

Опрос подписчиков Teamlead Good Reads

Помогите мне разобраться с тем, как лучше вести канал – расскажите немного про себя, свой опыт в управлении, а главное – про то, какие темы канала вам интереснее всего! Опрос небольшой, минуты за 3 точно справитесь.

А чтобы обмен получился более честным, среди ответивших на опрос я разыграю несколько сертификатов на хорошие книги в МИФ! От себя могу посоветовать там как минимум Код, Азбуку системного мышления и Пять пороков команды – но и помимо них там есть много всего хорошего.

👉Пройти опрос

Как работает промо в Amazon

Я точно несколько раз уже закидывал материалы, связанные с тем, как в Amazon устроена карьерная линейка (раз, два, три). Но сегодня – прямо очень детальный разбор от их недавно вышедшего на пенсию VP of Engineering, который заседал во всяких комиссиях по повышениям инженеров. Что бросается в глаза:

👉Что считается признаками хорошего мидла: способен независимо решать проблемы и не ноет.
👉Что нужно мидлу, чтобы вырасти в сеньора: предлагать и затаскивать большие проекты, которые приносят ощутимую ценность команде. Причем важно затащить такой проект именно в соло, договорившись со всеми нужными людьми вокруг. Помимо этого нужно решать неочевидные, но важные проблемы – а еще лучше, если это проблема завтрашнего дня; иметь уникальную техническую экспертизу и быть "go-to person" по каким-то вопросам; менторить других разработчиков; иметь заметное влияние на других; уметь бороться с кризисами.
👉При этом с того момента, когда вас признали крепким мидлом (см пункт 1), и вы начали показывать признаки сеньора (пункт 2), ждать промо еще 1-2 года.