вот и 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 в разных командах: делимся подходами и обсуждаем, что работает лучше всего.

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

Когда можно считать себя senior-разработчиком?

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

Вот ключевые признаки senior-а:

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

Сеньор — это тот, кто берет задачу, доводит её до конца и видит, какую ценность это приносит компании.

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

Soft skills. Умение общаться с коллегами из других отделов (продукт, дизайн, маркетинг), менторить junior-разработчиков и доносить свои идеи — критически важно.

Чем выше уровень, тем больше обсуждений и компромиссов с бизнесом.

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

Ты перестаёшь ныть о "неправильных" процессах и начинаешь думать, как улучшить бизнес. Это и есть переход в сеньорство

Можно ли считать себя senior, если не работал в этой должности, но запускал свои стартапы?

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

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

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

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

Как бороться с синдромом самозванца?

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

Отделяйте себя от навыка. Если не получилось — это не вы «плохой», просто пока нет нужного опыта.

Ведите дневник достижений. Записывайте положительные фидбэки, успешно завершённые задачи и ситуации, где вы проявили инициативу.

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

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

Не сравнивайте себя с идеалом. Всегда найдется кто-то круче. Важно сравнивать себя с собой в прошлом.

Помните, что senior — это не "всезнайка". Senior-разработчик тоже учится и ошибается. Главное — уметь быстро находить решения и исправлять ошибки.

Используйте синдром как мотивацию. Легкая неуверенность может подталкивать к развитию. Главное — не давать ей парализовать себя.

Senior — это не звание, а образ мышления

Если этого еще недостаточно, чтобы развеять сомнения в своей сеньорности, – записывайтесь на консультацию. За 15-30 минут с преподавателем вы определите свои сильные и слабые стороны, составите план развития и узнаете, чем на этом пути вам поможет курс [из Middle в Senior]. Подробности по ссылке 🔗

Навыки техлида: критическое мышление и problem solving

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

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

💡 Problem solving — это способность находить решения даже в условиях неопределенности и ограниченных ресурсов. Для техлида это значит не просто "погасить пожар", а разобраться в первопричине проблемы, чтобы избежать её повторения в будущем, а зачастую – предвидеть проблему заранее. Это включает умение четко формулировать проблему, быстро исследовать возможные подходы и выбирать наиболее эффективное и рациональное решение.

Как меняется навык от middle до техлида?

Middle-разработчик владеет навыками problem solving на уровне конкретных задач. Он решает проблемы самостоятельно в рамках заданного контекста.

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

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

Как развивать критическое мышление и problem solving?

1️⃣ Практикуйте глубокий анализ. Вместо того, чтобы использовать первое попавшееся решение, всегда задавайте вопрос: "Почему именно так?" Рассматривайте альтернативы и их последствия.

2️⃣ Учитесь задавать правильные вопросы. Чем выше уровень вашей позиции, тем важнее качество задаваемых вопросов. Учитесь докапываться до сути проблемы.

3️⃣ Разбирайте кейсы и ошибки. Проводите ретроспективы и post-mortem-аналитику. Разбор реальных кейсов помогает увидеть слабые места в логике решений и выработать навык системного подхода к решению задач.

4️⃣ Развивайте системное мышление. Не смотрите на проблему изолированно. Учитесь видеть взаимосвязи между компонентами системы, их влияние друг на друга и долгосрочные последствия решений.

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

6️⃣ Приходите на курс [Технический Лидер] и развивайте эти навыки на практических задачах и в обсуждениях с преподавателем и другими senior+ инженерами. Записывайтесь на консультацию!

🚀 AI в разработке: от хайпа к реальности

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

Приходите завтра на доклад — Денис Филипкин поделиться личным опытом. Поговорим:

🧩 AI в коде — как он меняет игру и чего ждать дальше

🧩 Мой опыт — где AI помог, а где только мешал

🧩 Кейс с Cline — конкретный проект и что получилось

🧩 Q&A + обмен опытом — обсудим, кто как работает с AI

📅 22.04 в 20.00 GMT+3

Зарегестрироваться и оставить свои вопросы можно по ссылке. До встречи!