Где стеклянный потолок в карьере разработчика и как его пробить?

📺 Обсудим это на открытом митапе [Технический Лидер] с Павлом Вейником.

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

А ещё ответим на вопросы:
- Куда расти сеньору и нужно ли?
- Как меняются hard и soft навыки по мере роста?
- Как оценивают уровень разработчиков в разных компаниях?
- Насколько больше рядовых разработчиков зарабатывают техлиды и архитекторы?
- Чего ждать от 2025 года в IT?

📆 Ждем вас 19 декабря в 19:00(GMT+3)!

🔗 Регистрируйтесь по ссылке!

Друзья, нынче Трепы редкое удовольствие! Первый и последний в декабре начинается через 30 мин. Приходите обсудить с Юрой Морозовым и Максим Симоненко тему "Вендор-лок против опенсорса". Подробнее 🙌

Что умеет техлид, чего не умеет сеньор?

Senior – это про персональное мастерство. Он отлично пишет код и решает технические задачи почти любой сложности. Его фокус – конкретные проблемы и как их решить исходя из своего богатого опыта.

Отличие техлида от сеньора – не в глубине технических знаний, а масштабе решаемых задач и степени вовлеченности в бизнес-сторону разработки. Он отвечает не только за свои технические решения, но и за практики, которые используют в команде, взаимодействие с другими командами и отстаивание решений перед бизнесом.

19 декабря на митапе [Технический Лидер] подробно поговорим о профессиональном росте разработчика, как его добиться в реалиях современного рынка IT, и чего ждать от этого рынка в 2025 году. Регистрируйтесь по ссылке!

⚙️ Какие hard skills прокачивать, чтобы стать техлидом?

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

Паттерны и законы распределенных систем. Это понимание шаблонов, которые можно использовать в распределенных системах для решения конкретных проблем, и как их организовать в системе.

Кросс-функциональные знания. Scalability, performance, security, мониторинг, поддержание продакшена.

System design и архитектурный vision. Уметь не только нарисовать схему “идеальной” архитектуры, но и понимать, как потребности конкретного бизнеса и возможности конкретной команды влияют на архитектуру.

💡 Что насчет soft skills?

Лидерство и способность брать на себя ответственность. Этот навык – ключевой для профессионального и карьерного роста, особенно выше senior.

Умение объяснять и отстаивать свои решения. Техлиду время от времени приходится спорить как с представителями бизнеса, так и с разработчиками.

Понимание бизнеса и взаимодействие с ним. Техлид должен быть переводчиком с бизнесового языка на инженерный и наоборот.

Создание и поддержание процессов. Ответственность техлида – качество кода всей команды. Без процессов – код-ревью, тестирования, написания и обновления документации, – это невозможно.

Управление техдолгом. Костыли, мелкие баги и устаревание архитектуры – естественный процесс в разработке для бизнеса. Задача техлида – стараться делать так, чтобы техдолга не становилось слишком много, и он не мешал развитию продукта.

Обучение команды и продвижение культуры разработки. В долгосрочной перспективе – это самый надежный способ не плодить техдолг.

А каких навыков на ваш взгляд не хватает вам? Делитесь в комментариях 👇

🔥 Завтра на H&S Conclave обсудим острую и важную тему — столкновение интересов бизнеса, культуры разработки и технического долга.

Программа встречи:
1️⃣ Балансирование интересов бизнеса и культуры разработки.
2️⃣ Работа с техническим долгом: проверка ценностей инженера.
3️⃣ Внутренняя кухня продуктов: взгляд бизнеса на ситуацию.
4️⃣ Методики выхода из кризисов.
5️⃣ Практические кейсы из работы консультанта фаундеров IT-продуктов.

Начало: в 20.00 GMT+3

🎤 Спикер: Дмитрий Горячко — IT-консультант в zmicer.consulting, основатель и руководитель сервисной IT компании JazzTeam. Обладает инженерным бэкграундом с фокусом на Java, работал на позициях Senior Software Engineer, Agile Consultant, CTO

👉 Регистрация по ссылке. До встречи!

В прошлый четверг мы провели 28-й Software Craftsmanship Meetup в новом формате – live design session.

Павел Вейник вместе с участниками митапа в подробностях разбирали классическую задачу на system design – высоконагруженный сокращатель ссылок:

- Определили функциональные и нефункциональные требования к системе
- Рассчитали нагрузки, объем памяти и хранилища, пропускную способность сети, необходимые для работы системы
- Выявили узкие места
- Определились с алгоритмами сокращения и расшифровки ссылок, и подобрали некоторые инструменты, которые могут обеспечить их работу

🎥 Запись встречи на YouTube

16 января проведем вторую дизайн-сессию, где составим high-level схему системы, сравним компоненты (БД, кэши, балансировщики и т.д.), и финализируем проект архитектуры.

🔗 Регистрируйтесь на вторую часть митапа по ссылке!

Отвечаю на следующий вопрос, заданный в регистрациях на 28й митап.
Короткий ответ - забота о безопасности должна соответствовать нефункциональным требованиям.
Что потеряет бизнес если произойдет утечка данных - все, ничего, или наоборот окажется хорошим PR?
Что произойдет, если сервис будет лежать под DDOS - полный крах, легкое неудобство или ничего?
Редко ущерб будет действительно большой.
В любом случае, не нужно выстраивать более дорогую систему безопасности, чем того требует бизнес.
Кроме того, безопасность - в большей степени дело дисциплины, процессов и процедур, чем реально техническая задача. Потому что против бумажки с паролем под клавиатурой, которая потом попала в мусорку, ничего противопоставить нельзя.

Смотря что тут понимается под анализом требований. Если анализ уже готового дока на 146 страниц - то AI может пригодиться, а если требования в головах стейкхолдеров, то никакой AI не поможет. Приходится звониться с ними и разговаривать, заниматься requirement management и разрешать противоречия между интересами разных стейкхолдеров.

Никак. Совсем никак.
Просчетов не будет только если вы только что сделали 3 таких же задачи - но ведь так не бывает.
Чтобы уменьшить просчет, нужно более тщательно проектировать, докапываясь до corner cases, ошибок и их обработчиков, особенно если речь про бизнес-логику и транзакции. Описывать действия вплоть до алгоритма, прогонять этот алгоритм на бумажке/доске раз 15, чтобы понять где прокол. Тогда все мыслительные операции будут отдельно от кодирования, и уже написанный код не будет мешать думать. Покрывать тестами важные куски, чтобы в процессе следующих задач не поломать эту задачу.

Добавить к оценке время на отработку пайплайна, или на ручные проверки.

А также поддерживать доверие и коммуникации с менеджером/тимлидом, рассказывая ему что и почему делаешь, чтобы он был в курсе и не нервничал если что-то пошло не так.

Это был последний вопрос к 28му Software Craftsmanship Meetup. Завтра будет митап, посвященный рост после сеньера, вот там вопросов примерно 61. Задать вопрос сюда https://hardsoftskills.dev/meetup_technical_leader_1912

🥂Всех с пятницей!

Вчера прошел митап [Технический Лидер]. Обсуждали рост инженера, стеклянный потолок сеньора, и что нужно, чтобы его пробить.

Отдельно поговорили о ситуации на рынке IT сейчас и чего ждать в 2025 году. (спойлер - очень тревожно)

📹 Видео уже на YouTube - приятного просмотра!

А еще можете посмотреть запись выступления Павла Вейника для выпускников Стратоплана, которое состоялось в эту среду:

Связь между организацией, архитектурой и мелкими проблемами в разработке

1️⃣ перегруженные техлиды
2️⃣ отсутствующие архитекторы
3️⃣ повышение за выслугу лет и лояльность
4️⃣ оторванные от жизни платформенные команды
5️⃣ core команды, правящие баги всей системы
6️⃣ архитекторы, не создающие правил в большой системе

Что может делать техлид для развития команды?

Работать над тем, чтобы команда разработки лучше выполняла свои задачи – это то, зачем техлиду приставка “лид”. При этом, прямой власти у техлида может и не быть. Часто это роль, а не должность, и техлид – это самый опытный сеньор, первый среди равных.

Развивать команду можно несколькими путями:

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

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

📚 Прямое обучение – проводить внутренние митапы и tech talks, организовывать совместные обсуждения и брейншторм-сессии по архитектуре, выбивать у менеджмента бюджет на оплату курсов для членов команды.

А что если сотрудник не хочет развиваться?

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

Но может быть так, что такого человека недостаточно мотивируют текущие задачи. Возможно, он хочет побыть ментором, поработать над архитектурой или углубиться в DevOps. Стоит учитывать личные амбиции и интересы сотрудников. (если это возможно в текущих условиях)

Культура команды начинается с ее лидера.

Требуя развития от коллег, не забывайте расти сами. Узнайте, что для этого нужно, на консультации перед курсом [Технический Лидер]!

Итоги года для Hard&Soft Skills мы подвели, а каким 2024 был для IT в целом?

Немного статистики:

🚫 Лэйоффы затронули 240 тысяч человек в tech индустрии. Это почти вдвое меньше, чем в прошлом году, но сопоставимо с 2022.
📃 Количество открытых вакансий выросло на 18% с начала года.
📉 По данным LinkedIn, Hiring rate снизился на 1,2% по сравнению с прошлым годом. (и на 17% по сравнению с 2016)

На 2025 год прогнозов много и все они разные: от сдержанного оптимизма по поводу роста рынка на 8-9%, до предсказаний, что IT – это пузырь, который вот-вот лопнет.

Одно можно сказать точно – в индустрии тренд на эффективность техники, процессов и людей.

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

Условный Amazon торгуется по цене 20x своей выручки и может брать в инвестиционных фондах деньги под минимальные проценты.
⬇️
Он покупает за 100 миллионов стартап, который делает 10 миллионов выручки в год и присоединяет его к себе.
⬇️
Поскольку Amazon торгуется по цене 20х к своей выручке, то его капитализация вырастает на 200 миллионов.

После 2022 года быстрый рост ради самого роста уже не оправдывает вливание средств – инвесторы хотят видеть cash flow и прибыльность. Новая схема такая:

Private equity фонды за бесценок скупают IT-компании, которые находятся в тяжелом состоянии. Они срезают большую часть расходов, а это значит увольняют огромное количество инженеров и менеджмента. В итоге превращают этот бизнес в маленький cashcow, который не развивается, но приносит прибыль здесь и сейчас.

Один из громких примеров такой модели – покупка беларусской компании Apalon. В начале 2024 года ее приобрел итальянский разработчик игр Bending Spoons. Всю команду – 330 человек – при этом уволили.

Что это значит для разработчиков?

🔹 Как раньше уже не будет. Получить 3 оффера за день просто ответив на входящие запросы рекрутеров уже не получится.
🔹 Нужно понимать бизнес, и какую пользу ваша работа ему приносит.
🔶 Хорошие специалисты востребованы всегда, особенно в тяжелые времена. Пример – отзывы наших выпускников из предыдущего поста. Хотите обезопасить себя – записывайтесь на курс [Технический Лидер].

Согласны с такими выводами? Делитесь в комментариях 👇

Что делать разработчику, чтобы оставаться востребованным в 2025 году?

Об этом и не только будем говорить на открытом митапе [Технический Лидер].

🗓 23 января
⏰ 19:00(GMT+3)

Обсудим карьеру разработчика, навыки сеньора и техлида. Посмотрим на рынок труда, тренды индустрии IT и что изучать, чтобы расти по карьере, получать интересные задачи и увеличивать свой доход.

👉 Регистрируйтесь по ссылке!

Как техлиду подружить ожидания стейкхолдеров с реальностью?

💼 Бизнес хочет, чтобы все работало и приносило как можно больше денег как можно быстрее.

💻 Разработчики хотят делать интересные сложные решения, и чтобы им не мешали делать красиво и качественно.

🎯 Менеджеры хотят, чтобы планы соблюдались, KPI выполнялись, подчиненные слушались, а руководители не продавливали очередные очень важные и срочные задачи.

И у каждого из них есть собственные интересы, карьерные амбиции, личные взаимоотношения и явные или скрытые мотивы. И в этом должен лавировать техлид и, в еще большей степени, архитектор.

Инструмент только один – коммуникации. Говорить со всеми, пытаться понять их точку зрения, пояснять свою, спорить, договариваться и искать компромиссы.

А чтобы облегчить коммуникации и сделать их эффективнее – нужен авторитет.

Как его завоевать?

🔹Соблюдать границы своей роли. Фидбэк, который не просили, всегда воспринимается как агрессия, если вы не даете его вашему подчиненному, потому что это ваша обязанность. Если, например, проект стопорится из-за некомпетентного менеджера, лучше найти неравнодушных единомышленников и идти к вышестоящему руководству, чем пытаться решать проблему в одиночку.

🔹Не навязывать улучшения, о которых не просят. Тот же принцип, что и выше. Указывайте на проблемы, предлагайте решения, но не пытайтесь продавить их без поддержки. Если спустя время эти проблемы выстрелят, в будущем к вам будут больше прислушиваться.

🔹Способ донесения информации важнее содержания. У всех есть эго. Критикуя работу коллег важно помнить об этом и стараться лишний раз его не задевать. Сказать “это – говно, переделывай" проще всего, но нужно ли?

🔸И главное – доверие и уважение зарабатываются постепенно. Если вы в компании давно, у вас уже есть какой-то кредит доверия, за счет которого можно протолкнуть улучшения. Но если вы только пришли, мало кто будет прислушиваться к вам, будь вы хоть трижды правы.

О роли техлида, и чем она отличается от тимлида и архитектора приходите послушать 23 января на митапе [Технический Лидер].