Tony pro IT 👨🏻‍💻

Почему сильные разработчики пишут меньше кода?

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

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

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

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

И вот почему ⬇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошая идея ≠ хороший бизнес: 7 причин, почему даже сильные задумки проваливаются

Часто вы слышали такие фразы?
💬 У меня идея, аналогов нет. Это точно выстрелит!
💬 А давайте сделаем платформу типа Авито, но только для юристов.
💬 Это почти как Notion, но заточено под бухгалтеров.

И часто даже всё звучит логично. Видна боль, понятна аудитория, в голове уже рисуется прототип. Но ты ловишь себя на мысли: «Что-то здесь уже было...»

👉🏻 Слишком знакомо.
👉🏻 Слишком уверенно.
👉🏻 Слишком “по верхам”.

Потому что хороших идей действительно много. Но вот хорошей реализации — единицы.

📌 Идея — это не стартап.
📌 Идея — это не ценность.
📌 Идея — это максимум 5% от успеха. Остальное — исполнение.
А оно у большинства сыпется.

Вот 7 причин, по которым даже отличные идеи превращаются в ничто ⬇

1️⃣ Слишком рано. Ты готов, рынок — нет.
Придумали инновационную фичу? AI-бот, который сам оформляет заказы и переписывается с поставщиками? Вы видите пользу. Вы верите в идею. А рынок смотрит и думает: «А зачем нам это всё?»

🔥 Продукт «вперёд времени» хорош в фантастике.
В реальности он никому не нужен — пока люди не дозреют, пока процессы не изменятся, пока у бизнеса не появится запрос. А ждать полтора года до «созревания» — дорого.

2️⃣ Слишком поздно. Ты один из ста.
Вторая крайность. Тренд уже на пике, все туда ломанулись — а вы только начали.

🔹 Уже есть лидеры.
🔹 У них узнаваемость, бюджеты, процесс.
🔹 А вы говорите: «Ну у нас UX получше и приложение грузится быстрее».

Окей. А зачем мне переходить от привычного сервиса к вам? Быть «чуть лучше» — это не причина смены продукта. А быть 11-м клоном — ещё и дорого. Даже с деньгами. Даже с командой.

3️⃣ Рынок не тот.
Классика: нашли боль, начали пилить. А потом выясняется, что:

🔹 Никто не готов за это платить.
🔹 Клиенты делают это вручную раз в месяц и их всё устраивает.
🔹 Автоматизация просто не нужна, особенно за деньги.

4️⃣ Команда не тянет.
Да, звучит грубо. Но это реальность. Сильная идея требует сильной команды. Не только по скиллам, но и по подходу.

Вы удивитесь, сколько команд:
❌ боятся выкатывать на прод
❌ не работают с фидбэком
❌ кодят по 2 месяца без проверок
❌ вечно «оптимизируют архитектуру»

А фаундер в этот момент: «Рынок ждёт! Где продажи?» Не вытягивает команда — идея рассыпается. Тут не про то, какие все умные, а про то, кто умеет делать.

5️⃣ Маркетинг — на уровне “потом сделаем лендинг”.
Часто продукт объективно лучше. Удобнее. Быстрее. Но маркетинг не умеет за 15 секунд объяснить, зачем он нужен.

🔹 Вы не продадите AI-сервис, если всё, что есть — это “AI-сервис для автоматизации”.
🔹 Вы не убедите клиента, если ваша посадка начинается со слов «Улучшите эффективность на 27%».

Продажа — это часть продукта. Не дополнение. Она в интерфейсе, в тексте, в онбординге, в голосе саппорта.

6️⃣ MVP с костылями → костыли на годы.
«Ща накидаем быстро MVP, проверим идею, потом перепишем». Всё, что пишется “временным”, живёт вечно. Потому что пока оно работает — его боятся трогать. А как только ломается — уже нет ни автора, ни понимания, что под капотом.

👉🏻 Рефакторинг откладывается на потом. MVP превращается в труп.

7️⃣ Нет фокуса — нет результата
Вы выпустили первую версию. Работает. Пользователи заходят.

И тут начинается:
💬 «Добавим ещё такую фичу!»
💬 «А давайте корпоративную версию!»
💬 «А давайте параллельно делать маркетплейс!»

В итоге:
🔹 Никто не понимает, где центр продукта.
🔹 Все распыляются.
🔹 Идея тонет в хотелках.

Фокус — ключ к результату. Без него даже сильная команда теряет темп.

💡Вывод:
✅ Хорошая идея — это только старт.
✅ Всё остальное — это исполнение, команда, фокус и готовность быстро тестировать.
✅ Хотите результат — стройте не продукт, а систему, способную проверять, учиться и масштабироваться.

Идея — не конкурентное преимущество.

😈Как уволить сотрудника профессионально: корректно, без конфликтов и с уважением, сохранив командный дух и репутацию компании?

Узнайте на бесплатном вебинаре онлайн-курса «Team Lead» - «Пора на выход: как тимлиду сказать это сотруднику правильно»: регистрация 

Программа вебинара:
- Когда действительно пора расставаться?
- Ошибки тимлидов при увольнении.
- Как подготовиться к увольнению?
- Корректное проведение увольнительной беседы.

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

🤝После вебинара продолжите обучение на курсе со скидкой и даже в рассрочку!

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

erid: 2W5zFJC8aXi

Розыгрыш MacBook Air

30+ экспертов из IT и digital собрались в одной папке, чтобы научить тебя оформлять кейсы, находить общий язык с заказчиками, управлять проектами и развивать личный бренд.

Подпишись на них и получи один из 3 призов:

🏆Главный приз — MacBook Air (M2).
🏆2 место: разбор карьерного трека от креативного директора Пиробайт.
🏆3 место: консультация по карьерному росту от секретного эксперта.

Как участвовать:

1. Подпишись на папку: https://t.me/addlist/fEvzl5khQT8yZTcy
2. Подтверди участие в боте
3. Отправь ссылку на бота своим друзьям — за каждого приглашённого человека ты получишь +1 призовой билет

🗓 26 апреля в прямом эфире узнаешь, какой приз достался тебе

Выполнил все условия? Тогда включай уведомления — и до связи 🚀

Участников: 6
Призовых мест: 3
Дата розыгрыша: 10:00, 26.04.2025 MSK (26 дней)

Розыгрыш MacBook Air

30+ экспертов из IT и digital собрались в одной папке, чтобы научить тебя оформлять кейсы, находить общий язык с заказчиками, управлять проектами и развивать личный бренд.

Подпишись на них и получи один из 3 призов:

🏆Главный приз — MacBook Air (M2).
🏆2 место: разбор карьерного трека от креативного директора Пиробайт.
🏆3 место: консультация по карьерному росту от секретного эксперта.

Как участвовать:

1. Подпишись на папку: https://t.me/addlist/fEvzl5khQT8yZTcy
2. Подтверди участие в боте
3. Отправь ссылку на бота своим друзьям — за каждого приглашённого человека ты получишь +1 призовой билет

🗓 26 апреля в прямом эфире узнаешь, какой приз достался тебе

Выполнил все условия? Тогда включай уведомления — и до связи 🚀

Участников: 21
Призовых мест: 3
Дата розыгрыша: 10:00, 26.04.2025 MSK (26 дней)

Розыгрыш MacBook Air

30+ экспертов из IT и digital собрались в одной папке, чтобы научить тебя оформлять кейсы, находить общий язык с заказчиками, управлять проектами и развивать личный бренд.

Подпишись на них и получи один из 3 призов:

🏆Главный приз — MacBook Air (M2).
🏆2 место: разбор карьерного трека от креативного директора Пиробайт.
🏆3 место: консультация по карьерному росту от секретного эксперта.

Как участвовать:

1. Подпишись на папку: https://t.me/addlist/fEvzl5khQT8yZTcy
2. Подтверди участие в боте
3. Отправь ссылку на бота своим друзьям — за каждого приглашённого человека ты получишь +1 призовой билет

🗓 26 апреля в прямом эфире узнаешь, какой приз достался тебе

Выполнил все условия? Тогда включай уведомления — и до связи 🚀

Участников: 106
Призовых мест: 3
Дата розыгрыша: 10:00, 26.04.2025 MSK (25 дней)

Почему багов становится больше, когда команда усиливается? 🤔

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

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

📌Почему так происходит и как этого избежать?
Делюсь ключевыми системными принципами, которые позволяют масштабировать команду без потерь в качестве и скорости:

1⃣ Закон Брукса никто не отменял
«Добавление ресурсов в поздний проект только замедляет его завершение»

Каждый новый разработчик — это не +1 к скорости. Это +1 к нагрузке на менторов, процессы, синхронизацию. Чтобы масштабирование работало, нужна операционная готовность к обучению, встраиванию и поддержке новых людей. Без этого «ускорение» приводит к перегрузке.

2⃣ Коммуникации растут нелинейно
Увеличение команды = экспоненциальный рост точек согласования:
🔹 3 разработчика — 3 связи
🔹 6 разработчиков — уже 15
🔹 10 — больше 40

Без структурирования общения и чётких зон ответственности вы получаете ⬇
🔹 дублирование задач
🔹 конфликты при слиянии
🔹 замедление из-за “переспрашиваний” и нестыковок.

💡Решение — гибкое деление на команды, прописанные интерфейсы, взаимодействия и регулярные встречи по вертикали.

3⃣ Ввод в команду — не формальность
Быстрый и качественный ввод новых специалистов - критично важен.

Что должно быть?
🔹погружение в архитектуру
🔹разбор бизнес-ограничений
🔹знакомство с правилами командной разработки
🔹разъяснение процессов принятия решений

Эффективное включение в работу сокращает баги, повышает вовлечённость и ускоряет результат.

4⃣ Инфраструктура должна быть готова к росту
Больше людей - больше изменений в коде, больше задач и тестов.

Что нужно предусмотреть:
🔹 автоматическая проверка кода перед объединением
🔹 стабильная тестовая среда
🔹 возможность включать и выключать отдельные функции новых релизов
🔹 контроль за тем, что изменения не ломают старое

Техническая основа - это то, что позволяет масштабироваться без потерь.

5⃣ Много людей ≠ гарантия скорости
Очень часто команда после усиления впадает в иллюзию:
— “Нас стало больше — мы точно справимся быстрее!”

Но в реальности:
🔹 без процессов — больше людей = больше координации,
🔹 без ролей — больше мнений = больше хаоса,
🔹 без приоритетов — больше задач = меньше результата.

Чтобы команда росла продуктивно — нужен процессный скелет.

📌 Что работает на практике:
✔ Полноценное введение в проект - от структуры кода до понимания продукта
✔ Чек-листы для проверки кода и двойная проверка изменений
✔ Деление на мини-команды
✔ Постоянная тестовая среда, где можно проверять изменения до релиза
✔ Планирование задач не на 100% времени, а на 70–80% — с учётом поддержки и форс-мажоров

💡Вывод:
Расширение команды ≠ рост скорости. Это рост сложности. И чтобы он не превратился в хаос — стройте процессы заранее, а не по ходу.

😎Как руководителю вовремя отследить возможные проблемы и эффективно предотвратить их?

Узнайте на бесплатном вебинаре онлайн-курса «Delivery Manager» - «Это диагноз: контроль здоровья IT-проектов»: регистрация 

Узнаем на бесплатном вебинаре:
- Чем отличается управление портфелем проектов от управления одним проектом
- Какую информацию о проекте можно считать достоверной и как определить необходимые метрики здоровья именно вашего проекта
- Как поставить процесс сбора такой информации на рельсы и в дальнейшем эффективно ее анализировать

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

🤝После вебинара продолжите обучение на курсе со скидкой и даже в рассрочку!

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

erid: 2W5zFHNfy4t

Почему не каждый сильный разработчик станет хорошим тимлидом

До сих пор жив миф: если ты крутой разработчик, логичный следующий шаг — стать тимлидом. Но это не так. Более того, попытка посадить в эту роль не того человека может разрушить и проект, и команду, и самого разработчика.

Сегодня расскажу, почему переход от senior-разработчика к тимлиду — это не эволюция, а смена профессии. И почему не каждый должен идти в эту сторону ⬇️

🔹 Сильный разработчик ≠ хороший тимлид

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

Но хороший тимлид должен:
🔸 выстраивать процессы,
🔸 работать с командой,
🔸 объяснять, договариваться, убеждать,
🔸 видеть проект как систему, а не только как код,
🔸 брать ответственность за результат других.

Это совсем другая работа.

🔹 Почему сильные разработчики часто «ломаются» как тимлиды?

1️⃣ Не умеют делегировать.
Они привыкли быть лучшими. Им сложно доверить задачу другому, особенно если тот делает медленнее или хуже. В итоге они берут всё на себя и сгорают.

2️⃣ Ожидают от других такого же уровня.
«Почему он не понимает с первого раза?» — думает бывший сеньор, забывая, сколько лет он шёл до этого уровня. Вместо развития команды — раздражение и микроменеджмент.

3️⃣ Избегают разговоров.
Они не хотят обсуждать конфликты, фидбек, мотивацию. А без этого лидерство невозможно. Код не чувствует, а люди — да.

4️⃣ Фокус теряется.
Вместо того чтобы закрывать задачи тимлида, они продолжают «разрабатывать» — потому что это зона комфорта. А процессы и люди — остаются без внимания.

🔹 Можно ли подготовить разработчика к роли тимлида?
Да. Но только если у человека есть мотивация. Вот что я проверяю, прежде чем обсуждать рост до тимлида:

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

🔹 А что, если в команде нет сильного senior, только «среднячок»?
Это нормально. Тимлид не обязан быть самым крутым кодером.

Иногда идеальным тимлидом становится middle с сильными soft skills, который умеет:
🔸 фасилитировать,
🔸 держать фокус команды,
🔸 разруливать конфликты,
🔸 задавать темп,
🔸 и просто быть «клеем», который связывает всех.

А код можно доверить техлиду или старшему разработчику.

🔹 Хочешь вырастить тимлида — не торопи
У меня есть правило: предлагать роль тимлида, пока человек сам не начал вести себя как тимлид.

Сначала — действия, потом — должность.

Я даю «пробные» задачи:
🔸 помочь джуну
🔸 предложить улучшения в процессе
🔸 решить конфликт внутри команды
🔸 самостоятельно собрать и провести созвон с аналитиком или заказчиком
🔸 провести демо фичи или рассказ на внутреннем созвоне или созвоне с клиентом
🔸 декомпозировать сложную задачу и взять на себя организацию её выполнения

Если человек берёт и делает — мы говорим про рост.

🔹 А если не хочет — это нормально?
Да, есть достаточно много других путей развития. Даже после уровня сеньора можно расти в экспертизе — углубляться в архитектуру, становиться техлидом без управления людьми, менторить, брать ответственность за ключевые решения и влиять на продукт.
Можно совмещать роли: быть ментором, вести архитектуру, но не заниматься наймом или планированием.

Развитие — это не только про управление. Иногда лучший путь — углубление в то, что тебе действительно интересно.

💡Вывод
Сильный разработчик — это не тимлид по умолчанию.
Роль лидера требует другой оптики: не про «как сделать лучше», а про «как сделать так, чтобы команда делала лучше».

Не торопитесь. Наблюдайте. Давайте пробовать. И помните: вырастить тимлида — это не назначить, а раскрыть.