Почему сильные разработчики пишут меньше кода?
В айтишной среде давно живёт миф: если ты сильный — значит, ты много пишешь. Гонишь фичи, коммитишь каждый день, двигаешь спринт. Занят — значит полезен.
Но чем старше становится проект, чем сложнее система и чем взрослее команда — тем заметнее становится другая закономерность: по-настоящему крутые разработчики пишут меньше кода. И делают это осознанно.
Сначала это даже раздражает.
🔹Почему он ничего не делает?
🔹 Почему он «тормозит» обсуждение?
🔹 Почему он спорит с задачей, а не реализует?
А потом ты начинаешь видеть ценность.
👉🏻 Эти люди чаще сидят с пустым экраном.
👉🏻 Реже спешат с реализацией.
👉🏻 Гораздо чаще спрашивают “зачем”, прежде чем начать “как”.
И вот почему ⬇
1⃣ Они умеют не делать, если не нужно
Сильный разработчик никогда не прыгает в задачу «на автомате».
Если к нему приходят с задачей: «Реализовать отображение данных на дашборде в реальном времени» — он не бежит сразу поднимать веб-сокет и писать код.
Он спрашивает:
🔹«А зачем это обновление в реальном времени?»
🔹 «Кто будет смотреть на эти данные постоянно?»
🔹 «Насколько критична задержка?»
И выясняется:
👉🏻 это внутренний отчёт, к которому заходят два аналитика раз в день
👉🏻 данные не меняются чаще раза в час
👉🏻 а отображение в реальном времени увеличит нагрузку на сервер
Результат:
❌ задача снимается
✔️ нет лишнего кода
✔️ нет новых багов
✔️ не увеличивается техдолг
✔️ команда сосредоточена на важном
В это время другой разработчик делает «бесполезную, но быструю» фичу — и считает, что он молодец. Но через 3 месяца эту фичу никто не использует. И она остаётся жить в системе, как наследие чьей-то поспешности.
2⃣ Они думают не про задачу, а про систему
Хороший разработчик не просто реализует ТЗ. Он задаёт неудобные вопросы:
🔹 как это влияет на архитектуру?
🔹 насколько это устойчиво при масштабировании?
🔹 не сломает ли это старые модули?
🔹 что если бизнес передумает?
❗Писать код — это не проблема.
Проблема — встроить его так, чтобы не развалить остальное.
Мидлы пишут фичи. Сеньоры строят систему.
3⃣ Они упрощают — не из лени, а из уважения к системе
Сильный разработчик не пытается впечатлить команду стеком.
Он не предлагает тащить новую библиотеку, если можно решить задачу текущими средствами. Не выносит в микросервис, если модуль спокойно живёт внутри монолита.
Он думает так:
🔹 «Эта технология точно нужна или просто “хочется попробовать”?»
🔹 «Это упростит поддержку — или наоборот, усложнит?»
🔹 «Через полгода кто-то другой сможет с этим разобраться?»
📌 Вместо того чтобы писать своё, он переиспользует.
📌 Вместо архитектурного «шоу» — предлагает решение, которое реально можно развивать.
📌 Вместо “сделаем красиво” — говорит “давайте сделаем надёжно”.
❌ Он не упрощает ради скорости.
✅ Он упрощает ради устойчивости.
4⃣ Они знают, что каждая строка — это баг, ответственность и долг
🔹 Любая новая строчка = новая точка отказа
🔹 Новый модуль = больше зависимости
🔹 Новый фреймворк = выше порог входа
🔹 Новая фича = больше поддержки
Опытные инженеры обожглись на этом. И теперь для них меньше кода — это плюс, а не минус.
❌ Они не меряют ценность строками.
✅ Они меряют устойчивостью системы и скоростью развития продукта.
📌 Что с этим делать?
🔹Если вы джун — да, надо писать. Учиться. Тренировать руку.
🔹Если вы мидл — важно научиться не просто решать, а задавать вопросы.
🔹Если вы уже упрётесь в потолок — вы поймёте: самая крутая фича — та, которую вы не стали делать.
👉🏻 Потому что она была не нужна.
👉🏻 Потому что вы подумали наперёд.
👉🏻 Потому что продукт важнее строк.
💡 Вывод:
Сильный разработчик — это не тот, кто много пишет. Это тот, кто точно знает, когда писать не нужно.
✔️ Кто фильтрует задачи
✔️ Думает на 3 итерации вперёд
✔️ Упрощает, а не усложняет
✔️ Уважает архитектуру, а не демонстрирует стек
✔️ Понимает, что он не кодит — он строит систему
Скорость — важна. Но без зрелости она превращается в скорость накопления технического долга. Хотите расти — тренируйтесь не только писать. Учитесь останавливаться, думать и отказываться. Это — и есть уровень.
