Сегодня обсудим continuous learning, книги по IT и важность чтения технических статей.

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

Что я вынес за 10 лет в IT?

📌Книги — это фундамент, но не все книги одинаково полезны.. Бессмысленно читать очередную «Java за 24 часа» — практика даст вам больше. А например книги уровня «Чистого кода» или «Современные операционные системы» сэкономят вам массу времени и уберегут от изобретения велосипедов.

📌 Если нет времени на книги — читайте хотя бы статьи и рассылки. Уделяйте 5–10 минут в день материалам по вашей специализации на любом из ресурсов ниже:
🔸Medium
🔸DZone
🔸HackerNoon
🔸Habr
🔸Telegram-каналы по теме (у меня их целая подборка — пишите в комментариях, если нужен список 👇).

🔥 Must-read для любого IT-специалиста

📖 «Компьютерные сети» (Таненбаум) — база для DevOps и не только.

📖 «Linux Kernel Development» (Robert Love) — мастхэв для работы с ОС.

📖 «Паттерны проектирования» (Банда Четырёх) — классика, которая не стареет.

📖 «Искусство программирования» (Кнут) — если хватит смелости 😉

📖 «System Design Interview» (Alex Xu) — даже если не собеседуетесь, научит масштабировать системы и думать как архитектор.

📖 «Современные операционные системы» (Таненбаум) — энциклопедия по ОС. После неё перестанете бояться deadlock’ов и виртуальной памяти.

📖 «Чистый код» (Роберт Мартин) — мастхэв для любого разработчика и DevOps. Учит писать код, который не стыдно показать: от именования переменных до рефакторинга и принципов SOLID. Если не читали — начинайте с этой книги!

Эти книги сформируют прочный фундамент, который пригодится в любой IT-специальности. А если вы когда-нибудь решите пройти собеседование в FAANG-like компанию, они станут просто незаменимой базой.

Как внедрить чтение в рутину?

🔹5 минут утром за кофе — пролистайте ленту Telegram-каналов.

🔹Подкасты в дороге — слушайте технические подкасты, пока едете на работу.

🔹Челлендж на неделю — выделяйте 15 минут в день на одну главу книги.
Сделав это ежедневной привычкой, вы будете оставаться в курсе трендов и развиваться без перегруза.

А вы что выбираете — книги, статьи или learning by doing? Делитесь в комментариях своими лайфхаками и топовыми книгами! 🚀

🚀 Карьерная лестница в IT: от Intern до Lead — что скрывается за грейдами?

Привет!
Вы наверняка знакомы с классической карьерной лестницей: Intern → Junior → Middle → Senior → Lead. Это стандартный путь развития технического специалиста, где на каждом уровне от вас ожидают определённые компетенции, но какие конкретно? Давайте сегодня разберемся подробнее.


🔹 Intern: точка роста
"Горящие глаза + базовые навыки"


✅ Минимум для старта:
* Основы языка/фреймворка (хотя бы по туториалу)
* Умение задавать вопросы (да, это навык!)
* Готовность переделывать задачу 3 раза
* Минимальные навыки чтения технического английского

⚠️ Особенность роли:
Задачи интерна — тренировочный полигон. Без детального ТЗ, ежедневного менторства и 80% времени на правки в код-ревью — не обойтись.

🎯 Главная цель:
Научиться не теряться при виде production-кода и доводить задачи до конца самостоятельно (даже если «работает, но стыдно показать»).

🔹 Junior: первый самостоятельный шаг
"Я уже что-то могу, но не спрашивайте как это работает в продакшене"

📌 Отличия от Intern:
* Способен самостоятельно решать большинство простых задач
* Работает с простыми системами и API
* Умеет грамотно декомпозировать задачи
* Взаимодействие с ментором становится реже и более асинхронным.
* Пишет автотесты (иногда даже перед кодом!)
* Понимает, что такое технический долг (и оставляет его будущему себе)

💡 Ловушка уровня:
«Я уже всё знаю» → игнорирует feedback → застревает в джуне на 3 года.

🎯 Главные цели:
* Набить руку на типовых задачах
* Научиться работать с неочевидными и сложными системами
* Разбираться в чужом коде и стабильно решать задачи в разумные сроки
* Предвидеть последствия своего кода.

🔹 Middle: золотая середина
"Решаю проблемы, а не пишу код"

🔥 Что реально требуется:
* Понимание устройства всего проекта
* Умение писать код любой сложности, если есть более или менее чёткие критерии
* Готовность брать на себя ответственность за задачи и их дедлайны.
* Способность перевести простой бизнес-запрос в технические спецификации
* Понимание, как ваш код влияет на смежные модули
* Умение отстаивать своё решение (с аргументами, а не «мне так нравится»)

🆚 Middle vs Senior:
Middle спрашивает: «Как сделать?», Senior — «Зачем делать?»

🎯 Главная цель:
Перестать быть «исполнителем» и начать видеть системные взаимосвязи.

👉 Как расти до Senior?
* Участвовать в обсуждениях бизнес-процессов,
* Работать с бэклогом, самостоятельно формулировать acceptance criteria,
* Начинать менторить и помогать другим.

🔹 Senior
"Разрабатываю не фичи, а бизнес-ценность"
Здесь начинается игра на совсем другом уровне. Senior — это не просто опытный разработчик, а человек, который понимает бизнес, берет на себя ответственность и влияет на продукт.

📌 Что отличает настоящего Senior:
* Видит разницу между «можно сделать» и «нужно сделать»
* Умеет сказать «нет» заказчику (и предложить альтернативу)
* Автоматизирует рутину команды, а не только свою
* Пишет документацию, которую реально читают
* Лидит процессы. Участвует в оптимизации разработки, CI/CD, DevOps и техническом долге.
* Строит долгосрочные решения, а не просто пилит фичи
* Обучает и помогает Junior/Middle-разработчикам

💼 Неочевидные навыки:
* Выступление на митапах / написание статей (формирование экспертного статуса)
* Управление ожиданиями стейкхолдеров («это займёт 2 месяца» → «это невозможно в ваши сроки, но вот что мы можем...»)

🎯 Главная цель:
Перевести фокус с технологии на бизнес-результат.

👉 Как расти до Lead?
* Брать ответственность за ключевые решения в проекте,
* Учиться делегировать и эффективно распределять задачи,
* Работать не только над кодом, но и над процессами в команде.
* Смотреть на проекты вокруг себя. Расширять свою техническую компитенцию и экспертизу.

🔹 Lead
"Моя роль — превращать хаос в процессы"
На этом уровне разработка отходит на второй план, а на первый выходит управление командой и процессами.

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

💣 Типичные ошибки:
Застревание в «техническом режиме» → микроменеджмент вместо делегирования.

🆚 Lead vs Senior:
* Senior отвечает за код, Lead — за людей и процессы
* Senior все еще пишет код сам, Lead следит, чтобы команда писала правильно

🎯 Главная цель:
Построить систему, которая работает без вашего ежедневного вмешательства.

Итог
Каждый уровень — это не просто рост технических навыков, а смена фокуса:
🔸 Intern → Junior: «Учусь делать» → «Делаю сам»
🔸 Junior → Middle: «Вижу задачу» → «Вижу систему»
🔸 Middle → Senior: «Решаю проблемы» → «Предотвращаю проблемы»
🔸 Senior → Lead: «Создаю код» → «Создаю среду»

А какой переход был для вас самым сложным? Поделитесь лайфхаками в комментариях!
P.S. А если вы Lead, который до сих пор пишет код по ночам — это нормально. Мы вас видим 👀

🔥 Карьера разработчика: что после Senior?

Когда разработчик доходит до уровня Senior, возникает вопрос: «А что дальше?» Спойлер: карьера только начинается! На этом этапе открываются четыре основные ветки развития:

🔹 Team Lead – управление командой и процессами

🔹 Tech Lead – техническое лидерство и развитие продукта

🔹 Architect – проектирование архитектуры и стратегические решения

🔹 Manager – переход в управление.


Помимо этих направлений, есть и дополнительные роли, которые можно совмещать с основной позицией:
🔹 Mentor – обучение и поддержка коллег

🔹Engineering Manager - работа с направлением внутри компании (но в данном посте мы не будем погружаться в детали этой роли).


Давайте разберёмся в каждой из описанных позиций подробнее.

🔹 Team Lead
Фокус: Люди и процессы

📌 Задачи:
✅ Организация работы команды (скрам-митинги, ретро, планирование),
✅ Отвечает за продуктивность и мотивацию команды,
✅ Решает административные вопросы (перформанс-ревью, найм, онбординг, увольнение),
✅ Следит за сроками и распределением задач,
✅ Работает над ростом сотрудников и их карьерными планами.

🔹 Senior vs Team Lead
* Senior – фокус на коде и архитектуре,
* Team Lead – фокус на людях и управлении командой.

👉 Ключевой навык для Team Lead – умение выстраивать эффективную команду, а не просто разрабатывать самому.

🔹 Tech Lead
Фокус: Разработка и технологии

📌 Задачи:
✅ Определяет архитектурные и технологические решения,
✅ Разрабатывает стратегию развития кода и инфраструктуры,
✅ Контролирует код-ревью и следит за качеством кода,
✅ Помогает команде с техническими сложностями,
✅ Работает с техническим долгом и DevOps-процессами.

🔹 Tech Lead vs Team Lead
* Tech Lead – фокус на техническом развитии продукта (качество и масштабируемость)
* Team Lead – фокус на команде и процессах.


👉 Tech Lead – это человек, который помогает разработчикам писать не просто код, а качественный и масштабируемый код.

🔹 Architect
Фокус: Стратегическое проектирование

📌 Задачи:
✅ Проектирование масштабируемых систем
✅ Выбор технологий и архитектурных подходов
✅ Разработка стандартов и гайдов
✅ Взаимодействие с несколькими командами
✅ Оптимизация производительности и интеграций

🔹 Architect vs Tech Lead
* Tech Lead – решает локальные технические вопросы в рамках одной команды
* Architect – отвечает за глобальные архитектурные решения на уровне всей компании или нескольких проектов

👉 Это роль для тех, кто хочет уйти глубже в инженерные решения и решать бизнес-задачи, а не просто писать код.

🔹 Manager
Фокус: Бизнес и стратегия

📌 Задачи:
✅ Управление командами или отделами
✅ Рост и развитие сотрудников
✅ Найм и адаптация
✅ Взаимодействие с бизнесом и стратегическое планирование
✅ Оптимизация работы всей разработки

🔹 Manager vs Team Lead
* Team Lead – управляет процессами внутри одной команды
* Manager – управляет несколькими командами или целыми отделами.

👉 Это путь для тех, кто хочет полностью перейти в управление и влиять на развитие бизнеса.

🔹 Mentor
Ментор – это не официальная должность, а дополнительная роль, которую можно совмещать с любой позицией.

📌 Чем занимается Mentor?
✅ Помогает младшим разработчикам расти,
✅ Делится знаниями и опытом,
✅ Участвует в адаптации новых сотрудников,
✅ Может вести лекции или внутренние курсы.

🔹 Кто может быть ментором?
Любой опытный разработчик, который хочет передавать знания и помогать другим расти.

👉 Это важная роль, которая помогает всей компании развиваться быстрее.

📌 Итог
Каждый выбирает свой путь в зависимости от интересов:

✔ Любишь управлять людьми? -> Team Lead
✔ Хочешь влиять на технологии? -> Tech Lead
✔ Мечтаешь строить архитектуру? -> Architect
✔ Тянешься к бизнесу? -> Manager

А какой путь выбрали вы? Делитесь в комментариях! 🚀

Привет! Мы уже обсуждали грейды, а теперь хочу поделиться своей историей. Возможно, это поможет вам лучше понять возможные пути развития.


Начало пути
Я начал работать в 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+ микросервисов, работающих в распределённой среде
🏗 30+ окружений
🔧 Самописные Kubernetes-операторы, автоматизирующие рутинные процессы

Но кроме технической части, я также управлял процессами:
✅ Нанимал и ротировал людей, создавая эффективную команду из ~ 30 человек, которая требовала координации и поддержки
✅ Проводил регулярные архитектурные созвоны, предлгая ключевые технические решения
✅ «Продавал» заказчику новые технологии, объясняя их ценность и обосновывая необходимость внедрения

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

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

Если интересно — тегайте @mercdevchat в комментариях, с радостью расскажу ещё пару карьерных историй. А у вас как? Делитесь самыми яркими моментами из своей карьеры — будет интересно почитать!

🔥 Быть активным в компании — это плюс или ловушка?
С одной стороны, активность = заметность. Ты участвуешь в митапах, двигаешь инициативы, знакомишься с топами. Карьера растёт! 🚀

Но не всё так просто:
⚡ Перегореть легко — ты делаешь больше, но зарплата остаётся прежней. В большинстве случаев корпоративные инициативы не оплачиваются.

⚡ Не все любят энтузиастов — можно нарваться на сопротивление «старожилов», которым и так нормально.

⚡ Активность ≠ результат —важны не только идеи, но и их реальная польза.

🎯 Кейc: как я запускал Random Coffee и что из этого вышло
На прошлой работе я внедрил Random Coffee — Slack-бот, который автоматически соединял случайных коллег на короткие встречи. Где-то это оживило коммуникацию, а где-то бот просто висел мёртвым грузом. Почему так?

🔹 Культура. В закрытых средах люди не готовы болтать с незнакомцами, особенно из других локаций или на другом языке. Тут я часто видел “сопротивление” для общения между людьми в разных локациях.

🔹 Формат. Без явной пользы (например, обмена опытом) разговоры быстро превращались в «привет-пока». Для интровертов — вообще стресс. Для продуктивных - путая трата времени.

🔹 Навязанность - если людей заставляют участвовать, а не вовлекают, инициатива тухнет. А если не навязывают, то сложно набрать аудиторию.


🚀 Вывод: активность тоже надо продавать
⚡ Любую инициативу нужно продвигать, как pet-project. Недостаточно просто придумать что-то полезное — важно донести ценность и найти сторонников.

⚡ SSM важен даже внутри компании. Нужно уметь продавать идеи командам, менеджерам, и даже CEO.


Этот проект я вёл несколько лет — и за это время я не успел перегореть. Он мне дал много новых, полезных знакомст, а еще удовлетворения от хорошей затеи.


Так что же лучше: тихо работать или заявлять о себе? Делись своим опытом! 👇

PS: Если вы хотите запустить random coffee в своей компании - feel free to use https://github.com/kvendingoldo/random_coffee_slack