В айтишной среде давно живёт миф: если ты сильный — значит, ты много пишешь. Гонишь фичи, коммитишь каждый день, двигаешь спринт. Занят — значит полезен.

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

Сначала это даже раздражает. 🔹Почему он ничего не делает? 🔹 Почему он «тормозит» обсуждение? 🔹 Почему он спорит с задачей, а не реализует?

А потом ты начинаешь видеть ценность. 👉🏻 Эти люди чаще сидят с пустым экраном. 👉🏻 Реже спешат с реализацией. 👉🏻 Гораздо чаще спрашивают “зачем”, прежде чем начать “как”.

И вот почему ⬇

1⃣ Они умеют не делать, если не нужно Сильный разработчик никогда не прыгает в задачу «на автомате». Если к нему приходят с задачей: «Реализовать отображение данных на дашборде в реальном времени» — он не бежит сразу поднимать веб-сокет и писать код.

Он спрашивает: 🔹«А зачем это обновление в реальном времени?» 🔹 «Кто будет смотреть на эти данные постоянно?» 🔹 «Насколько критична задержка?»

И выясняется: 👉🏻 это внутренний отчёт, к которому заходят два аналитика раз в день 👉🏻 данные не меняются чаще раза в час 👉🏻 а отображение в реальном времени увеличит нагрузку на сервер

Результат: ❌ задача снимается ✔️ нет лишнего кода ✔️ нет новых багов ✔️ не увеличивается техдолг ✔️ команда сосредоточена на важном

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

2⃣ Они думают не про задачу, а про систему Хороший разработчик не просто реализует ТЗ. Он задаёт неудобные вопросы: 🔹 как это влияет на архитектуру? 🔹 насколько это устойчиво при масштабировании? 🔹 не сломает ли это старые модули? 🔹 что если бизнес передумает?

❗Писать код — это не проблема.Проблема — встроить его так, чтобы не развалить остальное. Мидлы пишут фичи. Сеньоры строят систему.

3⃣ Они упрощают — не из лени, а из уважения к системе Сильный разработчик не пытается впечатлить команду стеком. Он не предлагает тащить новую библиотеку, если можно решить задачу текущими средствами. Не выносит в микросервис, если модуль спокойно живёт внутри монолита.

Он думает так: 🔹 «Эта технология точно нужна или просто “хочется попробовать”?» 🔹 «Это упростит поддержку — или наоборот, усложнит?» 🔹 «Через полгода кто-то другой сможет с этим разобраться?»

📌 Вместо того чтобы писать своё, он переиспользует. 📌 Вместо архитектурного «шоу» — предлагает решение, которое реально можно развивать. 📌 Вместо “сделаем красиво” — говорит “давайте сделаем надёжно”.

❌ Он не упрощает ради скорости. ✅ Он упрощает ради устойчивости.

4⃣ Они знают, что каждая строка — это баг, ответственность и долг 🔹 Любая новая строчка = новая точка отказа 🔹 Новый модуль = больше зависимости 🔹 Новый фреймворк = выше порог входа 🔹 Новая фича = больше поддержки

Опытные инженеры обожглись на этом. И теперь для них меньше кода — это плюс, а не минус.

❌ Они не меряют ценность строками. ✅ Они меряют устойчивостью системы и скоростью развития продукта.

📌 Что с этим делать? 🔹Если вы джун — да, надо писать. Учиться. Тренировать руку. 🔹Если вы мидл — важно научиться не просто решать, а задавать вопросы. 🔹Если вы уже упрётесь в потолок — вы поймёте: самая крутая фича — та, которую вы не стали делать. 👉🏻 Потому что она была не нужна. 👉🏻 Потому что вы подумали наперёд. 👉🏻 Потому что продукт важнее строк.

💡 Вывод: Сильный разработчик — это не тот, кто много пишет. Это тот, кто точно знает, когда писать не нужно. ✔️ Кто фильтрует задачи ✔️ Думает на 3 итерации вперёд ✔️ Упрощает, а не усложняет ✔️ Уважает архитектуру, а не демонстрирует стек ✔️ Понимает, что он не кодит — он строит систему

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