В прошлый четверг мы провели 28-й Software Craftsmanship Meetup в новом формате – live design session.

Павел Вейник вместе с участниками митапа в подробностях разбирали классическую задачу на system design – высоконагруженный сокращатель ссылок:

- Определили функциональные и нефункциональные требования к системе
- Рассчитали нагрузки, объем памяти и хранилища, пропускную способность сети, необходимые для работы системы
- Выявили узкие места
- Определились с алгоритмами сокращения и расшифровки ссылок, и подобрали некоторые инструменты, которые могут обеспечить их работу

🎥 Запись встречи на YouTube

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

🔗 Регистрируйтесь на вторую часть митапа по ссылке!

Отвечаю на следующий вопрос, заданный в регистрациях на 28й митап.
Короткий ответ - забота о безопасности должна соответствовать нефункциональным требованиям.
Что потеряет бизнес если произойдет утечка данных - все, ничего, или наоборот окажется хорошим PR?
Что произойдет, если сервис будет лежать под DDOS - полный крах, легкое неудобство или ничего?
Редко ущерб будет действительно большой.
В любом случае, не нужно выстраивать более дорогую систему безопасности, чем того требует бизнес.
Кроме того, безопасность - в большей степени дело дисциплины, процессов и процедур, чем реально техническая задача. Потому что против бумажки с паролем под клавиатурой, которая потом попала в мусорку, ничего противопоставить нельзя.

Смотря что тут понимается под анализом требований. Если анализ уже готового дока на 146 страниц - то AI может пригодиться, а если требования в головах стейкхолдеров, то никакой AI не поможет. Приходится звониться с ними и разговаривать, заниматься requirement management и разрешать противоречия между интересами разных стейкхолдеров.

Никак. Совсем никак.
Просчетов не будет только если вы только что сделали 3 таких же задачи - но ведь так не бывает.
Чтобы уменьшить просчет, нужно более тщательно проектировать, докапываясь до corner cases, ошибок и их обработчиков, особенно если речь про бизнес-логику и транзакции. Описывать действия вплоть до алгоритма, прогонять этот алгоритм на бумажке/доске раз 15, чтобы понять где прокол. Тогда все мыслительные операции будут отдельно от кодирования, и уже написанный код не будет мешать думать. Покрывать тестами важные куски, чтобы в процессе следующих задач не поломать эту задачу.

Добавить к оценке время на отработку пайплайна, или на ручные проверки.

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

Это был последний вопрос к 28му Software Craftsmanship Meetup. Завтра будет митап, посвященный рост после сеньера, вот там вопросов примерно 61. Задать вопрос сюда https://hardsoftskills.dev/meetup_technical_leader_1912

🥂Всех с пятницей!

Вчера прошел митап [Технический Лидер]. Обсуждали рост инженера, стеклянный потолок сеньора, и что нужно, чтобы его пробить.

Отдельно поговорили о ситуации на рынке IT сейчас и чего ждать в 2025 году. (спойлер - очень тревожно)

📹 Видео уже на YouTube - приятного просмотра!

А еще можете посмотреть запись выступления Павла Вейника для выпускников Стратоплана, которое состоялось в эту среду:

Связь между организацией, архитектурой и мелкими проблемами в разработке

1️⃣ перегруженные техлиды
2️⃣ отсутствующие архитекторы
3️⃣ повышение за выслугу лет и лояльность
4️⃣ оторванные от жизни платформенные команды
5️⃣ core команды, правящие баги всей системы
6️⃣ архитекторы, не создающие правил в большой системе

Что может делать техлид для развития команды?

Работать над тем, чтобы команда разработки лучше выполняла свои задачи – это то, зачем техлиду приставка “лид”. При этом, прямой власти у техлида может и не быть. Часто это роль, а не должность, и техлид – это самый опытный сеньор, первый среди равных.

Развивать команду можно несколькими путями:

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

📃 Через стандарты и документацию – определить четкие требования к тестам и гайдлайны к стилю и форматированию кода, шаблоны компонентов системы. Собрать правила в одном месте, например в репозитории, чтобы они были под рукой.

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

А что если сотрудник не хочет развиваться?

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

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

Культура команды начинается с ее лидера.

Требуя развития от коллег, не забывайте расти сами. Узнайте, что для этого нужно, на консультации перед курсом [Технический Лидер]!

Итоги года для Hard&Soft Skills мы подвели, а каким 2024 был для IT в целом?

Немного статистики:

🚫 Лэйоффы затронули 240 тысяч человек в tech индустрии. Это почти вдвое меньше, чем в прошлом году, но сопоставимо с 2022.
📃 Количество открытых вакансий выросло на 18% с начала года.
📉 По данным LinkedIn, Hiring rate снизился на 1,2% по сравнению с прошлым годом. (и на 17% по сравнению с 2016)

На 2025 год прогнозов много и все они разные: от сдержанного оптимизма по поводу роста рынка на 8-9%, до предсказаний, что IT – это пузырь, который вот-вот лопнет.

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

Это связано с тем, что поток бесплатных денег от венчурных фондов сильно сократился, и теперь компаниям приходится оптимизироваться. Раньше работала следующая цепочка:

Условный Amazon торгуется по цене 20x своей выручки и может брать в инвестиционных фондах деньги под минимальные проценты.
⬇️
Он покупает за 100 миллионов стартап, который делает 10 миллионов выручки в год и присоединяет его к себе.
⬇️
Поскольку Amazon торгуется по цене 20х к своей выручке, то его капитализация вырастает на 200 миллионов.

После 2022 года быстрый рост ради самого роста уже не оправдывает вливание средств – инвесторы хотят видеть cash flow и прибыльность. Новая схема такая:

Private equity фонды за бесценок скупают IT-компании, которые находятся в тяжелом состоянии. Они срезают большую часть расходов, а это значит увольняют огромное количество инженеров и менеджмента. В итоге превращают этот бизнес в маленький cashcow, который не развивается, но приносит прибыль здесь и сейчас.

Один из громких примеров такой модели – покупка беларусской компании Apalon. В начале 2024 года ее приобрел итальянский разработчик игр Bending Spoons. Всю команду – 330 человек – при этом уволили.

Что это значит для разработчиков?

🔹 Как раньше уже не будет. Получить 3 оффера за день просто ответив на входящие запросы рекрутеров уже не получится.
🔹 Нужно понимать бизнес, и какую пользу ваша работа ему приносит.
🔶 Хорошие специалисты востребованы всегда, особенно в тяжелые времена. Пример – отзывы наших выпускников из предыдущего поста. Хотите обезопасить себя – записывайтесь на курс [Технический Лидер].

Согласны с такими выводами? Делитесь в комментариях 👇

Что делать разработчику, чтобы оставаться востребованным в 2025 году?

Об этом и не только будем говорить на открытом митапе [Технический Лидер].

🗓 23 января
⏰ 19:00(GMT+3)

Обсудим карьеру разработчика, навыки сеньора и техлида. Посмотрим на рынок труда, тренды индустрии IT и что изучать, чтобы расти по карьере, получать интересные задачи и увеличивать свой доход.

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

Как техлиду подружить ожидания стейкхолдеров с реальностью?

💼 Бизнес хочет, чтобы все работало и приносило как можно больше денег как можно быстрее.

💻 Разработчики хотят делать интересные сложные решения, и чтобы им не мешали делать красиво и качественно.

🎯 Менеджеры хотят, чтобы планы соблюдались, KPI выполнялись, подчиненные слушались, а руководители не продавливали очередные очень важные и срочные задачи.

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

Инструмент только один – коммуникации. Говорить со всеми, пытаться понять их точку зрения, пояснять свою, спорить, договариваться и искать компромиссы.

А чтобы облегчить коммуникации и сделать их эффективнее – нужен авторитет.

Как его завоевать?

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

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

🔹Способ донесения информации важнее содержания. У всех есть эго. Критикуя работу коллег важно помнить об этом и стараться лишний раз его не задевать. Сказать “это – говно, переделывай" проще всего, но нужно ли?

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

О роли техлида, и чем она отличается от тимлида и архитектора приходите послушать 23 января на митапе [Технический Лидер].

🚀 Всем привет!

В этот четверг, 16 января, проведем вторую часть Live Design Session про высоконагруженный сокращатель ссылок.

В прошлый раз мы проанализировали функциональные и нефункциональные требования, провели подробные расчеты нагрузок на систему – RPS, CPU, сети и объема хранилища данных.

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

Запись можно посмотреть тут

На второй встрече перейдем непосредственно к System Design – спроектируем всю систему, нарисуем диаграммы и выберем БД, кэши и другие инструменты.

📅 16 января
⏰ 20:00 (GMT+3)

Регистрируйтесь на сайте и до встречи на митапе!

❗️Важный анонс для тех, кто в Грузии

Во вторник 21 января Павел Вейник проведет оффлайн Tech Talk в офисе Andersen в Батуми. Тема:

Кэши: виды, критерии выбора, проблемы и способы их решения

• Для чего используется кэш;
• Стратегии обновления и удаления записей в кэше;
• Какие сейчас существуют кэши и похожие инструменты;
• Критерии выбора кэша для проекта;
• Использование кэша вместе с другими компонентами и внутри монолита;

📅 21 января
⏰ 19:00(Грузия) / 16:00(CET)
📍 Батуми, офис Andersen

Онлайн тоже будет – регистрация тут

А сегодня вечером встречаемся на продолжение Live Design Session по проектированию сокращателя ссылок.

Cобеседование на позицию senior+ – вопросы для работодателя и что подмечать в ответах

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

Тем не менее, задать эти вопросы все равно стоит:

- Что будет обязательно входить в мою рутину?
- С кем я буду работать?
- Кто будет мой руководитель? Кто принимает решения?
- Как выстроен процесс разработки? Какие коммуникации и согласования в этом процессе?

В дополнение к этим вопросам стоит уточнить про технику и архитектуру:

- Насколько модульное приложение? Есть ли CI/CD?
- Какая архитектура системы? Кто контролирует ее развитие?
- Как принимаются архитектурные решения?
- Ведется и обновляется ли документация?

Например, если в ответах на эти вопросы ни разу не было слова “микросервисы”, а ПО разрабатывается 10 лет, – значит, скорее всего, там монолит с кучей легаси.

На что стоит обратить внимание:

✅ Если руководитель прямо говорит о косяках, с которыми приходится работать, – “Есть такая проблема, которую мы решаем”. Обычно все рассказывают, какой у них замечательный проект, но в процессе работы всегда всплывают недостатки. Честность на собеседовании – однозначно зеленый флаг.

🚩 “Как вы справляетесь со стрессовыми ситуациями?” – На это можно ответить “А как часто у вас бывают стрессовые ситуации, и почему?” Разумеется, в работе случается всякое, но если работа сопряжена с постоянным стрессом – это говорит о серьезных проблемах в процессах.

🚩 ”Мы создаем уникальную технологию”. Действительно уникальных технологий единицы на весь мир. Создать свой собственный алгоритм автоматизиции или свою базу данных – амбиции, которые крайне редко оправданы.

✅🚩 Работа с рекрутером. Если все быстро, четко, конструктивно – это свидетельствует о том, что в компании процессы работают хорошо. В отделе разработки, конечно, все может быть совсем не так

Напротив, стоит задуматься, если рекрутер сам не очень понимает, кого ищет, если в требованиях к вакансии 40 технологий, а сами требования размытые или, наоборот, опыт работы с конкретной БД 3 года и никак иначе. Не говоря уже о знаках зодиака, таро и “какой у вас тип личности”. 🫣

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

🏔 Для тех, кто хочет с душой провести выходные в Грузии!

8-9 февраля
IT SOUL WEEKEND: выходные в горном SPA с ИТ-коммюнити

Хочется вдохновения, качественного общения и перезагрузки в уютной атмосфере? Присоединяйтесь к нам!
Едем в Горную Аджарию, в отель Chateau Milisi с панорамным видом на горы, бассейном и SPA зоной, чтобы отдохнуть и зарядиться, провести время в теплой компании, уделить внимание телу и душе, и наполненными вернуться обратно.

🔧 Features included:
• Warm & soulful conversations
• Relaxed, easygoing, and fun vibes
• Low or no-alcohol mode
• Deep talks with talented minds
• Attention to body and soul aspects

🎒Что по программе выезда:
• проживание в отеле Chateu Milisi (завтрак включен)
• трансфер из Батуми и обратно (выезд в 9 утра в субботу, в воскресенье в 7 вечера обратно)
• чай, телесные практики и йога, теплое общение
• бассейн, сауна, настольный теннис и бильярд

📅 даты выезда: 8-9 февраля;

💰Стоимость участия:
* 300 GEL ( 250 GEL Early bird до 1 февраля )

Бронирование и подробности - @NikShc ⠀

👋 Привет! Вчера у нас прошло сразу два мероприятия, так что, если не знаете, чем занять вечер – приятного просмотра!

1️⃣ В девятом докладе из серии H&S Conclave Елизавета Булыгина рассказала о том, как в больших fintech компаниях выстраиваются процессы управления командами, формируется продуктовый бэклог, реализуются задачи из этого бэклога, и какую роль в этом играет Solution Architect.

📺 Запись мероприятия уже на нашем YouTube-канале.

2️⃣ Павел Вейник выступил для компании Andersen на тему “Кэши: виды, критерии выбора, проблемы и способы их решения”. Встреча проходила очно в Батуми

📺 Посмотреть запись можно вот тут.

А уже завтра встретимся на митапе [Технический Лидер], где поговорим о росте разработчика выше уровня senior, роли и навыках техлида, а также взглянем на текущее состояние рынка IT в Европе и США, и обсудим, как разработчику оставаться востребованным сейчас и в будущем.

Регистрируйтесь и задавайте интересующие вас вопросы в форме!

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

1️⃣ "Designing Data-Intensive Applications" (Martin Kleppmann)

Это must-read для тех, кто работает с высоконагруженными системами. Книга особенно ценна тем, что:

- Детально разбирает различные модели данных (реляционные, документные, графовые) и помогает понять, когда какую использовать
- Объясняет принципы построения распределенных систем, включая работу с Apache Kafka, Hadoop и Spark
- Рассматривает стратегии масштабирования и отказоустойчивости
- Дает практические рекомендации по выбору технологий хранения данных

Плейлист с подробными разборами каждой главы от senior+ инженеров из нашего сообщества.

2️⃣ "Software Architecture in Practice" (Bass, Clements, Kazman)

Эта книга - отличный фундамент для понимания базовых концепций архитектуры ПО:

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

3️⃣ "Building Evolutionary Architectures" (Ford, Parsons, Kua)

Книга особенно актуальна для тех, кто работает над долгоживущими системами:

- Вводит концепцию "fitness functions" для оценки качества архитектуры
- Объясняет, как делать архитектуру адаптивной к изменениям
- Рассматривает практики resilience engineering
- Учит выстраивать процессы непрерывного улучшения архитектуры

4️⃣ "Software Architecture: The Hard Parts" (Ford, Richards, Sadalage, Denghani)

Практическое руководство по современной распределенной архитектуре:

- Глубоко погружает в особенности распределенных систем
- Разбирает архитектуру микросервисов и связанные с ней компромиссы
- Охватывает serverless и облачные решения
- Помогает понять trade-offs при проектировании распределенных систем

Эти книги дополняют друг друга: Kleppmann даст глубокое понимание работы с данными, Bass и соавторы обеспечат фундаментальную базу, Ford научит делать архитектуру эволюционной, а Richards поможет разобраться с современными распределенными системами.

👉 Ключевые моменты из этих и других книг + примеры из продакшена реальных проектов + практические задачи на проектирование архитектуры высоконагруженных систем + фидбек от solution-архитектора Miro и EPAM Павла Вейника = курс [Технический Лидер].

Узнать о курсе подробнее и записаться на консультацию вы можете здесь. В феврале стартуем следующий поток, не пропустите!