Написал какой-то код, получил зарплату. А что дальше?

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

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

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

Чтобы по-настоящему влиять на продукт, просто писать код недостаточно – нужно расширять свой скоуп ответственности:

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

🎓 Менторьте и помогайте коллегам
Один из самых эффективных способов почувствовать себя полезным — это делиться знаниями. Дайте чуть больше подробностей на код-ревью, проведите внутренний митап для команды, попробуйте себя в роли спикера на мероприятиях Hard&Soft Skills 😉

📈 Фокусируйтесь на impact, а не на output
Количество написанного кода или закрытых задач – это метрика для вашего менеджера, но не для оценки своей полезности. Вместо этого задайте себе вопрос: "Как мой код или решение повлияет на продукт, пользователей или бизнес?" Даже если это небольшой модуль, подумайте, как он улучшит производительность, упростит жизнь другим разработчикам или решит проблему пользователя.

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

Навыки техлида: технический кругозор

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

Почему развитие кругозора особенно важно для роста из senior-разработчика до техлида?

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

1️⃣ Принятие архитектурных решений

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

2️⃣ Коммуникация с командой и стейкхолдерами

Техлид выступает мостиком между разработчиками, менеджментом и бизнесом. Чтобы объяснить, почему выбран тот или иной подход, нужно понимать альтернативы и их плюсы/минусы.

3️⃣ Масштабирование решений

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

4️⃣ Менторство и развитие команды

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

Как развивать технический кругозор?

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

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

- Общайтесь с коллегами. Посещайте митапы, конференции и воркшопы. Обмен опытом с другими разработчиками — один из самых эффективных способов расширить кругозор.

- Пройдите курс [Технический Лидер]. В нем уже систематизированы архитектурные компоненты – от баз данных и кэшей до балансировщиков и ORM фреймворков. Выбор подходящих инструментов отработаете на практических архитектурных задачах, а решения этих задач обсудите с преподавателем и другими участниками курса.

🚀 Погружаемся в мир GenAI!

Друзья, вчера состоялась первая часть доклада Вадима Гацура о разработке GenAI-приложений, и это было cильно 💡

За два часа встречи мы успели подробно разобрать:
➡ Как устроены LLM и как их обучают
➡ Ключевые концепции: in-context learning, RAG, fine-tuning
➡ Что такое AI-агенты и мультиагентные системы

🔗 Запись уже доступна на YouTube – не пропустите, если хотите разобраться в теме!

Вторая, практическая часть доклада не за горами – stay tuned! 😎

Кстати, на нашем YouTube-канале есть еще много полезных записей, из последнего:

🎙️ Собеседования 2.0 – как мы изменили процесс найма и что из этого получилось (Алексей Лобан)
🎙️ Токсичные "гении" в разработке – как с ними работать и выжить (Алексей Яговкин)
🎙️ Бизнес-метрики для техлидов и архитекторов – что нужно знать (Антон Дворников)

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

Microsoft анонсировала квантовый чип Majorana 1, основанный на новой архитектуре Topological Core. Обещают до миллиона кубитов на чипе, которые к тому же стабильны и защищены от случайных помех.

«Мы буквально напыляем атом за атомом, чтобы создать идеальные условия для работы кубитов. Если в структуре материала есть дефекты, это может полностью разрушить квантовую систему»

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

Подробнее:
https://news.microsoft.com/source/features/ai/microsofts-majorana-1-chip-carves-new-path-for-quantum-computing/
https://habr.com/ru/companies/first/articles/884146/

Привет! Если вдруг пропустили нашу рассылку, то завтра у нас Круглый стол про роль Solution Architect в компаниях.

👨‍💻Ведущий - Антон Дворников, Principal Solution Architect.

Начало в 20.00 GMT+3

🔗 Подробная программа и регистрация по ссылке

вот и AWS подтянулся со своим квантовым чипом https://www.perplexity.ai/page/amazon-debuts-quantum-chip-8xhHs8EDRsGDtC0UYG4xTg

имеем google willow, microsoft majorana, aws ocelot. Дамы и господа, мы внутри еще одной гонки.

Разбираем по косточкам роль SA в компаниях, присоединяйтесь🚀

Чек-лист: готовы ли вы стать архитектором?

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

Проверьте себя, готовы ли вы к таким переменам, с помощью нашего чек-листа:

1️⃣ Ключевые навыки, которые отличают архитектора от разработчика:

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

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

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

Глубокое понимание нефункциональных требований. Производительность, безопасность, масштабируемость, доступность – это ваша зона ответственности. Вы должны уметь проектировать системы, которые не только работают, но и делают это эффективно.

Знание архитектурных паттернов и подходов. Микросервисы, event-driven архитектура, CQRS, SOA – нужно не только знать эти концепции, но и понимать, когда и как их применять.

2️⃣ Опыт, который поможет быть архитектором

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

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

Опыт работы с legacy-системами. Умение работать с устаревшим кодом и постепенно его модернизировать — это важный навык, который поможет справляться с техдолгом.

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

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

3️⃣ Аспекты работы архитектора, к которым нужно быть готовым

Меньше кодинга, больше документирования. Архитектор пишет код редко. Основное время уходит на проектирование, документацию и обсуждения.

Ответственность за решения. Ваши решения могут повлиять на весь проект. Ошибки архитектора дорого обходятся компании, и это давление не для всех.

Постоянные компромиссы. Вам придется выбирать между несколькими вариантами "достаточно хорошо" вместо “идеально”. Это кошмарный сон для перфекционистов.

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

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

Если вы отметили большую часть чек-листа — вы на верном пути. Следующий шаг – изучите наши материалы о роли архитектора:

📺 Круглый стол Solution Architect: путь, навыки, перспективы
📺 Этапы роста и развития архитекторов. Software Craftsmanship Meetup №27
📺 Принятие архитектурных решений. Software Craftsmanship Meetup №26

А затем – изучите программу курса [Solution Architect in the Wild]. Или [Технический Лидер], если вы пока не готовы отрываться от техники. Записывайтесь на консультации!

Дорогие девушки! 💐

Поздравляем вас с 8 марта!

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

Помните, даже самые сложные проблемы иногда решаются простым перезапуском и чашкой чая 😉

С праздником! 🥂

Привет!

Уже завтра встретимся на H&S Conclave, чтобы поговорить о том, как управлять собственной заметностью на работе:

- Карьерные лестницы в ИТ: управленческая и техническая.
- Как решения других людей влияют на вашу карьеру?
- Экологичное повышение visibility: как правильно управлять своей заметностью?
- Практические советы, как показать ценность вашей работы без излишнего самолюбования.

«Карьера — это сумма решений, которые в отношении вас принимают другие люди» (Михаил Завилейский, основатель DataArt).

🧑‍💻 Спикер: Александр Орлов, управляющий партнер Школы менеджмента «Стратоплан», автор книги «Джедайские техники конструктивного общения». В прошлом, менеджер в Intel и Sun Microsystems, Inc.

🔗 Регистрация на ивент по ссылке

👉 Друзья, мы начинаем доклад Александра Орлова, из Cтратоплан, про повышение видимости в компаниях. Присоединяйтесь в Google Meet

Всем привет!

Приходите завтра на доклад Илья Кремнева про XZ Backdoor или как взломали Linux

Доклад посвящён разбору резонансного инцидента с XZ Backdoor: как появилась уязвимость в liblzma, как долго она оставалась незамеченной и какие риски подобные инциденты несут для open-source проектов. Также поговорим о способах выявления подобных угроз и мерах по защите зависимостей в будущем.

🔗Регистрация как обычно на сайте.

PS. Запись вчерашнего доклада про то как повышать видимость внутри компании и снаружи можно посмотреть на нашем ютубе.

До завтра!

Друзья, забегайте к нам в Google Meet обсудить прошлогодную атаку на Linux и какое будущее ждет open-source в связи с подобными инцидентами. Мы только начали🚀

Книги, которые стоит прочитать, если хочешь стать solution-архитектором

1. "Patterns of Enterprise Application Architecture" — Martin Fowler
Эта книга — классика для архитекторов, работающих с enterprise системами. Она учит, как проектировать системы, которые легко развивать и поддерживать, даже в условиях большой нагрузки и сложности.

💡Что даст:
- Знание ключевых паттернов проектирования для создания масштабируемых и поддерживаемых enterprise-приложений.
- Понимание, как применять эти паттерны в реальных системах.
- Умение разделять компоненты системы для повышения модульности и гибкости.

2. "Technology Strategy Patterns: Architecture as Strategy" — Gregor Hohpe
Solution-архитектор должен не только проектировать системы, но и понимать, как они вписываются в бизнес-стратегию. Эта книга поможет мыслить стратегически.

💡Что даст:
- Понимание, как выстраивать технологическую стратегию, которая соответствует бизнес-целям.
- Научит разбираться в том, как снижать затраты, внедрять инновации и удерживать систему и организацию от размывания.
- Навыки создания технологического roadmap для приоритизации инициатив и инвестиций.

3. "Software Requirements" — Karl E. Wiegers
Архитектор должен уметь работать с требованиями. Эта книга поможет лучше понимать, как требования формируют архитектуру.

💡Что даст:
- Навыки работы с требованиями: их сбор, анализ, спецификация и валидация.
- Понимание, как требования влияют на архитектуру системы.
- Умение использовать моделирование, прототипирование и тестирование для проверки требований.

4. "Impact Mapping: Making a big impact with software products and projects" — Gojko Adzic
Еще одна книга о взгляде на разработку со стороны бизнеса. Она научит, как проектировать системы, которые приносят реальную пользу бизнесу.

💡Что даст:
- Навыки создания impact maps для выравнивания разработки с бизнес-целями.
- Понимание, как фокусироваться на результатах, а не на функциональности.
- Умение работать с минимально жизнеспособными продуктами (MVP) для быстрого получения обратной связи.

Работа SA – не только о технике, а еще о взаимодействии с людьми и выстраивании долгосрочной стратегии. Эти книги помогут заполнить пробелы и увереннее подходить к архитектурным задачам.

О книгах с фокусом именно на проектирование архитектуры мы писали в одном из прошлых постов.

📈 Поговорим о росте и развитии архитектора

✅ Как различаются взгляды на систему у Senior разработчика, техлида, Solution и Enterprise архитектора?
✅ Чем занимаются Solution, Enterprise, Data, ML, Cloud, Integration и другие архитекторы?
✅ Как архитектор переходит от технических решений к бизнес-фокусу, начинает масштабировать архитектуру и выстраивать технологическую стратегию компании?
✅ Как балансировать между time-to-market и техдолгом, справляться с legacy, со сложной бизнес-логикой, с ростом бизнеса и с влиянием корпоративной культуры
✅ Как архитектору эффективно взаимодействовать с low-code/no-code решениями и интегрировать AI-инструменты в архитектуру компании.

А также представим обновленную программу курса [Solution Architect in the Wild] v3

📅 Дата: 26 марта
⏰ Время: 20:00(GMT+3)

Ведущие:
Павел Вейник - Solution Architect, Staff Engineer
Антон Дворников - Principal Solution Architect

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

Будущее профессии Solution Architect: что ждет нас в ближайшие годы?

Профессия архитектора меняется вместе со всей индустрией IT. Две недели назад мы затронули эту тему вместе с участниками круглого стола о роли Solution Architect. Вот краткие выводы:

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

AI возьмет на себя рутину, некритичный код, оформление документации и быструю сборку POC. А архитекторы будут больше сосредоточены на творческих аспектах и поиске компромиссов между бизнес-требованиями и техническими ограничениями.

⚖️ Во-вторых, индустрия IT быстро оптимизируется и стандартизируется после периода взрывного роста, который был до 2022 года. Это касается сокращения людей и ролей в компаниях, а также внедрения подходов вроде "архитектура как код" и "документация как код".

🗣 В-третьих, работа архитектора по большей части не о проектировании, а о взаимодействии с людьми: бизнес-стейкхолдерами, менеджерами, разработчиками. Никакая автоматизация не сможет полностью заменить человеческое общение.

Что изучать, чтобы не отстать?

ИИ, автоматизация и no-code/low-code. Новые инструменты уже меняют индустрию. Чтобы оставаться эффективным и конкурентоспособным, архитектору нужно знать, как ими пользоваться.

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

Архитектурные паттерны и best practices. Несмотря на любые изменения в работе SA, чтобы проектировать хорошие системы, нужно знать, как их сделать хорошими.

🗓 26 марта мы встретимся с Павлом Вейником и Антоном Дворниковым, чтобы поговорить о роли Solution Architect:

🔹 Карьерный путь к архитектуре. Рост и развитие Solution Architect.
🔹 Типы архитекторов и зоны ответственности.
🔹 Работа в команде архитекторов и реальные вызовы в этой работе.
🔸 Как архитектору эффективно взаимодействовать с low-code/no-code решениями и интегрировать AI-инструменты в архитектуру компании.

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

Как ИИ и автоматизация вытесняют middle-разработчиков — и что с этим делать

1️⃣ Что уже произошло: ИИ, low-code и автоматизация меняют рынок

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

🔹Джуны и слабые middle-разработчики становятся не нужны. ИИ справляется с рутинным кодом, шаблонными задачами и тестированием. No-code-платформы позволяют бизнесу собирать приложения без программистов.

🔹Тестировщики и продакт-оунеры под ударом. А менеджеры, не разбирающиеся в технике, теряют ценность.

🔹Архитекторы и senior-разработчики тоже не в безопасности. Компании сокращают бюджеты, и дорогие специалисты теперь должны доказывать, что их работа критически важна.

2️⃣ Что будет дальше?

Через несколько лет рынок изменится ещё сильнее:

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

🔸Порог входа в IT резко вырастет. Чтобы попасть в индустрию, нужно будет сразу обладать навыками сегодняшнего middle+.

🔸Останутся только две категории разработчиков:
- Те, кто автоматизирует автоматизацию (пишут инструменты для ИИ и low-code).
- Те, кто работает с фундаментальными системами (базы данных, инфраструктура, AI/ML).

3️⃣ Что делать middle-разработчику, чтобы выжить?

Краткий ответ – расти до сеньора. Для этого:

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

✅ Прокачивайте soft skills. Учитесь понимать стейкхолдеров, объяснять и отстаивать свои технические решения. Разбирайтесь в процессах разработки и людях, которые их создают и поддерживают.

✅ Разбирайтесь в AI и автоматизации. Передайте рутинные задачи ИИ, а сами сфокусируйтесь на сложных вещах.

📆 2 апреля на митапе [из Middle в Senior] подробно поговорим о том, какие навыки отличают сеньора от мидла, что изучать, чтобы перейти на следующий грейд, и чего не хватает именно вам.

Ведущие:
Павел Вейник - Solution Architect, Staff Engineer
Светлана Семёнова - Senior Software Engineer

Регистрируйтесь по ссылке и увидимся в среду!

Как проходят курсы в Hard&Soft Skills? Посмотрим, что обсуждают участники [Технического Лидера]

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

1. Как применять шаблон решения архитектурных задач для презентации технических решений

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

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

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

✅ По отзывам, после внедрения шаблона количество коммуникаций по решениям уменьшилось в 2-3 раза за счет понятности, логичности и обоснованности этих решений.

2. End-to-end тесты и перегруженная очередь сообщений

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

Как это получилось решить?

🔹 Внедрили пирамиду тестирования:

– Много юнит-тестов (десятки тысяч).
– Меньше компонентных тестов (сотни/тысячи).
– Совсем немного end-to-end тестов (десятки). Их задача — проверить взаимодействие сервисов, а не логику внутри компонентов.

🔹 Постепенно заменили тяжелые end-to-end тесты на моки или тесты более низкого уровня.

В результате время тестирования сократилось с 60 часов до 2-3 часов, просто за счет пересмотра подхода и удаления лишних end-to-end проверок. При этом качество контроля только выросло.

3. Код-ревью

Вопрос о код-ревью вызвал оживленную дискуссию. Вот ключевые моменты:

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

❗️Важно:
Если разработчики «дают слабину», возможно, проблема в мотивации или культуре команды, а не в код-ревью как таковом. Код-ревью — не просто формальность, а инструмент роста.

Друзья, завтра встречаемся на новый H&S Conclave доклад "RUST: панацея или просто ещё один язык?"

Rust продолжает набирать популярность, но стоит ли он хайпа? Разбираемся без иллюзий:

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

🔸 Обзор принципов языка:
Четыре столпа Rust — это революция или просто эволюция? Как Rust обеспечивает безопасность и производительность на практике.

🔸 Как стать Rust-инженером:
Порог вхождения, подводные камни и советы тем, кто хочет освоить Rust.

🔸 Выводы:
Стоит ли переключаться на Rust прямо сейчас? И что важно знать перед тем, как сделать этот шаг.

Приходите! Регистрация по ссылке ⚙️🦀

🔥 Уже сегодня вечером поговорим о лучших практиках Code Review! Приходите послушать опыт спикера и поделиться своими инсайтами.

🗓 Когда: 10 апреля, в 20:00 (GMT +3)

🎙 Спикер: Виктория Телюк — Senior Java Backend Developer, Code Quality Advocate

💡 В программе доклада:

‣ Статистика из реального кейса
Насколько нам удалось улучшить качество кода и какую роль сыграл post review.

‣ Проверенные практики для эффективного code review в команде.

‣ Топ-10 самых частых проблем при ревью кода
Рейтинг типичных ошибок и как их выявлять и предотвращать.

‣ Обмен опытом
Как организован процесс code review в разных командах: делимся подходами и обсуждаем, что работает лучше всего.

👉 Зарегистрироваться и оставить вопрос спикеру — по ссылке. До встречи!