Код Меркури

🔥 Быть активным в компании — это плюс или ловушка? С одной стороны, активность = заметность. Ты участвуешь в митапах, двигаешь инициативы, знакомишься с топами. Карьера растёт! 🚀 Но не всё так просто: ⚡ Перегореть легко — ты делаешь больше, но зарплата остаётся прежней. В большинстве случаев корпоративные инициативы не оплачиваются. ⚡ Не все любят энтузиастов — можно нарваться на сопротивление «старожилов», которым и так нормально. ⚡ Активность ≠ результат —важны не только идеи, но и их реальная польза.

Это был насыщенный путь, полный вызовов, роста и возможностей. Конечно, я рассказал далеко не всё – например, не рассказал про запуск собственных проектов внутри компании, опыт работы в роли engineering manager, попытку бросить университет ради командировок в Штаты и том, как я уволился с предыдущего места работы, чтобы снова стать просто Senior'ом (привет вчерашнему обсуждению в комментариях)... Если интересно — тегайте @mercdevchat в комментариях, с радостью расскажу ещё пару карьерных историй. А у вас как? Делитесь самыми яркими моментами из своей карьеры — будет интересно почитать!

Привет! Мы уже обсуждали грейды, а теперь хочу поделиться своей историей. Возможно, это поможет вам лучше понять возможные пути развития. Начало пути Я начал работать в 2016 году на позиции DevOps Intern. В самом начале у меня был небольшой, уютный внутренний проект, но вскоре мне его стало мало. Я начал погружаться в соседние задачи, помогая команде осваивать Terraform (ещё версии 0.6.X!), Jenkins, Docker и прочий базовый DevOps стек. Через три месяца меня взяли на первый коммерческий проект – для одного из топ-3 ритейлеров США (при этом я очень плохо разговаривал на английском!). Это было страшно: моя команда состояла на 80% из сеньоров, и я очень боялся не справиться. Но через пару месяцев освоился (спасибо коллегам, с которыми до сих пор общаемся!) и получил промоушен до Junior. Переход в Middle Со временем я глубже погружался в энтерпрайз-разработку. Однажды мне предложили pre-sale проект, где я смог применить накопленные знания и полноценно залидить его с позиции Junior. Это привело к промоушену в Middle. В этой роли я задержался примерно на 1–1,5 года. Перейти в Senior помогло то, что я активно участвовал не только в основном проекте, но и в соседних инициативах, расширяя зону ответственности и визибилити в компании. Меня начали узнавать даже на кухне в офисах разных стран. Путь к Senior На границе между Middle и Senior у меня появилась первая команда из двух человек (включая меня). Позже, сменив проект, я начал работать уже с командой из пяти человек. Мы переносили легаси-приложения на новую архитектуру в Kubernetes, разрабатывая её параллельно с миграцией. Проект был сложным – сопротивление архитекторов, менеджеров и других стейкхолдеров порой тормозило процесс. По неопытности, я иногда задерживался в офисе до 10–11 вечера, пытаясь доделать работу за команду (не повторяйте моих ошибок!). Время шло, и в какой-то момент менеджер попросил собрать очный митинг в 11 утра, на который он пришёл с фразой: «Увольняем всю команду» (не из компании, а с проекта). Но вместо стресса это стало для меня толчком к развитию. Лидерство и R&D На этом этапе я уже больше года занимался менторингом: помогал коллегам с проектами, направлял их развитие, проводил регулярные 1:1 сессии. Для меня ключевыми KPI были: ✅ Сколько человек перешли из Junior → Middle и из Middle → Senior ✅ Сколько инженеров получили сертификации Через неделю после завершения предыдущего проекта, где всю мою команду уволили с проекта, меня пригласили в R&D, чтобы создать полноценный Data Lake с AI, batch, streaming и множеством ETL-пайплайнов – продукт, который можно было продавать как сервис. Это был крутой и сложный опыт, который включал: 🔹 Регулярные созвоны с AWS-архитекторами 🔹 Постоянный поиск обходных путей из-за ограничений AWS 🔹Первый “взрослый” опыт работы devops-архитектором Техлидство и масштабные проекты После R&D наступил новый этап. Меня пригласили строить команду с нуля для крупного клиента – одной из топ-3 фастфуд-сетей США. Здесь мне предстояло создать полноценную инфраструктуру с нуля, включая: 🏗 Multi-regional Kubernetes-кластеры с высокой отказоустойчивостью 🔀 Service Mesh для управления трафиком и безопасностью микросервисов ⚙️ 100+ микросервисов, работающих в распределённой среде 🏗 10+ окружений, включая dev, staging и production 🔧 Самописные Kubernetes-операторы, автоматизирующие рутинные процессы Но кроме технической части, я также управлял процессами: ✅ Нанимал и ротировал людей, создавая эффективную команду из ~ 30 человек, которая требовала координации и поддержки ✅ Проводил регулярные архитектурные созвоны, предлгая ключевые технические решения ✅ «Продавал» заказчику новые технологии, объясняя их ценность и обосновывая необходимость внедрения Этот этап стал для меня уникальным опытом, который позволил не только углубиться в архитектуру, но и развить лидерские и стратегические навыки. Несмотря на это, я выбрал не менеджмент или архитектуру, а стал техлидом.

📌 Итог Каждый выбирает свой путь в зависимости от интересов: ✔ Любишь управлять людьми? -> Team Lead ✔ Хочешь влиять на технологии? -> Tech Lead ✔ Мечтаешь строить архитектуру? -> Architect ✔ Тянешься к бизнесу? -> Manager А какой путь выбрали вы? Делитесь в комментариях! 🚀

🔹 Mentor Ментор – это не официальная должность, а дополнительная роль, которую можно совмещать с любой позицией. 📌 Чем занимается Mentor? ✅ Помогает младшим разработчикам расти, ✅ Делится знаниями и опытом, ✅ Участвует в адаптации новых сотрудников, ✅ Может вести лекции или внутренние курсы. 🔹 Кто может быть ментором? Любой опытный разработчик, который хочет передавать знания и помогать другим расти. 👉 Это важная роль, которая помогает всей компании развиваться быстрее.

🔹 Manager Фокус: Бизнес и стратегия 📌 Задачи: ✅ Управление командами или отделами ✅ Рост и развитие сотрудников ✅ Найм и адаптация ✅ Взаимодействие с бизнесом и стратегическое планирование ✅ Оптимизация работы всей разработки 🔹 Manager vs Team Lead * Team Lead – управляет процессами внутри одной команды * Manager – управляет несколькими командами или целыми отделами. 👉 Это путь для тех, кто хочет полностью перейти в управление и влиять на развитие бизнеса.

🔹 Architect Фокус: Стратегическое проектирование 📌 Задачи: ✅ Проектирование масштабируемых систем ✅ Выбор технологий и архитектурных подходов ✅ Разработка стандартов и гайдов ✅ Взаимодействие с несколькими командами ✅ Оптимизация производительности и интеграций 🔹 Architect vs Tech Lead * Tech Lead – решает локальные технические вопросы в рамках одной команды * Architect – отвечает за глобальные архитектурные решения на уровне всей компании или нескольких проектов 👉 Это роль для тех, кто хочет уйти глубже в инженерные решения и решать бизнес-задачи, а не просто писать код.

🔹 Tech Lead Фокус: Разработка и технологии 📌 Задачи: ✅ Определяет архитектурные и технологические решения, ✅ Разрабатывает стратегию развития кода и инфраструктуры, ✅ Контролирует код-ревью и следит за качеством кода, ✅ Помогает команде с техническими сложностями, ✅ Работает с техническим долгом и DevOps-процессами. 🔹 Tech Lead vs Team Lead * Tech Lead – фокус на техническом развитии продукта (качество и масштабируемость) * Team Lead – фокус на команде и процессах. 👉 Tech Lead – это человек, который помогает разработчикам писать не просто код, а качественный и масштабируемый код.

🔹 Team Lead Фокус: Люди и процессы 📌 Задачи: ✅ Организация работы команды (скрам-митинги, ретро, планирование), ✅ Отвечает за продуктивность и мотивацию команды, ✅ Решает административные вопросы (перформанс-ревью, найм, онбординг, увольнение), ✅ Следит за сроками и распределением задач, ✅ Работает над ростом сотрудников и их карьерными планами. 🔹 Senior vs Team Lead * Senior – фокус на коде и архитектуре, * Team Lead – фокус на людях и управлении командой. 👉 Ключевой навык для Team Lead – умение выстраивать эффективную команду, а не просто разрабатывать самому.

🔥 Карьера разработчика: что после Senior? Когда разработчик доходит до уровня Senior, возникает вопрос: «А что дальше?» Спойлер: карьера только начинается! На этом этапе открываются четыре основные ветки развития: 🔹 Team Lead – управление командой и процессами 🔹 Tech Lead – техническое лидерство и развитие продукта 🔹 Architect – проектирование архитектуры и стратегические решения 🔹 Manager – переход в управление. Помимо этих направлений, есть и дополнительные роли, которые можно совмещать с основной позицией: 🔹 Mentor – обучение и поддержка коллег 🔹Engineering Manager - работа с направлением внутри компании (но в данном посте мы не будем погружаться в детали этой роли). Давайте разберёмся в каждой из описанных позиций подробнее.

💣 Типичные ошибки: Застревание в «техническом режиме» → микроменеджмент вместо делегирования. 🆚 Lead vs Senior: * Senior отвечает за код, Lead — за людей и процессы * Senior все еще пишет код сам, Lead следит, чтобы команда писала правильно 🎯 Главная цель: Построить систему, которая работает без вашего ежедневного вмешательства. Итог Каждый уровень — это не просто рост технических навыков, а смена фокуса: 🔸 Intern → Junior: «Учусь делать» → «Делаю сам» 🔸 Junior → Middle: «Вижу задачу» → «Вижу систему» 🔸 Middle → Senior: «Решаю проблемы» → «Предотвращаю проблемы» 🔸 Senior → Lead: «Создаю код» → «Создаю среду» А какой переход был для вас самым сложным? Поделитесь лайфхаками в комментариях! P.S. А если вы Lead, который до сих пор пишет код по ночам — это нормально. Мы вас видим 👀

🔹 Lead "Моя роль — превращать хаос в процессы" На этом уровне разработка отходит на второй план, а на первый выходит управление командой и процессами. ⚙️ Чем занят Lead: * Создаёт культуру команды (как проводят ретро, как спорят, как празднуют успехи) * Формирует стратегию. Как и что будет разрабатываться в ближайшие месяцы и годы. * Выстраивает команду. Занимается наймом, адаптацией и развитием сотрудников. * Разрешает конфликты и управляет ожиданиями. Lead — это основной буфер между бизнесом и технической командой. * Выстраивает процессы. Это включает как ежедневные ритуалы (скрам-митинги, ретро, демо), так и технические процессы: деплой, откаты (rollback), работу над постмортемами, а также внедрение и адаптацию новых инструментов. * Делегирует задачи. Разрабатывает не сам, а распределяет задачи среди команды.

🔹 Senior "Разрабатываю не фичи, а бизнес-ценность" Здесь начинается игра на совсем другом уровне. Senior — это не просто опытный разработчик, а человек, который понимает бизнес, берет на себя ответственность и влияет на продукт. 📌 Что отличает настоящего Senior: * Видит разницу между «можно сделать» и «нужно сделать» * Умеет сказать «нет» заказчику (и предложить альтернативу) * Автоматизирует рутину команды, а не только свою * Пишет документацию, которую реально читают * Лидит процессы. Участвует в оптимизации разработки, CI/CD, DevOps и техническом долге. * Строит долгосрочные решения, а не просто пилит фичи * Обучает и помогает Junior/Middle-разработчикам 💼 Неочевидные навыки: * Выступление на митапах / написание статей (формирование экспертного статуса) * Управление ожиданиями стейкхолдеров («это займёт 2 месяца» → «это невозможно в ваши сроки, но вот что мы можем...») 🎯 Главная цель: Перевести фокус с технологии на бизнес-результат. 👉 Как расти до Lead? * Брать ответственность за ключевые решения в проекте, * Учиться делегировать и эффективно распределять задачи, * Работать не только над кодом, но и над процессами в команде. * Смотреть на проекты вокруг себя. Расширять свою техническую компитенцию и экспертизу.

🔹 Middle: золотая середина "Решаю проблемы, а не пишу код" 🔥 Что реально требуется: * Понимание устройства всего проекта * Умение писать код любой сложности, если есть более ли менее чёткие критерии * Готовность брать на себя ответственность за задачи и их дедлайны. * Способность перевести простой бизнес-запрос в технические спецификации * Понимание, как ваш код влияет на смежные модули * Умение отстаивать своё решение (с аргументами, а не «мне так нравится») 🆚 Middle vs Senior: Middle спрашивает: «Как сделать?», Senior — «Зачем делать?» 🎯 Главная цель: Перестать быть «исполнителем» и начать видеть системные взаимосвязи. 👉 Как расти до Senior? * Участвовать в обсуждениях бизнес-процессов, * Работать с бэклогом, самостоятельно формулировать acceptance criteria, * Начинать менторить и помогать другим.

🔹 Junior: первый самостоятельный шаг "Я уже что-то могу, но не спрашивайте как это работает в продакшене" 📌 Отличия от Intern: * Способен самостоятельно решать большинство простых задач * Работает с простыми системами и API * Умеет грамотно декомпозировать задачи * Взаимодействие с ментором становится реже и более асинхронным. * Пишет автотесты (иногда даже перед кодом!) * Понимает, что такое технический долг (и оставляет его будущему себе) 💡 Ловушка уровня: «Я уже всё знаю» → игнорирует feedback → застревает в джуне на 3 года. 🎯 Главные цели: * Набить руку на типовых задачах * Научиться работать с неочевидными и сложными системами * Разбираться в чужом коде и стабильно решать задачи в разумные сроки * Предвидеть последствия своего кода.

🚀 Карьерная лестница в IT: от Intern до Lead — что скрывается за грейдами? Привет! Вы наверняка знакомы с классической карьерной лестницей: Intern → Junior → Middle → Senior → Lead. Это стандартный путь развития технического специалиста, где на каждом уровне от вас ожидают определённые компетенции, но какие конкретно? Давайте сегодня разберемся подробнее. 🔹 Intern: точка роста "Горящие глаза + базовые навыки" ✅ Минимум для старта: * Основы языка/фреймворка (хотя бы по туториалу) * Умение задавать вопросы (да, это навык!) * Готовность переделывать задачу 3 раза * Минимальные навыки чтения технического английского ⚠️ Особенность роли: Задачи интерна — тренировочный полигон. Без детального ТЗ, ежедневного менторства и 80% времени на правки в код-ревью — не обойтись. 🎯 Главная цель: Научиться не теряться при виде production-кода и доводить задачи до конца самостоятельно (даже если «работает, но стыдно показать»).

Как внедрить чтение в рутину? 🔹5 минут утром за кофе — пролистайте ленту Telegram-каналов. 🔹Подкасты в дороге — слушайте технические подкасты, пока едете на работу. 🔹Челлендж на неделю — выделяйте 15 минут в день на одну главу книги. Сделав это ежедневной привычкой, вы будете оставаться в курсе трендов и развиваться без перегруза. А вы что выбираете — книги, статьи или learning by doing? Делитесь в комментариях своими лайфхаками и топовыми книгами! 🚀

🔥 Must-read для любого IT-специалиста 📖 «Компьютерные сети» (Таненбаум) — база для DevOps и не только. 📖 «Linux Kernel Development» (Robert Love) — мастхэв для работы с ОС. 📖 «Паттерны проектирования» (Банда Четырёх) — классика, которая не стареет. 📖 «Искусство программирования» (Кнут) — если хватит смелости 😉 📖 «System Design Interview» (Alex Xu) — даже если не собеседуетесь, научит масштабировать системы и думать как архитектор. 📖 «Современные операционные системы» (Таненбаум) — энциклопедия по ОС. После неё перестанете бояться deadlock’ов и виртуальной памяти. 📖 «Чистый код» (Роберт Мартин) — мастхэв для любого разработчика и DevOps. Учит писать код, который не стыдно показать: от именования переменных до рефакторинга и принципов SOLID. Если не читали — начинайте с этой книги! Эти книги сформируют прочный фундамент, который пригодится в любой IT-специальности. А если вы когда-нибудь решите пройти собеседование в FAANG-like компанию, они станут просто незаменимой базой.

Что я вынес за 10 лет в IT? 📌Книги — это фундамент, но не все книги одинаково полезны.. Бессмысленно читать очередную «Java за 24 часа» — практика даст вам больше. А например книги уровня «Чистого кода» или «Современные операционные системы» сэкономят вам массу времени и уберегут от изобретения велосипедов. 📌 Если нет времени на книги — читайте хотя бы статьи и рассылки. Уделяйте 5–10 минут в день материалам по вашей специализации на любом из ресурсов ниже: 🔸Medium 🔸DZone 🔸HackerNoon 🔸Habr 🔸Telegram-каналы по теме (у меня их целая подборка — пишите в комментариях, если нужен список 👇).

Сегодня обсудим continuous learning, книги по IT и важность чтения технических статей. Однажды мой друг заявил: «Зачем читать книги по программированию? Я всё узнаю на практике!» Сначала меня это возмутило, но позже я понял: такой подход тоже имеет право на жизнь... если не забывать про нюансы.