Привет, Хабр! Меня зовут Андрей Бирюков. Я являюсь независимым экспертом в области ИТ и ИБ, преподаю в учебных центрах и пишу книги. Каждая компания‑разработчик хочет иметь в своей команде сильных специалистов, и зачастую поиск и найм таких спецов ограничивается только бюджетом. Однако в этой статье мы рассмотрим ситуацию, в которой у нас была возможность нанять гениального одиночку, но в итоге мы получили токсичный актив, разрушивший всю команду.
Перспективная история с грустным концом
Итак, у нас есть команда из 6 разработчиков среднего уровня, работающих над флагманским продуктом. Скорость — нормальная, качество — приемлемое, но есть одна проблема: архитектура старого модуля трейдинга тормозит развитие. Руководитель — опытный тимлид, которого наняли полгода назад, чтобы «ускорить команду».
Тимлид принимает решение, которое кажется ему идеальным. Он находит на рынке разработчика с 12-летним опытом, который раньше работал в крупной западной компании, писал высоконагруженные системы и знает три языка программирования на уровне эксперта. Этот разработчик произвел прекрасное впечатление на собеседовании: он решает сложные алгоритмические задачи быстрее всей панели интервьюеров вместе взятых.
Чтобы заполучить этого разработчика, тимлид выбивает зарплату в два с половиной раза выше средней по команде. Логика простая: «Рок‑звезда вывезет сложный модуль за три месяца, а потом подтянет остальных».
Первые две недели все шло хорошо. Наш гений не только быстро пишет код, но и находит два критических бага в старой системе, которые никто не замечал годами. Команда смотрит на него с восхищением.
Но через пару месяцев начинаются проблемы. Наш вундеркинд категорически отказывается писать документацию («Код сам себя документирует для тех, кто умеет читать»). Code review от него выглядит одинаково: «Это не работает, перепиши с нуля» — без объяснений. Джуниор, попросивший помощи, услышал: «Читай документацию к фреймворку, я не репетитор».
Дальше — хуже. Модуль, который он разрабатывает, работает идеально, но никто в нём не может изменить ни строчки — слишком неочевидная архитектура и плотный, переусложнённый код. Остальные разработчики чувствуют себя некомпетентными и перестают предлагать идеи на планерках. Два инженера, которые раньше были лидерами команды, подали заявления — «атмосфера больше невыносима».
И что же мы получаем через полгода. Наша рок‑звезда работает по 60 часов в неделю, потому что всё замыкается на нём. Он выглядит измотанным, несколько раз на стендапе огрызался на вопросы. Тимлид понимает, что допустил ошибку, но не знает, что делать: уволить гения — потерять единственного человека, понимающего новый модуль; оставить — потерять остальную команду.
Это классический сценарий ошибки найма «рок‑звезды». Теперь давайте разбираться с тем, кто и в чем допустил ошибку и что теперь делать.
Ошибка руководителя
Для начала, давайте договоримся об одной важной вещи: наш разработчик не злодей. Он действительно гениальный инженер, который привык работать один и не обучен (или не хочет) усиливать других. И ошибка руководителя здесь системная и управленческая, а не этическая.
Прежде всего, это смешение понятий. Тимлид принял «индивидуальную продуктивность» за «командную ценность». Он не задал себе вопрос: «Как этот человек изменит работу остальных пятерых?» Вместо этого он думал: «Сколько строк кода он напишет за нас?»
Далее идет недооценка культурных навыков. Мы нанимали «архитектора‑спасателя», не проверив его готовность к наставничеству, документации и pair programming. На собеседовании спрашивали о сложных алгоритмах, но ни разу не спросили: «Как ты объяснял сложную тему коллеге? Как реагировал, когда код новичка не проходил ревью?»
Еще одна ошибка — это игнорирование превентивных индикаторов. Уже на второй неделе наш гений отказался писать документацию. Это был первый звоночек, но тимлид не придал ему значения — «главное, чтобы код был». Звоночки копились, а руководитель списывал их на «особенности творческой личности».
И наконец, отсутствие системы онбординга для «звёзд». Разработчика бросили в команду без чётких правил и ожиданий. Ему никто не сказал: «Мы ценим твою скорость, но у нас есть правило — код без пояснительных комментариев и документации не принимается». Руководитель создал вакуум, который наш «мегаразраб» заполнил своей моделью работы.
То есть, в итоге, у нас получается, что руководитель купил «супер‑код», не осознавая, что платит за это демотивацией всей команды и созданием bus‑фактора (один человек — единственное звено, при котором система не развалится).
Автобус… и другие риски и последствия
Поговорим о том, какие риски и проблемы мы получили в итоге. Начнем с так называемого bus‑фактора. Если нашего мегагения завтра собьёт автобус (или он уволится), проект останавливается на 2–4 недели минимум. Никто другой не понимает его модуль. Количество людей, способных безопасно задеплоить изменение, равно одному. Это прямое следствие отказа от документации и от совместного написания кода.
Еще одно последствие — это падение скорости команды. Да, рок‑звезда пишет код быстро, но все остальные… Замеры показывают: скорость принятия pull request от обычных разработчиков упала на 50%. Почему? Наш гений блокирует ревью своими саркастическими комментариями. Кроме того, остальные инженеры начали тратить время на безуспешные попытки понять его код или на рефакторинг того, что он набросал в спешке.
В итоге мы получаем рост текучки среди «середняков и перформеров». Самые ценные средние и сильные разработчики уходят первыми. Они видят, что их идеи не ценятся, а карьерный рост заблокирован. Гений занимает весь кислород в архитектурных обсуждениях. Формула: один «рок‑звезда» может вызвать увольнение 2–3 хороших инженеров за полгода. Стоимость замены каждого — 3–6 месяцев зарплаты.
Не стоит сбрасывать со счетов и скрытое выгорание самого нашего гения. Он работает один — 60 часов в неделю, без подстраховки, без обсуждений. Его код становится всё сложнее, потому что некому задать вопрос «а можно проще?». Через 6–9 месяцев такой нагрузки он либо срывается, либо уходит в другую компанию, где «больше амбициозных задач». Итог: вы потеряли и команду, и «звезду».
И в завершении мы получаем эрозию психологической безопасности в команде. Джуниоры и мидлы перестают задавать вопросы, потому что боятся услышать «ты что, этого не понимаешь?». Код‑ревью превращается в судилище. Атмосфера из «мы вместе» превращается в «Я Д'Артаньян, все … я один гений, а вы статисты«.»
Все эти последствия имеют количественные индикаторы, которые тимлид обязан отслеживать. Если они появились — ошибка уже совершена. Вопрос только в том, насколько глубоко вы внутри провала.
Итак, мы разобрались с проблемой, теперь давайте рассмотрим способы предотвращения подобной ситуации.
Как распознать «токсичную звезду» на собеседовании и в первые недели
Что можно спросить у соискателя на собеседовании для того, чтобы выявить описанные выше риски.
Первый вопрос о наставничестве: «Расскажи случай, когда ты помог младшему коллеге разобраться в сложной теме. Что именно сделал? Как часто это происходит?».
Не принимайте ответы типа «я дал ссылку на документацию» или «я поправил его код сам». Ищите развёрнутое объяснение, терпение, описание того, как человек адаптировал сложную тему под уровень слушателя.
Далее стоит спросить о документации: «Твой код через год будет читать другой инженер. Что ты сделал за последний год, чтобы ему было легче?»
Если кандидат говорит «мой код самодокументируем» или «не пишу комментарии, они устаревают» — красный флаг. Документация бывает разной, но полный отказ от неё в командной разработке — это риск.
Также неплохо бы спросить об обратной связи: «Как ты реагируешь, когда твой код справедливо критикуют на ревью? Приведи конкретный пример».
Ищите не идеальный ответ, а отсутствие агрессивной защиты. Если кандидат рассказывает, как он объяснял, почему его решение лучше, и при этом не обесценивал мнение коллеги — хорошо. Если говорит «меня редко критикуют, потому что я пишу хорошо» — насторожитесь.
Помимо собеседования, диагностировать «токсичную звезду» можно по первым неделям работы. Например, посмотрите на его реакцию на стандарты команды. Дайте ему почитать ваш гайд по кодстайлу и документации. Если он говорит «это бюрократия, я не буду этому следовать» — у вас проблема. Хороший инженер обсуждает стандарты, плохой их игнорирует.
Индикатор второй — первое общение с джуниором. Посмотрите, как новый разработчик отвечает на вопрос новичка (подойдите и послушайте, не предупреждая). Если ответ раздражённый или насмешливый — это не исправится само.
И еще один индикатор — это готовность к парному программированию. Предложите разработчику написать первую задачу в паре с кем‑то из команды. Если он отказывается («я быстрее один») — вы получили одиночку, и в командной разработке это минус.
Если вы видите хотя бы два красных флага из шести (три вопроса собеседования + три индикатора первой недели) — не нанимайте, либо нанимайте с чётким контрактом «ты делаешь X, Y, Z, иначе испытательный срок».
А если все совсем плохо
Теперь рассмотрим более сложный сценарий: ошибка совершена, наш rock star сидит в команде, и проблемы нарастают. В такой ситуации руководитель может начать с личного разговора (не обвинительного, а конструктивного) с проблемным сотрудником наедине. Говорите не «ты токсичный», а «у нас есть командные правила, которые я как руководитель не донёс до тебя в начале». Перечислите три незыблемых правила:
код‑ревью не содержит личных оценок и требует объяснений;
документация обязательна для любого публичного модуля;
отказы от помощи коллегам не принимаются.
Далее, назначьте ему официального «менти» из джуниоров на 2 часа в неделю (это часть его рабочего времени, а не благотворительность). Объясните: «Мы наняли тебя не только писать код, но и растить команду. Это тоже твоя задача, и мы будем её оценивать».
И введите практику «парного ревью»: pull request нашего гения проверяет не только он (в смысле, он принимает), но хотя бы один другой разработчик. И наоборот — он комментирует чужой код, но не блокирует его без объяснения.
Этот сценарий будет работать, если новый сотрудник — адекватный человек, который просто не понимал ожиданий. Если после двух недель выполнения правил ничего не меняется — переходим к следующему сценарию.
Если в течение 3–5 месяцев ситуация не меняется в лучшую сторону, введите персональные цели для данного работника на квартал, привязанные к командным метрикам. Например:
написать документацию на два ключевых модуля;
провести три тренинга для команды;
снизить время ревью для чужих pull request до 24 часов.
Без выполнения этих целей — бонус не выплачивается.
Также документируйте случаи токсичного поведения (конкретные фразы, даты, отказ от помощи). Не для того чтобы наказать, а чтобы у вас была объективная картина. Поговорите с командой анонимно (опросник) — «как влияет на вашу работу присутствие нашего гения?».
А еще здесь нужен чёткий тайм‑бокс: через 4–6 недель вы подводите итог. Если метрики команды (скорость, количество инцидентов в его модуле при попытке изменений другими, удовлетворённость коллег) не улучшились — вы переходите к… да, вы правильно поняли, к увольнению.
Парадокс, но уволить «рок‑звезду» часто оказывается менее болезненно, чем оставить. Да, вы потеряете модуль, который он написал. Но вы сохраните команду из 5–6 хороших инженеров, которые без него сделают больше и лучше за 2–3 месяца.
Для увольнения без лишних проблем заморозьте новый функционал в его модуле на 2–3 недели. Команда за это время пишет документацию и тесты к тому, что он наделал (да, придётся разбираться, но это неизбежно). И параллельно ищите замену — не другую «рок‑звезду», а хорошего, стабильного инженера, который умеет работать в команде. Зарплата может быть средней, но с чёткими ожиданиями по коммуникации.
Увольнение по соглашению сторон (без скандала). Уже не нашему гению подойдёт другая компания, где ценят одиночек‑архитекторов. Ваша компания — командная. Это не хорошо и не плохо, это просто разная совместимость.
После увольнения проведите ретроспективу с командой. Не «какой гений был плохой», а «как мы позволили возникнуть такой ситуации и как не допустим повторения».
Выводы
Ошибка найма «рок‑звезды» — это не история про плохого инженера. Это история про руководителя, который не задал вовремя вопрос: «Как этот гениальный одиночка повлияет на остальных пятерых?».
Самый продуктивный разработчик в мире не стоит демотивации всей команды и создания bus‑факторов. Нанимайте сильных, но проверяйте не только IQ, но и умение усиливать других. И если ошибка уже совершена — не тяните с исправлением. Уволить «звезду» иногда бывает лучшим управленческим решением за год.
Если после статьи захотелось не просто кивнуть «да, так бывает», а понять, как такие ситуации диагностировать и не доводить до развала команды, присмотритесь к открытым урокам OTUS. Они бесплатные, проходят в рамках онлайн‑курсов и помогают проверить, насколько вам близок формат обучения.
20 мая, 20:00 — «Системная диагностика команды и группы команд». Записаться
На уроке поговорим о том, как замечать проблемы в команде не по ощущениям, а по сигналам, метрикам и повторяющимся управленческим паттернам.2 июня, 20:00 — «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться
Подойдёт тем, кто уже вырос из роли «просто сильного инженера» и хочет научиться управлять людьми, процессами и ожиданиями без хаоса и выгорания.
Больше открытых уроков, подборок по IT‑направлениям и полезных материалов публикуем в нашем канале в MAX. Подписывайтесь, чтобы не пропустить новые вебинары, разборы и анонсы курсов.
Комментарии (77)
ideological
21.05.2026 16:25Как можно генерировать такой бред?)
Он не задал себе вопрос: «Как этот человек изменит работу остальных пятерых?»
У дефективных менеджеров часто всё происходит само-собой. Хотя наверное иногда следует сказать о целях, например по подтягиванию команды. Придумать отдельные мероприятия или хотя бы поставить встречу.
Вместо этого они готовы не только на джуна поставить сложную задачу, и на уборщицу тикет бы поставили, если бы могли. "Там в команде разберутся и вообще юниты в постоянной синхронизации сами по себе."
Berrserker
21.05.2026 16:25Сказки уровня б из 2003. Верните книжку, из которой вы этот шедевр классической литературы взяли, тому деду который вам ее одолжил.
poige
21.05.2026 16:25Верните книжку, из которой вы этот шедевр классической литературы взяли, тому деду который вам ее одолжил.
Учитывая вступление «являюсь независимым экспертом в области ИТ и ИБ, преподаю в учебных центрах и пишу книги» это звучит как уже почти … — Да нормально в общем звучит. ;)
achekalin
21.05.2026 16:25А в должностных у "звезды" было "объяснять джунам фреймворк" или хотя бы "обучение коллег"?
Потому что его брали с ожиданием "напишет" - вот он и пишет! А все, что его отвлекает от письма, он с раздражением игнорит.
FixicusMaximus
21.05.2026 16:25Вот я тоже не понял. Понабирают роковых, а потом спрашивают как с терпил.
GeorgSokolov96
21.05.2026 16:25Терпила в данном случае, я думаю, менеджмент. При чем от собственной глупости потерпевший.
JustMoose
21.05.2026 16:25Эмммм.... Я не очень в курсе, какой грейд у "рок-звезды", но обычно про сеньоров говорят:
"Вторая важная задача senior-программистов — это обучение и менторство. Они делятся опытом и формируют культуру знаний. Передача экспертизы делает команду и продукт значительно сильнее. При этом менторство снижает зависимость команды от отдельных сотрудников и помогает повысить эффективность новых людей." (с) https://blog.skillfactory.ru/senior-razrabotchik/
akakoychenko
21.05.2026 16:25Чувствую боль этого рокера. Когда окружен людьми, на 2 головы слабее себя, причём, скорее всего, не только в знании фреймворка, а и в способности строить и валидировать длинные логические цепочки, держать достаточно токенов в контексте, и уметь мыслить абстрактно.
К слову, если, и, вправду, модуль трейдинга столь важен и критичен для компании и алгоритмически сложен, и там зарыто конкурентное преимущество, то, таки да, рок-звезда там нужна. Можно иметь хоть 6, хоть 60 посредственностей, но, если конкурент такой рок-звездой обладает, то это имеет немного смысла. Голлиаф, перекидывающий джейсоны между сотней микросервисов, не одолеет Давида, бьющего точно в темечко.
Вообще, подозреваю, что найм ещё одного разраба его уровня, возможно, смог бы решить вопрос. Топовые инженеры любят работать с равными себе. Да и, если один сбежит, то второму будет куда легче вникнуть, чем толпе растерянных детей
SingleDigitIq
21.05.2026 16:25Вот да, если повезло с умом, то как будто только в кванты и идти. Больше нигде не возьмут без мимикрирования, видимо страшно брать тех, кто может оказаться умнее интервьювера, порой во всех отношениях, лучше или вежливо выпроводить, или завалить как-то
Nalivai
21.05.2026 16:25Главное не перепутать “умнее интервьюера” и высокомерие. Множество раз видел такое, разговаривает через губу, каждое предложение начинает с глубокого раздраденного вздоха, а потом “ой меня никуда не берут, никто со мной не разговаривает, это потому что я самый умный а все тупые”. Особенно обидно такое видеть когда человек действительно умный. Ну потрать ты капельку ума на то чтобы научиться с людьми нормально разговаривать.
DaneSoul
21.05.2026 16:25Вообще, подозреваю, что найм ещё одного разраба его уровня, возможно, смог бы решить вопрос. Топовые инженеры любят работать с равными себе.
По тех.уровню напарника можно и чуть ниже, достаточно чтобы понимал его код, но с хорошими софт. скилами, чтобы он был "переводчиком" между звездой и командой.
3aky
21.05.2026 16:25Напарник, это вариант, но скорее проблема в организации работы - видимо отсутствуют “морковки” за время потраченное на подтягивание команды, написание избыточной (с точки зрения самого программиста) документации, и т.д. . Мне, наверное, повезло - ни один из встреченных мной рок-звёзд и близко не был похож на описанного в статье, а вот вчерашних студентов или школьников таких - да, встречал, но даже с ними руководители как-то отношения выстраивали обычно.
akakoychenko
21.05.2026 16:25А зачем тогда команда? Звучит примерно, как "а давайте приделаем трактору дополнительную сверхнизкую передачу, чтобы за ним поспевали кони, тянущие вместе с ним одну упряжку"
Anvente
21.05.2026 16:25Прикол в том, что это не рок-звезды, а скорее аутисты. Таким людям проще с компом общаться, чем с людьми.
У самого такие коллеги были и есть. Ну не может человек объяснить, что и как делать. Инфу из него по отдельным строкам вытягивать приходится. У меня от нынешнего уже целый цитатник всяких умных команд, и он продолжает расти. А физически просто времени нет в этом направлении расти, в том числе потому что тема не моя.
До этого был парень, его после увольнения никто вспомнить не мог, потому что он от людей тупо прятался. Уволился потому что попытались заставить работать иногда с людьми. На новом месте его держат именно как кодера. Я случайно узнал, что он о смене места начал думать, его новые коллеги узнали, и они там переполошились, начали думать, что ему еще улучшить.
И да, проблема ровно та же, что без него никак. Кто то бухтит по этому поводу, но на деле без него в принципе можно обойтись, возможно когда то его и получится заменить, но всегда всплывает какое нибудь говно, которое будет оттягивать этот момент. И то, что казалось парой месяцев может растянуться на годы.
Другой вопрос, что другие не хотят читать. Вот я на каждый чих делаю инструкции. Просто потому что некоторые фишки нужны раз в пару лет, и там о них никто не вспомнит. И вот буквально на той неделе ко мне подошёл коллега, который спросил у меня, как делать его работу. Он тупо с 2024 года этого не делал и забыл, а я задокументил на случай если мне это делать понадобится. Но один хрен он попросил в двух словах расписать, ибо там же на сетевой лезть надо и читать... В итоге я единственный на 4 направления, у кого пара гигов - это просто всякие инструкции, написанные лично. Где то криво, где-то не актуально, но зато есть.
Ioanna
21.05.2026 16:25Лет двадцать назад в IT в основном шли люди такого склада, который вы называете аутизмом. Потому что тогда не было командной работы в этой сфере. И эти люди никуда не делись, они по-прежнему в деле.
GeorgSokolov96
21.05.2026 16:25Сегодня ничего не поменялось. Болтливые экстраверты отвлекают от мыслительного процесса своим бесполезным трепом о том, как вчера попили белковый смузи на Лиговском.
brtpfdvlbpd2
21.05.2026 16:25Именно так. Сам 22 года назад поступил на ИТ-специальность, потому что не люблю людей (это не мешает мне иметь прекрасные отношения с теми, с кем мне хочется их иметь, есть и друзья, и хорошие знакомые, есть и "мы - команда", точнее, подразделение) и хотел по максимуму ограничить контакты с ними, работая с железками, и на известном органе вертел "мягкие навыки". Правда, диагноза "расстройство аутистического спектра" у меня нет (но это не моя заслуга, а их недоработка :-D), и на рок-звезду совсем не тяну.
Ioanna
21.05.2026 16:25Ох, как я вас понимаю! Я поступила на ИТ-специальность 23 года назад. Людей не то чтобы не люблю, но искренне не понимаю, зачем тратить ресурсы на всяческие small talks. Открывать рот надо по делу.
Okeu
21.05.2026 16:25Я долгое время был эникеем, очень много работал с людьми и просто неистово вкачал себе софты. Иногда люблю поболтать с коллегами, например пока ждешь кофе, на обеде, или иногда бывает так: отвлекся от задачи, с коллегой взглядом пересекся - он тоже отвлекся от задачи, и тут вы начали чет обсуждать) Ну а вообще это такая интроверсия с периодическими всплесками экстраверсии, потому что хочется с кем-нибудь поделиться с тем, что ты только что раскопал)) Главное никому не мешать и никого не отвлекать этим. Всему есть мера, время и место.
Еще добавлю, по своему опыту - в таких рандомных болталках очень часто происходил обмен экспертизой и находилось решение какого-то повисшего вопроса
legendasofizma
21.05.2026 16:25В конец истории он там с топором в офис пришёл и всех на мясо изрубил и ещё полгода продавал в элитные рестораны Москвы.
А если по теме, то у нас была прикольная история: CTO по своим связям где-то нашёл и нанял некого хмыря, который был преподнесён как новый блестящий тимлид для одной из свежесозданных команд. Человек с блеском говорил на любые наши технические темы, был звездой Highload++ (и до сих пор входит там в число каких-то организаторов), на кофепоинте увлечённо спорил и объяснял разные сложные штуки про распределённые системы, многофазные коммиты и репликации и прочую дичь с многопоточностью и внутренностями компилятора. Со временем выяснилось, что это его основной скил - блестяще излагать. Брался он за разные начинания, все были брошены на полпути. Команду эту свою к успеху не привёл, продукт не сделали ни в какой версии, один из старожилов даже психанул и уволился. Потом его конечно попёрли каким-то образом, сообщив нам что "объяснили друг другу, что ожидания не оправдались" ну и вроде как подписали даже какие-то формальные отказы от взаимных претензий. Чел был настолько блестяще излагал и умело вовлекал в любые увлекательные обсуждения всех вокруг, что даже когда на него прямо наехали со словами "а вот ты начинал и где результат", то всё кончилось сначала многослойными объяснениями почему так вышло и сверху очередным увлекательным спором о технологиях! Это было любопытное психологическое явление - всем вокруг было очевидно и ясно как день, что имеют дело с ловкачом-продавцом-пылесосов, а поскандалить и довести его агрессивно до ухода или заткнуть никто не решался!
debagger
21.05.2026 16:25Такие люди тоже могут приносить пользу, если их правильно применять. На тех же конференциях бренд компании продвигать, тоже дело.
debagger
21.05.2026 16:25Взяли в группу фронт-меном рок-звезду, а теперь ноют, что он разнес гримерку и набил морду бас-гитаристу. То, что группа теперь собирает стадионы и ездит в мировые туры это, само собой, заслуга менеджмента. Главный вопрос на повестке - как сделать, чтобы фронт-мен стал зайкой, и при этом продолжал собирать стадионы. Я правильно изложил?
Alex_RF
21.05.2026 16:25От этой истории у меня полное ощущение, что в команду полную бездельников наняли нормального инженера. Особенно - код в неявной логике - в которой не кто разобраться немог! Или не хотел? Или началось - вон Ваня больше получает и значит ему нужнее - мы тупо посидим покурим в сторонке - он все сделает. Проблема не в звезде - а в команде - которая отказалась тянуться за звездой. Учитываю ситуацию - что звезду взяли по причине того - что модуль ДОЛЖЕН быть написан - то разгонять нужно команду.
Ioanna
21.05.2026 16:25Мне тоже понравился типаж, описанный в статье. Проблема (если это реальный случай) скорее в том, что команду надо подбирать в том числе и по человеческой совместимости.
taliano
21.05.2026 16:25Ошибка найма «рок‑звезды» — это не история про плохого инженера. Это история про некомпетентного руководителя, который не задался вовремя вопросом: «Как мне потянуть еще одного сотрудника, когда я уже не вывожу шестерых?».
Arhammon
21.05.2026 16:25Уже на второй неделе наш гений отказался писать документацию. Это был первый звоночек, но тимлид не придал ему значения — «главное, чтобы код был».
Ну так повесить будничные задачи и рок звезда обычно превращается в чуть лучше средняка. Хотите рок звезду, нанимайте в пару подмастерье, технического писателя, обслуживающий персонал. Впрочем можете сэкономить и взять только обслуживающий персонал результат будет чем-то похожий...
Kerman
21.05.2026 16:25Если кандидат говорит «мой код самодокументируем» или «не пишу комментарии, они устаревают» — красный флаг.
А что он не так говорит? Уж сколько раз твердили миру, что если пишете комментарий о том, что этот метод делает - значит у вас неправильное название. И да, я видел команды, которые своё неумение в нейминг пытаются компенсировать комментариями. И да, комментарии потом забывают править, они устаревают. Всё правильно.
А остальные комментарии по правилу "всё должно быть документировано" являются просто мусором, забивающим контекстное окно. В итоге код с комментариями понимать гораздо сложнее, потому что комментарии бесполезны, а нейминг отвратительный. Приходится по каждому методу проходить и смотреть, что он там на самом деле делает.
Человек может умеет работать с наименованиями. А у вас сразу ред флаг. Не надо так.
Boneyan
21.05.2026 16:25Вот к чему такое чёрно-белое мышление? Представьте если бы в документации к стандартной библиотеке какого-нибудь языка (выберете на свой вкус) у функций не было никакого описание, только “удачно выбранное” название. Это был бы ад. Имел неудовольствие пользоваться библиотеками, где никакой документации на методах нет. Документация нужна, по крайней мере на внешнем API. И API какой-нибудь подсистемы внутри вашего продукта ничем не хуже API какой-нибудь библиотеки.
В итоге код с комментариями понимать гораздо сложнее, потому что комментарии бесполезны, а нейминг отвратительный
В итоге (если какой-нибудь новичок наслушается такого рода пафоса) будет код и без комментариев и с отвратным неймингом. Что хуже, чем с комментариями и отвратным неймингом.
потому что комментарии бесполезны
Потому что их надо уметь писать, big news. Вы так пишете как-будто комментарии вообще всегда бесполезны, что не соответствует истине. Например в каком нибудь Си, вы предложите называть функцию так? “ReadFileReturnsZeroOnSuccessAndNegativeOneOnError(…)”. А то как же, комментарии писать нельзя!
Kerman
21.05.2026 16:25А давайте не путать публичные библиотечные функции с кодовой базой внутреннего проекта? Там всё-таки разные требования.
Вот к чему такое чёрно-белое мышление?
Вот расставление редфлагов по признаку "не пишу для каждой функции комментарий" и есть чёрно-белое мышление. Или кандидат думает как мы, или он плохой.
Потому что их надо уметь писать
Потому что вырываете слова из контекста. Если комментарий пишется по принципу "всё должно быть задокументировано", то в нём смысла нет. Когда комментарий пишется по принципу "тут надо бы пояснить читателю", то в нём смысла на порядок больше.
ReadFileReturnsZeroOnSuccessAndNegativeOneOnError
"readfile". Не силён в чистых сях, но существуют конвенции. 0, если выполнилось без ошибок, -1, если была ошибка. Конвенциальности в именование не вносятся. Это во-первых.
А во-вторых опять же, не надо путать публичные библиотечные функции с кодовой базой внутреннего проекта.
Boneyan
21.05.2026 16:25Или кандидат думает как мы, или он плохой.
Я если что интервьюера не защищаю, спорю только с вашей позицией.
Когда комментарий пишется по принципу “тут надо бы пояснить читателю”, то в нём смысла на порядок больше.
Я тут с вами согласен, я бы может и не стал с вами спорить, если бы вы свой изначальный коммент более нюансным сделали)
Конвенциальности в именование не вносятся.
Да, очевидно, я специально привёл абсурдный пример. То что функция возвращает 0 или -1 надо писать в комментарии к ней, особенно если кроме -1 у нас есть другие коды ошибок.
не надо путать публичные библиотечные функции с кодовой базой внутреннего проекта
Я и ничего не путаю, я написал чёрным по белому “API какой-нибудь подсистемы внутри вашего продукта ничем не хуже API какой-нибудь библиотеки”. Вы так пишете, как-будто если код внутри нашего проекта, то просто у всех программистов в команде идеальное знание кода и что какая часть делает. Что если у нас один человек пишет модуль, а другой человек этим модулем пользуется? На API этого модуля всё равно не писать комментарии? Но ведь API модуля по сути публичное для второго программиста. Могу предвидеть контраргументы:
Но если люди в одной команде, то им проще спросить друг у друга что метод делает. - Но если что-то записано в комментарии в коде, то оно будет хранится в гите и будет доступно если кто-то новый в команду прийдёт. А то придётся опять у автора кода спрашивать “а как оно работает/как им правильно пользоваться” (если он ещё не уволился).
Во время разработки код часто меняется, поэтому писать комментарии бесполезно, они будут устаревать. - Это уже вопрос дисциплины в команде, такое надо на код ревью отлавливать.
Kerman
21.05.2026 16:25Вы так пишете, как-будто если код внутри нашего проекта, то просто у всех программистов в команде идеальное знание кода и что какая часть делает
Я пишу так, как будто у всех программистов в команде есть представление о предметной области и они хорошо знают язык программирования. И они хотя бы в курсе архитектурных решений того куска кода, на который смотрят.
Этого уровня вполне достаточно, чтобы не засорять код бессмысленными комментариями, и в то же время эта планка достаточно низка, чтобы можно было её считать квалификационным барьером.
Комментарии, рассчитанные на читателя, не обладающего соответствующей квалификацией не делают код понятнее для этого читателя. Но затрудняют работу над проектом тем, кто проходит квалификационный барьер.
cruiseranonymous
21.05.2026 16:25А давайте не путать публичные библиотечные функции с кодовой базой внутреннего проекта? Там всё-таки разные требования.
Да но нет. Требование "понимать должны без меня, а то из отпуска достанут" и там, и там в наличии. Требование "да и я сам должен после отпуска через год захочу вспомнить почему тут так а не эдак не перелопачивая всё" - тоже.
RulenBagdasis
21.05.2026 16:25Уж сколько раз твердили миру, что если пишете комментарий о том, что этот метод делает - значит у вас неправильное название.
Комментарий должен пояснять не что делает метод, а зачем он это делает.
kmatveev
21.05.2026 16:25Точно у метода, вычисляющего длину строки, нужно писать зачем вычислять длину строки?
RulenBagdasis
21.05.2026 16:25Точно. Как минимум, чтобы стало понятно зачем вместо вызова библиотечной функции свой самобытный метод написали.
kmatveev
21.05.2026 16:25А если метод и есть библиотечный?
JustMoose
21.05.2026 16:25Тогда комментарий просто обязателен. Просто в случае библиотек комментарий пишется не рядом с кодом, а в документации. Пример: https://cplusplus.com/reference/algorithm/sort/
Hlad
21.05.2026 16:25Именно так. Не обязательно писать комментарии к каждой строке кода, но к каждому блоку - надо расписывать, нахрена этот блок вообще тут нужен.
Kerman
21.05.2026 16:25Не "зачем это делает". А "почему именно так". Зачем это метод делает решает не метод, а вызывающая сторона. Ей виднее зачем.
Hlad
21.05.2026 16:25Как только код соприкасается с реальным миром - никакой нейминг не поможет. Только комментарии. Расскажите, как неймингом указать, что "это мы делаем потому, что согласно ст. № .... ФЗ №... от .... надо выполнить следующие действия..."
Kerman
21.05.2026 16:25Это прямо идеальный пример, когда комментарий рассказывает "почему именно так", а не "что делает метод". И это правильный комментарий.
Но тут есть один нюанс. Этот комментарий должен быть не перед методом, который делает что-то в соответствии с "№ .... ФЗ", а где-то посередине кода, прямо перед вызовом этого метода. Потому что сам метод не знает о том, зачем его вызывают и в соответствии с каким ФЗ. Он просто делает свою работу, когда от него требуют.
Hlad
21.05.2026 16:25Ну я так понял, человек вообще не писал комментариев, а втирал про самодокументирующийся код.
monco83
21.05.2026 16:25Хватает ситуаций, когда комментарии нужны, но не вида userId // идентификатор пользователя.
Но уметь писать полезные комментарии и не писать бесполезных - это отдельный сложный навык. А если в компании отсутствие комментариев приравнивается к "красному флагу", то могу представить, какой бардак там творится.
deema35
21.05.2026 16:25Дальше — хуже. Модуль, который он разрабатывает, работает идеально, но никто в нём не может изменить ни строчки — слишком неочевидная архитектура и плотный, переусложнённый код.
Дак это он специально что-бы его потом не уволили, когда проект доделают до конца. Блин умный мужик!
«Расскажи случай, когда ты помог младшему коллеге разобраться в сложной теме. Что именно сделал? Как часто это происходит?».
Ну знаете иду я как-то а кофейный автомат у одного джуна купюру зажевал. Ну я его ногой пнул и он кофе налил.
kmatveev
21.05.2026 16:25Ну знаете иду я как-то а кофейный автомат у одного джуна купюру зажевал. Ну я его нагой пнул и он кофе налил.
Бедный джун, автоматы у него купюры зажёвывают, голые коллеги его пинают...
oleg_go
21.05.2026 16:25Остается вопрос - откуда Джун после магического пинка взял то кофе, которое налил
house2008
21.05.2026 16:25Я помню давно давно в прошлой конторе в соседнюю команду как то взяли рок звезду (на фоне остальных). Вроде даже интервьюер сказал ему, что резюме и ответы на собесе лучшие когда либо видели и очень хотел бы видеть его в нашей команде. Человек разумеется принял оффер. В командах были спринты, в конце каждого спринта был общий созвон (zoom) со всеми командами и все должны рассказать, что за спринт сделали важного + потом zoom ретро по спринту. Так этот новый чел просто отказался приходить на эти мероприятия, не знаю чем мотивировал, возможно что код в проде лучшее доказательство что сделал, а не эти спринт ревью, общем саботировал корпоративные практики работы в командах, но в кодинге был боженька. Испытательный срок не прошел конечно. Причем при найме говорили что работе в команде + аджайл.
tenzink
21.05.2026 16:25В конце каждого спринта был общий созвон (zoom) со всеми командами и все должны рассказать, что за спринт сделали важного + потом zoom ретро по спринту
...
Причем при найме говорили что работе в команде + аджайл
Хоть я и не большой фанат аджайла, но такая встреча это же ужас. Это ещё одна неэффективная встреча, маскирующаяся под демо. Ретро, хотя-бы было не со всеми командами?
house2008
21.05.2026 16:25Ретро, хотя-бы было не со всеми командами?
Да, внутри команды конечно (прошу прощения забыл этот момент добавить). Да тут дело не в том, что аджайл это плохо или хорошо, ему сказали как происходит воркфлоу - дэйлики, ретро, демки, брейншторминги и прочее, ну то есть каждый день какой-то движ в зуме. Зачем тогда соглашаться на работу мне не ясно. Я сам этого не люблю, тоже больше интроверт, но это часть игры, просто нужно смириться, я понимал это когда принимал офер. Видимо думал раз рок-звезда то сделают исключение, но это так не работает.
tenzink
21.05.2026 16:25На собеседовании не всегда ясно как это будет работать на практике. Тем более, что одна из целей рекрутера - продать команду. Наверное это успех: не сошлись характерами и быстро это поняли
Sovngard
21.05.2026 16:25Но через пару месяцев начинаются проблемы. Наш вундеркинд категорически отказывается писать документацию («Код сам себя документирует для тех, кто умеет читать»). Code review от него выглядит одинаково: «Это не работает, перепиши с нуля» — без объяснений. Джуниор, попросивший помощи, услышал: «Читай документацию к фреймворку, я не репетитор».
Еще и пользователей консультировать отказался, гад такой.
Badsanta83
21.05.2026 16:25Чел вообще топовый. Удивляет только одно - как он видя вокруг команду в подгузниках, вписался в их песочницу.
tuxi
21.05.2026 16:25Трейдинг, хайлоад... и тут же обязанности "объяснять джуну..." ладно, хрен с ней документацией, может он прав, может он не прав, нужно видеть контекст.
Но человек на таком проекте, которого взяли, чтобы хайлоад реально был - это не про кураторство над джунами. В трейдинге хайлоад либо сразу приносит прибыль, либо его отсутствие сразу приносит убытки и большие.
Это же не тот же хайлоад, когда апишечка стала откликаться на 15% быстрее, чтобы аватарчик в соцсеточке загрузить быстрее. Это реальные бабки, и там битва идет за доли процентов в скорости.
И как чел с опытом таких проектов, сможет что-то объяснить джуну на его, джуна, языке?
Turbo_Pascal_55
21.05.2026 16:25Взяли рок-звезду, разрешили ему накодить кучу, разрешили ничего не документировать, и никому не передавать знания.
Организация и дисциплина в конторе так себе.
mrozov
21.05.2026 16:25Выделяем сложный модуль в отдельный проект, назначаем на него рок-звезду, даём ему возможность подобрать себе коллегу, который “будет тебе помогать” и “закрывать тикеты, пока ты в отпуске”.
Выделяем этих двоих в отдельную команду, с отдельными code-review и митами. Тем самым снимается львиная доля проблем с токсичностью в команде.
Ещё желательно натравить в качестве reviewer-а этого проекта (ведь “он так важен”), вашего архитектора/staff, которого рок-звезда не может просто заткнуть, как недостаточно компетентного, чтобы ему что-то объяснять или доказывать. Его задача - добиться от рок-звезды внутренней архитектуры модуля, которая для понимания не требует ни быть её автором, ни даже просто выдающихся компетенций (хотя требуемые компетенции по прежнему могут значительно превышать компетенции вашей команды, но это отдельный вопрос).
Дальше получается вилка - если рок-звезда и правда неадекват (скорее всего с серьёзным выгоранием), то его можно уволить после того, как “помощник” в целом разберётся в модуле, а в новую команду добрать сильных специалистов. Откуда бюджет на расширение? Ну, если рок-звезде приходится работать по 10+ часов в день, значит либо количественная сложность проблемы недооценивается бизнесом, либо ваша рок-звезда не такая уж и звезда, а просто старый, усталый рокер, а качественная сложность проблемы ему не по зубам.
Ну а если вы просто наняли человека, технический уровень которого сильно превышает уровень остальной команды, то внезапно окажется, что новая команда продуктивна, в ней нормальная рабочая атмосфера и т.д. и т.п. Ну, отлично, получилась кузница кадров, а проблема в запрягании лебедя, рака и щуки куда-то не туда.
Альтернатива - внутренний перевод либо звезды, либо руководителя команды, так как текущий с ситуацией, очевидно, не справляется.
Teml
21.05.2026 16:25Есть такое понятие, "коллективное владение кодом". Оно в команде обязано быть в наличии!
НО если этот самый код (блок кода, модуль, имплементацию) - пишет один человек, а остальные молятся на него, то с какого перепуга этого работягу заставлять писать ещё и документацию?
Пусть тогда остальные тоже потрудятся: хотя бы попытаются этот код понять и задокументировать его.Задокументировать, именно так, как они его поняли - а трудяга, прочитав этот документ, поймёт, поняли его, или не поняли, и что поняли не так.
Пара-тройка итераций - и вот и документация готова и понимание появилось. Без какого-либо взаимодействия и трат времени трудяги на разъяснения и тем более на разработку документов - пусть продолжает писать только код.Сто раз так практиковал - неимоверная эффективность детектед.
Иначе несправедливо получается: работает один, а потом ещё и репетитором, да ещё в письменном виде - книги документов пишет. А остальные на расслабончике проехались, "не понятно им, разъясните, научите".
Pshir
21.05.2026 16:25Очередная история про менеджера, который вообще не понимает, чего он хочет. Тут вроде технический ресурс, а это значит, что размазанные на несколько экранов (или даже статей) советы можно взять и обобщить в одну концепцию. Для начала определи, чего ты хочешь, потом запиши это на бумажке (потому что память - штука очень гибкая), а потом уже действуй, постоянно сверяясь с этой бумажкой. Если в процессе ты заметил, что ты хочешь что-то за пределами этой бумажки, напиши новую, положи рядом и не пытайся делать вид, что именно этого ты хотел изначально.
Если изначально хотелось быстро переписать модуль силами нового сотрудника, потому что имеющиеся неспособны это сделать, то не надо делать вид, что задача была подтянуть команду. Если хотелось не только модуль, но ещё и чтобы команду научили разбираться в коде, в котором сама команда разобраться не способна, то, очевидно, это стоит не меньше, чем вся имеющаяся команда. То есть не меньше 6 средних зарплат по команде, а не 2 с половиной. Не обязательно в руки одного человека, но суммарные затраты будут такими, ничего не поделать - базовая арифметика должна соблюдаться.
diderevyagin
21.05.2026 16:25Модуль, который он разрабатывает, работает идеально, но никто в нём не может изменить ни строчки — слишком неочевидная архитектура и плотный, переусложнённый код.
кто и как ревьювил архитектуру ? кто и как ревьил этот код ?
Ревью - это не только про поиск ошибок и проблем, это и передача знаний.
Складывается впечатление что корень проблем был в процессах, а новый сотрудник выступил лакмусовой бумажкой ...
SilverHorse
21.05.2026 16:25Про суть статьи уже сказали, меня очень триггернуло вот это:
И еще один индикатор — это готовность к парному программированию. Предложите разработчику написать первую задачу в паре с кем‑то из команды. Если он отказывается («я быстрее один») — вы получили одиночку, и в командной разработке это минус.
Я никогда не соглашусь от балды писать что-то в паре с кем-то, особенно свою первую задачу, когда я вообще не обладаю контекстом разработки на новом месте. Парное программирование работает тогда, и только тогда, когда оба разработчика знают контекст задач и проекта в целом, знают, что другой это знает, и знают стиль, уровень и подход друг друга. Иначе это корабль с двумя капитанами, один из которых всегда Барбосса, а другой Джек Воробей. Я на текущем месте пришел на конкретный проект и работал в паре с текущим разработчиком проекта года полтора где-то, потом остался на проекте один, коллегу перекинули в другое место. Так вот, первые несколько месяцев я вливался в контекст, спрашивал, старался глубоко разбирать задачи, первый месяц вообще делал только типичные заявки техподдержки - потому что кодинг это не только написание кода строго по ТЗ, это еще и наполнение собственного контекста и понимания того, как работает бизнес с тем, над чем ты работаешь. Особенно когда над проектом ранее работало шесть разных разработчиков в течение десятка лет, которые писали кто во что горазд, в данных в БД местами авгиевы конюшни, 70% кода - это легаси, от которого надо избавляться, и которое наполовину просто де-факто не используется, а то как написано, и как этим пользуется конечный пользователь - две большие разницы. Сейчас я бы очень хотел кого-нибудь, кто исключит bus factor в отношении меня самого, потому что коллега покинул компанию, но пока что этого нет, а разработчиков с других проектов я знаю, знаю прекрасно их подход и стиль, но на моем проекте меня 95% этих людей просто не заменят. Отчасти потому, что проект имеет в подразделении негласную репутацию "вон той аццкой жести, в которую лучше не лезть". Оставшиеся 5% - те, кто имел какое-то отношение к проекту в последние несколько лет. Да, они конечно реализуют за меня точечные задачи, квалификация никуда не девается, но делать с проектом что-то масштабное - им понадобится минимум тот же месяц на вхождение в проект, с учетом того, что остальным контекстом они уже обладают по факту того, что работают в компании годами. И документация тут не сильно поможет, к слову.
Alesh
21.05.2026 16:25Ну вообще-то описываемый персонаж не будет писать парный код никогда.
С равным это сведется к концептуальным спорам, скорее всего)
А не равный просто не поймет про что тот пишет, а пояснения найдет токсичными, если они будут)
wmlab
21.05.2026 16:25Интересно. А вот в моей текущей команде комментарии в коде запрещены. Если только ты не докажешь ревьюверу, что без комментария вот этот кусок никто не поймет ("465 дней это не опечатка 365, а 15*31"). Я тоже вначале был слегка изумлен, но потом привык. Это правило когда-то ввел вот такой рок-стар, который потом ушел в другую компанию, а правило осталось. Да, пять сухих мартышек и подвешенный банан.
kobets87
21.05.2026 16:25Подтягивать команду и писать идеальный код, два принципиально разных навыка, редко сочетаемые в одном человеке (хотя такое и бывает). Надо на этапе набора, прозрачно ставить для себя и окружающих цели найма. Для топовых специалистов, нужны соответствующие условия, прежде всего уровень окружающих их сотрудников и управленцев должен быть сопоставим, самый лучшие звездные специалисты чахнут попав в слабую команду к бестолковому управленцу. Часто такое встречаю, до абсурда просто доходит, когда один и тот же человек подрабатывая на сторону вне основного рабочего времени творит чудеса, а на основном месте в своем бигтехе и 10% не выдает от номинала. Потому, что любая система стремиться к уровню минимальной энергией и максимальной энтропией. Это наоборот может работать, если в команду к 5 топ экспертам посадить джуна, то он может очень быстро прокачаться.
Dhwtj
Уже противоречие
DMGarikk
Такое бывает, я встречал проекты, причем довольно крупные, написанные в одно лицо
И мне приходилось спасать такие проекты после ухода гения. но пока он на месте, всё работает отлично