В издании для рекрутеров HR Bazaar вышла моя новая статья про идеальный размер команды:
https://hrbazaar.ru/articles/komanda-iz-6-chelovek-effektivnee-20/
Прошу читать и критиковать)

Это доработанная и адаптированная статья на основе поста из блога.

Разрабы должны чувствовать последствия своих решений

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

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

"Практика you build it - you run it" предлагает радикально другой подход: пусть тот, кто создает проблему, сам с ней и разбирается. Не из садизма, а из понимания простой истины — только почувствовав боль, разработчик начинает писать код по-другому. Когда разработчик знает, что в 3 утра его разбудит алерт от его собственного кода, магическим образом меняется отношение к качеству:
- Логирование становится осмысленным, а не формальным
- Обработка ошибок из "авось пронесет" превращается в продуманную стратегию
- Мониторинг закладывается на этапе проектирования, а не добавляется постфактум, чтобы номинально удовлетворить требования
- Архитектурные решения перестают приниматься по модели "и так сойдет"

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

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

Хороший разработчик думает не только "как это реализовать", но и:
- Как это будет деплоиться?
- Как это будет мониториться?
- Что будет, если это упадет?
- Как быстро можно будет найти и исправить проблему?

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

П.С. Знали бы вы, сколько я контр-аргументов против выслушал по этому поводу
П.П.С. На КДПВ девелоперы заботливо развивают свои микросервисы ^__^

Недавно участвовал в опросе среди 700+ руководителей команд - сегодня прислали результаты, которые показывают, что тимлиды в 2025 году балансируют на грани.

Да, нейросети, автоматизация - все об этом говорят. Но есть другая интересная картина, которая подтверждает мои собственные наблюдения: раньше многие мечтали перейти в лиды, а сейчас, каждый второй задумывается откатиться обратно. Нагрузка выросла, ответственности ещё больше, а разница в зарплате не так уж велика. Опрос показывает, что половина тимлидов ощущают перегруз, а 85% признаки выгорания.
Тут можно посмотреть результаты подробнее: devcrowd.ru/tl-2025/

10 правил хорошего тимлида команды разработчиков

▫️1. Уберите лишние собрания.
Каждый час созвона это минус час фокуса и ещё полчаса на возвращение в контекст текущей задач.

▫️2. Защитите от переработок.
Обсуждения и задачи только в рабочее время, а овертаймы и внеурочные выходы расценивайте как инциденты с разбором причин.

▫️3. Закладывайте реальные сроки.
Важна не только скорость, но и надёжность. Если сроки навязывают и они нереальны, объясните риски и дайте профессиональную оценку.

▫️4. Фильтруйте пожары.
Не каждый срочный влёт критичен. Берите паузу на проверку и защищайте команду от ложных тревог.

▫️5. Подсвечивайте приоритеты.
У каждой правки и нового требования есть цена и глобальное влияние; не меняйте приоритеты без обоснованной ценности.

▫️6. Защищайте от необдуманных решений.
Двигайтесь по целям, отсекайте хотелки без понятной ценности, обосновывайте выбор и предлагайте компромиссы.

▫️7. Избавляйтесь от карго-культа.
Не бойтесь пересматривать процессы и ритуалы. Если флоу работы, статусы или митинги потеряли актуальность, убирайте их или меняйте.

▫️8. Срезайте бюрократию.
Избегайте лишних согласований и узких горлышек, задавайте простые правила и делегируйте решения; автоматизируйте рутину.

▫️9. Помогайте развиваться.
Слушайте запросы, давайте регулярную обратную связь по точкам роста, ставьте цели и выделяйте время на обучение.

▫️10. Подмечайте достижения.
Хвалите за хорошую работу на командных и личных встречах, отмечайте важные успехи выше и делитесь кейсами на всю компанию.

Необязательно быть идеальным лидером. Но вашей команде нужно, чтобы вы её защищали!

Henry Developer

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

Я тут, немного поразмышлял на тему: "Что делать если вам урезали бюджет".
https://vaiti.io/kak-spasti-proekt-pri-urezanii-byudzheta-rabotayushhie-metody-iz-moej-praktiki/

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

Ставьте лайки если поддерживаете, критикуйте если нет!

За последнее время мне довелось поработать с несколькими редакциями изданий. И вот три разных статьи которые делались почти месяц опубликованы почти в одно время)

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

Как всегда жду критику и ваше мнение!

https://delovoymir.biz/ii-kak-soosnovatel-prakticheskiy-vzglyad-tehlida.html

Посетил интересную лекцию Самата Галимова, ведущего подкаста «Запуск завтра», про историю развития нейросетей.

Джун уже 6 месяцев откликается на вакансии. Каждый день шлёт холодные письма. Ноль результата.

Попросил меня посмотреть его резюме и скинул ссылку. Я не смог её открыть. Спрашиваю у него - он отвечает: «У меня открывается».

Парень разослал 400 писем, даже не зная, что нужно выдать доступ на просмотр в Google Drive.

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

В Твиттере поделились трогательной историей

Проблемы нового VR-шлема от Valve

Меня всегда интересовала тема виртуальной реальности. Ещё в детстве, увидев первый VR-шлем от Sega, я не мог спокойно спать — идея оказаться в любом месте мира (и даже в выдуманном) не вставая с дивана казалась чем-то фантастическим.

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

Как вы, наверное, уже слышали, вчера Valve представила свой новый VR-шлем. Я изучил его характеристики и собрал свои личные впечатления: что получилось хорошо, а что вызывает вопросы.

Читать на VC

В универе мне говорили: «Запоминать материал наизусть - вредно. Важнее понимать, где и как искать». Тогда это звучало необычно, а сегодня становится нормой: технологии меняются быстрее, чем успеваешь выучить. Раньше, незнание конкретики считалось минусом: «нужен тот, кто уже знает». Но теперь ии-агенты читают документацию лучше и быстрее нас всех!
И фокус сместился. Сейчас важнее не помнить, а быть гибким. Иначе легко застрять в прошлом и стать «дедом» со своими «проверенными», но устаревшими приёмами.

#мысли #ии

Поражаюсь, как современные AI-чат-боты помогают удовлетворить мою тягу к знаниям здесь и сейчас! Можно спрашивать любую неведомую дичь уровня «как натянуть ужа на дирижабль». Он, конечно, скажет: «Ты совсем чокнутый, но давай представим, как бы это вообще можно было сделать!» И всё — больше нет границ тому, о чём можно размышлять и дискутировать.

Любые идеи, типа «а что если создать устройство…» — ты сможешь спокойно обсудить и получить полноценные размышления и даже примеры решений. И даже рендер, если очень хочется. Запускай стартап и вперёд. Больше никаких границ фантазии!

Ещё 5 лет назад я мог услышать только: «Уйди отсюда, мальчик, и не задавай глупых вопросов». Безграничные знания были фантастикой, а теперь — мы уже здесь!)

Всем привет! Сегодня поучаствовал в беседе с ИТ-экспертами на тему зарплат программистов в следующем году. Ребята высказали интересные предположения. Таймкоды на мои комментарии: тыц, тыц, тыц и тыц!
Можете закидывать свои предположения и мысли)

Современная "охота на ведьм"

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

Последнее время всё чаще возникает ощущение, что все вокруг пытаются друг друга уличить в использовании нейросетей.
Авторов статей критикуют за длинные тире, дизайнеров — за гиперреалистичность, разработчиков — за вылизанный код, а соискатели с HR’ами соревнуются, кто быстрее задетектит, что с ним общается AI-агент, а не человек.

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

Но почему бы не относиться к этому просто как к инструменту?
Совершенно не важно, как ты сделал свою работу, если ты добился результата. Важно другое — что ты декларируешь и за что отвечаешь.

Если ты опубликовал текст, созданный с помощью нейросети, и выдаёшь его как своё мнение — значит, ты за него отвечаешь. Не важно, что сформулировать мысль помог AI, важно, что это твоя позиция и ты выбрал правильный инструмент, чтобы её донести.
Не важно, если резюме составлено нейросетью — важнее, что оно отражает реальный опыт.
Точно так же не важно, что код, вынесенный на ревью, был сгенерирован нейросетью. Гораздо важнее — кто за него отвечает.
А ложь — это отдельный вопрос. Люди врали и до изобретения нейросетей, этого не изменить.

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

#мысли #ai

Стоит ли переходить из разработки в лиды?

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

1. Какие качества должны быть у тимлида, чтобы расти в карьере и эффективно управлять командой?
Сильнейшее качество тимлида, на мой взгляд, — защита фокуса команды. Это базовая функция. Тебе нужно следить за тем, чтобы не разрастались лишние созвоны, фильтровать ложные пожары, резать бюрократию и не давать внешним людям ломать ваши приоритеты без внятной ценности. Ты должен следить, чтобы команда не выгорала и не было переработок, а значит, сроки должны быть реалистичными, с проговорёнными рисками. Нужно научиться говорить «нет» заказчикам и предлагать компромиссы. Также важной частью работы тимлида является ответственность за развитие людей как системный процесс. Например, если все вокруг пользуются новыми инструментами — ты должен быть уверен, что в твоей команде у ребят есть время на то, чтобы их изучить. И лучше быть в этом первым, чтобы не сбавлять темпов и оправдывать ожидания без пинка сверху. Ну и результат: нужно не забывать подсвечивать достижения, «продавать» успехи команды наверх и постоянно выравнивать ожидания стейкхолдеров.

2. Как понять, что быть тимлидом — твоё? А когда стоит уходить в экспертизу, а не в менеджмент?
Начать хочется с того, что тимлид — это не следующий грейд разработчика. Это переход из технической роли в управленческую. Будет совсем по-новому, и сильные технические навыки не обязательно помогут справиться с управлением командой. В первую очередь ты перестаёшь думать за себя и начинаешь думать и нести ответственность за всю команду. Любое неверное решение другого человека становится твоей проблемой. Это, кстати, верно и в эпоху AI-агентов, когда не так важно, кто пишет код — гораздо важнее, кто несёт за него ответственность.

Проведите мысленный эксперимент: насколько вам комфортно достигать успеха через других? Если удовольствие приносит не «я закоммитил», а «команда стала сильнее и стабильно делает результат» — это хороший сигнал в сторону менеджмента. Если же драйвит личная глубина, решение сложных техзадач и влияние через архитектуру/экспертизу, а «людские» задачи вы выносите на силе воли — лучше остаться в техническом русле.

Самая частая проблема, с которой сталкиваются лиды, — вопрос: «а что я сегодня сделал?». Иногда ответ очень размытый: «какие-то встречи, двигал таски, что-то обсуждал, и 0 строк кода. А ведь мог спокойно писать себе код и не отвлекаться на это всё!». При этом рынок зарплат часто солидарен и предлагает за такую неявную работу совсем небольшую прибавку.

Возможность защищать команду, выбирать вектор развития, изучать управленческие подходы — несомненно приятный бонус. Но если вы постоянно компенсируете роль через «я сам сделаю быстрее», если раздражают 1:1 и работа с мотивацией, если вам неприятно принимать кадровые решения или если вы чувствуете, что перестали расти как инженер/архитектор и вас это фрустрирует, — тогда лучше честно продолжить рост в технической экспертизе, где влияние достигается не властью, а техническим лидерством.

Как не деградировать, работая с нейросетями?

Последнее время кажется, что я деградирую, доверяя всё больше и больше написание кода и ресёрч нейросетям.
Начал замечать, что какие-то вещи уже не «на кончиках пальцев»: названия, boilerplate, конструкции. Раньше нужно было разбираться самому, а сейчас — описал промпт, и всё готово. И в какой-то момент появляется ощущение, что тупеешь.

Но я для себя сформулировал так: если знания можно восстановить за пару минут, их не обязательно держать в голове постоянно. Важно понимать принцип. Да, и вспомнить проще, чем учить с нуля. И тогда это уже не деградация, а перераспределение когнитивной нагрузки — освобождается место для более важных решений.
Экспертность ведь не в объёме выученного. Она в способности брать ответственность и принимать решения в условиях неопределённости. ИИ может ускорить, но последствия всё равно разгребать мне.

Выделил для себя несколько мысленных маркеров, которые помогают отличить признаки деградации от упрощения:
— «оно работает», но я не понимаю, что происходит
— принимаю ответ без проверки
— не могу объяснить решение своими словами
— не могу отдебажить, когда агент уткнулся в ошибку
— избегаю погружения в сложные задачи только потому, что «ИИ же сделает»
Если финальные решения всё ещё принимаю я — значит, это не деградация, а адаптация.

(Полная статья в блоге)

А как вы сдерживаете деградацию знаний?