Друзья, завтра встречаемся на новый 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

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

👉 Друзья, мы уже стартанули доклад про опыт использования AI в разработке, успевайте присоединиться к нам в Google meet

🎙 GenAI under Control: Evaluation & Guardrails. Part 2

Сегодня встречаемся в 20:00 GMT+3 на докладе H&S Conclave!

Продолжаем разбираться, как контролировать поведение LLM-моделей в боевых условиях. После теоретической базы — переходим к практике.
Во второй части доклада:
🔹 Что такое evals и как они помогают оценивать точность и релевантность промптов
🔹 Как использовать guardrails — для управления, фильтрации и ограничения поведения модели

📺 Если пропустили первую часть — запись доступна на YouTube!

👤 Спикер: Вадим Гацура, VP of Engineering @ Viio

👉 Зарегистрироваться на ивент и оставить свой вопрос можно по ссылке

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

Различие в адаптации между джунами и сеньорами, в сочетании с финансовыми последствиями использования ИИ-агентов, приводит к сценарию «мести». Компании, чтобы оставаться конкурентоспособными с помощью ИИ-агентов, должны резко увеличить расходы на LLM. Если им придется сокращать расходы для оплаты токенов, они, вероятно, будут сокращать более дорогих разработчиков, которые скептически настроены по поводу ИИ, в пользу более дешевых младших разработчиков, которые быстро адаптировались. Таким образом, джуны, быстрее освоившие ИИ и стоящие дешевле, получают стратегическое преимущество и могут отомстить и «выбросить неудачников-сеньоров с острова».

https://sourcegraph.com/blog/revenge-of-the-junior-developer

На вашем проекте все хорошо?

Проверьте это с чек-листом, охватывающим ключевые аспекты: качество кода, архитектуру, инфраструктуру и командные процессы.

🧩 1. Оценка качества кода
Начните с анализа метрик, отражающих сложность и поддерживаемость кода:

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

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

🏗 2. Анализ архитектуры
Проверьте архитектуру проекта на соответствие следующим критериям:

🔸Модульность: насколько компоненты системы изолированы и могут разрабатываться независимо.
🔸Масштабируемость: способность системы обрабатывать увеличивающуюся нагрузку.
🔸Надежность: устойчивость к сбоям и возможность быстрого восстановления.

☁️ 3. Проверка инфраструктуры
Оцените инфраструктуру проекта по следующим параметрам:

🔹Автоматизация развертывания: использование CI/CD для ускорения и надежности релизов.
🔹Мониторинг и логирование: наличие систем, отслеживающих состояние приложений и инфраструктуры.
🔹Безопасность: проверка на уязвимости и соответствие стандартам безопасности.

Инструменты, такие как Prometheus для мониторинга и KICS для анализа безопасности инфраструктурного кода, помогут в этой оценке. 

👥 4. Оценка командных процессов
Проанализируйте процессы внутри команды:

🔸Скорость разработки: время от идеи до релиза.
🔸Качество коммуникации: насколько эффективно команда обменивается информацией.
🔸Удовлетворенность команды: уровень мотивации и вовлеченности участников.

Используйте опросы и метрики, такие как время цикла задач в Jira, для получения объективных данных.

🎯 5. Приоритизация задач после проверки
После проведения health check составьте список выявленных проблем и оцените их по двум осям:

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

Используйте матрицу приоритетов, чтобы определить, какие задачи следует решать в первую очередь.

💼 6. Обоснование необходимости проверки для бизнеса
Чтобы убедить бизнес в важности проведения health check, акцентируйте внимание на следующих выгодах:

🔸Снижение рисков: раннее выявление проблем предотвращает дорогостоящие сбои в будущем.
🔸Повышение эффективности: оптимизация процессов ускоряет выпуск новых функций.
🔸Прозрачность: предоставление четкой картины состояния проекта способствует принятию обоснованных решений.

Представьте конкретные примеры и данные, демонстрирующие улучшения после предыдущих health check.

Точка невозврата: когда инженеру пора переключиться с написания кода на лидерство

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

🙅‍♂️Нужно ли полностью отказываться от кода?

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

🔄 Что делать вместо написания кода?

Роль техлида включает:

🔸Формирование технического видения – определение архитектурных решений и технологического стека.
🔸Менторство – поддержка и развитие членов команды.
🔸Коммуникация с бизнесом – перевод бизнес-требований в технические задачи.
🔸Управление процессами – оптимизация рабочих процессов и внедрение лучших практик.

🧠 Как переключить мышление?

1️⃣ Нужно смотреть на свою работу в контексте всей системы и своего влияния на бизнес, а не в конкретных задачах.
2️⃣ Обсуждать архитектуру и код не менее (а иногда и более) важно, чем его писать. Коммуникации – это тоже работа.
3️⃣ Дальнейший рост возможен только через расширение зоны ответственности. А чем шире зона ответственности, тем меньше возможности погрузиться в задачи глубоко – нужно делегировать.

📋 Как делегировать задачи без потери качества?

Четкое определение задач: ясное описание требований и ожиданий.

Доверие: предоставление команде автономии в принятии решений.

Обратная связь: регулярные обсуждения результатов и предложений по улучшению.

Готовы к такой трансформации? Записывайтесь на консультацию перед курсом [Технический Лидер]!

Друзья, завтра возобновляем после майских каникул наши ивенты и первый H&S Conclave пройдет на тему "Реактивное программирование и Spring WebFlux: преимущества, вызовы и интеграция с виртуальными потоками"

О чём доклад:
В этом докладе мы разберём, что такое реактивное программирование, какие проблемы оно помогает решать, и в каких случаях его стоит использовать. Обсудим ключевые концепции, такие как backpressure, Publisher/Observable, а также разницу между традиционными и реактивными веб-фреймворками.

Основные темы:

1. Основы реактивного программирования и зачем оно нужно
2. Как устроен Project Reactor
3. Что такое backpressure и как с ним работать
4. Разница между Spring WebFlux и Spring MVC
5. Что такое виртуальные потоки (Project Loom) и как они упрощают реактивные решения
6. Практическая демонстрация с WebFlux

🎯 Челлендж перед митапом!
Попробуйте реализовать небольшую задачу: посчитать количество double-click’ов за 5 секунд. Что угодно — консоль, UI, любой язык.
На митапе сравним подходы, обсудим, сколько времени ушло и насколько всё оказалось сложным без реактивщины.

📊 В конце — мини-опрос и обсуждение решений.
👉 Узнать подробнее и зарегестрироваться можно по ссылке