Друзья, если вчера пропустили, Software Craftsmanship Meetup уже доступен на нашем ютубе.
🔗 Майндмэп по ссылке
Приятного просмотра и хороших выходных!

Как проектировать систему, не зная деталей кода

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

💡Системы строятся на нескольких уровнях абстракции:

1. Низкоуровневый код (ассемблер, машинный код)
2. Языки высокого уровня (Java, Python и др.)
3. Фреймворки и библиотеки
4. AI-инструменты, no-code и low-code решения

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

Чем шире скоуп ответственности, тем на более высоком уровне абстракции нужно рассуждать:

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

❗️Преодоление боязни отрываться от кода – умение делегировать и доверять тем, кто реализует код. Рост выше сеньора без этого невозможен. Архитектор может не знать особенностей recovery в Kafka или всех деталей работы Cassandra. Достаточно понимать:

▫️ Основные принципы работы технологий
▫️ Их сильные и слабые стороны
▫️ Типовые сценарии применения
▫️ Базовые гарантии, которые они предоставляют

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

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

Архитектор может и должен знать, как устроены наиболее критичные части системы. Но погружение в детали не должно мешать видеть общую картину и решать главную задачу – создание работающего продукта для бизнеса. Как это делать – учим на курсе [Технический Лидер]. Стартуем уже на этой неделе – успейте записаться!

Привет! Завтра в 20.00 GMT+3 на H&S Conclave будем разбираться как обращаться с токсчиными звездами в команде.

Обсудим:
✔️ Почему мы терпим разработчиков, которые приносят отличные результаты, но отравляют атмосферу в коллективе?
✔️ Правда ли, что "гений" может быть незаменимым, или он тянет команду вниз?
✔️ И самое главное — почему софт-скиллы для разработчиков так же важны, как технические знания?

🔗 Регистрация на сайте. До встречи!

Как спроектировать систему, которую все будут ненавидеть, и стать легендой

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

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

1️⃣ Микросервисы — это модно и современно, но зачем усложнять себе жизнь?

Монолит – это понятно и даже звучит надежно. Поэтому сделайте свои микросервисы похожими на монолит!

Совет 1: Пусть каждый сервис знает всё о своих соседях. Зачем нужны API, если можно просто дергать друг друга напрямую?

Совет 2: Обязательно сделайте цепочки вызовов. Например, чтобы обработать один запрос, сервис A должен вызвать B, B — C, а C — снова A. Разработчики работают в команде, пускай сервисы тоже будут командой!

Совет 3: Используйте общую базу данных для всех сервисов. Это же так удобно — не нужно думать о консистентности данных, транзакциях и миграциях.

2️⃣ Игнорируйте изоляцию сбоев

Наши сервисы – это команда, а в команде все проблемы должны быть общими.

Совет 4: Никаких circuit breakers, retry-логики и bulkheads. Пусть один упавший сервис валит всё подряд.

Совет 5: Если сервис упал, пусть он продолжает пытаться выполнить запрос бесконечно. Это же упорство, а не баг!

Совет 6: Не тестируйте отказоустойчивость. Зачем тратить лишние ресурсы, если пользователи сами найдут все баги?

3️⃣ Предсказывайте будущее

Гениальный архитектор видит развитие системы на годы вперед. Зачем впопыхах переписывать систему, если можно подготовить все заранее?

Совет 7: Добавьте в систему все возможные абстракции, которые могут когда-нибудь пригодиться. Если вы делаете интернет-магазин, сразу добавьте поддержку квантовых вычислений. Вдруг пригодятся?

Совет 8: Создайте десятки слоев абстракции. Если разработчики тратят 80% времени чтобы понять, как работает код, – это их проблема, что они не гении.

Совет 9: Не документируйте ничего. Пусть вся информация о том, как работает система, будет только у вас в голове. Все равно документацию никто не читает.

4️⃣ Демонстрируйте интеллектуальное превосходство

Ваша цель — создать систему, которая будет жить вечно, потому что никто не сможет её понять или изменить.

Совет 10: Используйте максимально сложные технологии. Зачем брать проверенные решения, если можно взять что-то экспериментальное и модное? А еще лучше – написать все самостоятельно!

Совет 11: Никогда не проводите рефакторинг. А что, разработчики не могут сразу написать хорошо?

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

5️⃣ Убедите бизнес, что всё идёт по плану

Бизнес не должен знать, что система — это бомба замедленного действия.

Совет 13: Говорите, что все проблемы — это временно. Например: "Мы просто в процессе оптимизации, скоро всё наладится".

Совет 14: Обвиняйте разработчиков. Это они не смогли понять вашу гениальную архитектуру.

Совет 15: Постоянно меняйте требования. Пусть команда думает, что это бизнес виноват, а не ваша переусложненная система.

6️⃣ Заключение: как стать легендой

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

Но если вдруг вы передумаете и захотите создать что-то полезное, просто сделайте всё наоборот. А лучше записывайтесь на курс [Технический Лидер] и проектируйте эффективные системы вместо легендарных!

Друзья, 20 февраля приглашаем вас на H&S Conclave c Алексеем Лобан на тему "Собеседования 2.0: что мы изменили в нашем подходе и как это повлияло на найм"

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

Программа доклада:
🔍 Фильтр на старте: как анализировать резюме и отбирать кандидатов на собеседование.
🔍 Кого мы ищем? Определение grade разработчика и соответствующих задач.
🔍 Вопросы с фокусом на человека, а не GPT – как составить интервью, которое раскрывает кандидата.
🔍 Красные флаги на собеседовании: какие сигналы должны насторожить.
🔍 Советы для тех, кто в поиске работы: что важно учитывать, проходя интервью.

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

🔗Регистрация на сайте. До встречи!

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

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

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

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

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

💡Участвуйте в принятии решений
У 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 – не только о технике, а еще о взаимодействии с людьми и выстраивании долгосрочной стратегии. Эти книги помогут заполнить пробелы и увереннее подходить к архитектурным задачам.

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