Эта статья — безусловный победитель в номинации "Холиварная статья на Хабре 2025 года". Уровень субъективности, выданной за универсальную "зрелость" и "рациональность", просто пробил потолок. И да, автор прав: с такими, как он, спорить действительно бесполезно. Надо просто выполнить "commit, push" и протереть пыль с резюме, потому что работать в такой команде - сомнительное удовольствие. Поэтому я обращаюсь не к автору, это очевидно бесполезно, а к тем, кто прочитает его "философию тишины". Философия автора не имеет ничего общего со зрелостью. Это скорее набор правил для токсичной, авторитарной среды, где статус важнее идеи. Прощай, Менторство. Он фактически заявляет: "Если новичок что-то сделал не так, я исправлю это молча. Пусть сам догадывается, почему моё решение лучше, мне лень объяснять". Он максимально эффективно устранили обучение и рост в своей команде. Настоящая зрелость - это способность быстро и уважительно объяснить причину изменения, а не просто демонстрировать "превосходство" через коммит. Автор поставил под сомнение парное программирование, архитектурное мышление. Он превращает разработчика в писаря, а не автора. Путь к архитектурному мышлению лежит через дискуссии, через защиту своих решений и критику чужих. Модель автора низводит разработчика до "болтика", которому запрещено думать о контексте и предлагать альтернативы. Если он никогда не "спорит" о границах и шаблонах, он никогда не станет архитектором. А тут как в армии плох тот солдат, который не мечтает стать генералом. Так же и тут плох тот разработчик кто не мечтает стать архитекторам. Это пожалуй самая важная вещь в программировании. Каждый программист архитектор в контексте своего решения, будь это метод, или класс, или пакет. Если разработчик не спорит, а просто делает как надо он не программист, он писарь. Как птица-секретарь. Иерархия, а не Коллаборация. Автор гордится тем, что "старшие правят, младшие спрашивают". Это чистый взгляд сверху вниз. А что, если Junior нашел более эффективное решение или ошибку в "идеальном" коде старшего? Его "рациональность" предписывает ему молчать и принять решение стершего, основанное на статусе, а не на лучшем аргументе. И главное в программировании старший или senior - это весьма относительное понятие. Старший где? В этой команде? В этом, конкретно, приложении? В мире? Старший по выслуге лет? Или старший потому что его код повысил прибыль проекта в N - раз? Что вообще следует понимать под словом "старший"?
Подводя итог: Если единственная эффективная коммуникация в команде автора это молчаливое принятие чужих коммитов, то это не "зрелость". Это сигнал о том, что коллектив работает на выгорание, где "спор" заменен страхом и авторитаризмом. Продолжай кодить, а не спорить.
Вообще у меня сложилось ощущение, что автор работает не среди плохих или сильных разработчиков. Он работает в плохо выстроенной команде. И вопросы тут не в том кто такие программисты, а кто там в менеджерах.
И вот о статусе, кстати. Опять живой пример. Прямо сейчас я проходил процессинг по найму в одну команду. Первый день, что-то напутали, я вышел в одного числа, а вроде как команда ожидала другое число. Да, такое бывает. В итоге мне не дали доступы. Сказали отправляться домой и ждать. Я поехал, но предварительно уточнил на счет задачи которая у меня будет на испытательном сроке (они практикуют на испытательном сроке давать реальную бизнес-задачу и по итогам её выполнения оценивать твой скил). Я мог не уточнять о задаче, мне никто не предложил её обсудить. Но я сам проявил инициативу и уточнил. Более того, оценив задачу, я понял что большую её часть можно сделать вообще в отрыве от их инфраструктуры. Сделать её в своем контексте. DDD на практике, так сказать. Итог: конец первого рабочего дня, у меня уже полностью готова бэкнд часть задачи изолировано. Получив доступы я реализовал пару описательных классов-адаптеров и интегрировал бесшовно в их приложение свое решение за час. А доступы я ждал почти 3 дня. То есть по сути я могу тупо ждать 3 дня. Но я пошел иным путем. И конечно, разработчиков моё решение ввело в ступор. Даже опытных, которые там более 6 лет работают. Но обсуждая решение, я аргументировал это тем, что цель состояла не в демонстрации того как я могу "красиво" написать независимый код. Это решение было продиктовано условиями в которых я оказался. Я сэкономил бизнесу деньги и время, вопреки их бюрократическим провалам. Junior на моем месте скорее всего бы тупо ждал, Meaddle вероятно ознакомившись с задачей, а Senior написал решение как сделал я. Но вопрос даже не в подходе к реализации. А в том: а каждый бы Senior проявил инициативу и спросил о деталях задачи в первой рабочий день, несмотря на то, что привычный flow процесса онбординга нарушен? Думаю что нет. А это и есть настоящая зрелость разработчика. А не "режим тишины" и молчаливые "комиты". Зрелость - это не выбормежду разговором и действием, это синтезих обоих. Зрелый разработчик не является пассивным участником плохого процесса, а активно его исправляет/обходит во благо бизнеса. Я с автором согласен в одном. Спорить в комментариях - бесполезно. И в этом он прав, просто говорит об этом как то странно. Если ты молча написал код, сделал коммит, тебя начинают критиковать в комментариях - я бы тоже не спорил, а переписал. Но не потому, что я опытный и зрелый разработчик. Я бы не такое заключение сделал. Я бы сделал заключение, что я тупой. Потому что зрелый и опытный, сперва предлагает, спорит, обсуждает, рождает истину, а уже потом появляется коммт с готовым решением.
Эта статья — безусловный победитель в номинации "Холиварная статья на Хабре 2025 года". Уровень субъективности, выданной за универсальную "зрелость" и "рациональность", просто пробил потолок. И да, автор прав: с такими, как он, спорить действительно бесполезно. Надо просто выполнить "commit, push" и протереть пыль с резюме, потому что работать в такой команде - сомнительное удовольствие. Поэтому я обращаюсь не к автору, это очевидно бесполезно, а к тем, кто прочитает его "философию тишины". Философия автора не имеет ничего общего со зрелостью. Это скорее набор правил для токсичной, авторитарной среды, где статус важнее идеи. Прощай, Менторство. Он фактически заявляет: "Если новичок что-то сделал не так, я исправлю это молча. Пусть сам догадывается, почему моё решение лучше, мне лень объяснять". Он максимально эффективно устранили обучение и рост в своей команде. Настоящая зрелость - это способность быстро и уважительно объяснить причину изменения, а не просто демонстрировать "превосходство" через коммит.
Автор поставил под сомнение парное программирование, архитектурное мышление. Он превращает разработчика в писаря, а не автора.
Путь к архитектурному мышлению лежит через дискуссии, через защиту своих решений и критику чужих. Модель автора низводит разработчика до "болтика", которому запрещено думать о контексте и предлагать альтернативы. Если он никогда не "спорит" о границах и шаблонах, он никогда не станет архитектором. А тут как в армии плох тот солдат, который не мечтает стать генералом. Так же и тут плох тот разработчик кто не мечтает стать архитекторам. Это пожалуй самая важная вещь в программировании. Каждый программист архитектор в контексте своего решения, будь это метод, или класс, или пакет. Если разработчик не спорит, а просто делает как надо он не программист, он писарь. Как птица-секретарь. Иерархия, а не Коллаборация. Автор гордится тем, что "старшие правят, младшие спрашивают". Это чистый взгляд сверху вниз. А что, если Junior нашел более эффективное решение или ошибку в "идеальном" коде старшего? Его "рациональность" предписывает ему молчать и принять решение стершего, основанное на статусе, а не на лучшем аргументе. И главное в программировании старший или senior - это весьма относительное понятие. Старший где? В этой команде? В этом, конкретно, приложении? В мире? Старший по выслуге лет? Или старший потому что его код повысил прибыль проекта в N - раз? Что вообще следует понимать под словом "старший"?
Подводя итог: Если единственная эффективная коммуникация в команде автора это молчаливое принятие чужих коммитов, то это не "зрелость". Это сигнал о том, что коллектив работает на выгорание, где "спор" заменен страхом и авторитаризмом. Продолжай кодить, а не спорить.
Вообще у меня сложилось ощущение, что автор работает не среди плохих или сильных разработчиков. Он работает в плохо выстроенной команде. И вопросы тут не в том кто такие программисты, а кто там в менеджерах.
И вот о статусе, кстати. Опять живой пример. Прямо сейчас я проходил процессинг по найму в одну команду. Первый день, что-то напутали, я вышел в одного числа, а вроде как команда ожидала другое число. Да, такое бывает. В итоге мне не дали доступы. Сказали отправляться домой и ждать. Я поехал, но предварительно уточнил на счет задачи которая у меня будет на испытательном сроке (они практикуют на испытательном сроке давать реальную бизнес-задачу и по итогам её выполнения оценивать твой скил). Я мог не уточнять о задаче, мне никто не предложил её обсудить. Но я сам проявил инициативу и уточнил. Более того, оценив задачу, я понял что большую её часть можно сделать вообще в отрыве от их инфраструктуры. Сделать её в своем контексте. DDD на практике, так сказать. Итог: конец первого рабочего дня, у меня уже полностью готова бэкнд часть задачи изолировано. Получив доступы я реализовал пару описательных классов-адаптеров и интегрировал бесшовно в их приложение свое решение за час. А доступы я ждал почти 3 дня. То есть по сути я могу тупо ждать 3 дня. Но я пошел иным путем. И конечно, разработчиков моё решение ввело в ступор. Даже опытных, которые там более 6 лет работают. Но обсуждая решение, я аргументировал это тем, что цель состояла не в демонстрации того как я могу "красиво" написать независимый код. Это решение было продиктовано условиями в которых я оказался. Я сэкономил бизнесу деньги и время, вопреки их бюрократическим провалам. Junior на моем месте скорее всего бы тупо ждал, Meaddle вероятно ознакомившись с задачей, а Senior написал решение как сделал я. Но вопрос даже не в подходе к реализации. А в том: а каждый бы Senior проявил инициативу и спросил о деталях задачи в первой рабочий день, несмотря на то, что привычный flow процесса онбординга нарушен? Думаю что нет. А это и есть настоящая зрелость разработчика. А не "режим тишины" и молчаливые "комиты". Зрелость - это не выбор между разговором и действием, это синтез их обоих. Зрелый разработчик не является пассивным участником плохого процесса, а активно его исправляет/обходит во благо бизнеса. Я с автором согласен в одном. Спорить в комментариях - бесполезно. И в этом он прав, просто говорит об этом как то странно. Если ты молча написал код, сделал коммит, тебя начинают критиковать в комментариях - я бы тоже не спорил, а переписал. Но не потому, что я опытный и зрелый разработчик. Я бы не такое заключение сделал. Я бы сделал заключение, что я тупой. Потому что зрелый и опытный, сперва предлагает, спорит, обсуждает, рождает истину, а уже потом появляется коммт с готовым решением.