Запускаю мини-группы для завершения уровней

Перед переходом на потоковую модель нужно корректно закрыть старый формат.

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

Обучение — это не кружок программирования.
Цель — научиться мыслить инженерно и реализовывать это в коде.

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

Расписание:

Уровень Стажёр — 14:30
Уровень Джуниор — 15:00
Уровень Мидл + DevOps — 15:30

Если вы не завершили уровень и уже делаете задачи следующего — переходите в группу следующего уровня.
Перепрыгивать уровень без завершения нельзя.

Формат работы:

— еженедельный созвон
— фиксация текущих задач
— контроль прогресса
— движение к завершению уровня

Мини-группы будут работать до 1 июня 2026 года.
После этой даты старый формат полностью закрывается.

Если хотите участвовать — напишите мне в личные сообщения: @parsentev
Укажите свой уровень и какую задачу сейчас делаете.

В эту субботу проведём первый созвон.

Сегодня провёл первые синки с мини-группами по всем уровням.

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

Ещё раз проговорили важную вещь:
цель — не просто “закрыть задачи”, а выстроить инженерное мышление.
Теория не ради теории. Практика не ради галочки.

Зачем нужны созвоны?

Не для контроля.
Не для отчётов.
А для ритма.

Когда есть регулярная точка фиксации прогресса — процесс перестаёт растягиваться на годы.

По поводу записей.

Это не лекции и не вебинары.
Это рабочие синки. Формат построен на участии и личной ответственности.

Записей не будет.

Если вам нужен только материал — он доступен.
Если нужен результат — нужен ритм.

Следующий синк — через неделю.

Performance Review — зеркало требований компании

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

Интересное наблюдение.

В сложных продуктовых компаниях с высокой ценой ошибки на review почти не обсуждают количество задач или знание инструментов.

Смотрят на другое:

— снижает ли инженер риски
— понимает ли доменную модель
— усиливает ли устойчивость сервиса
— влияет ли на предсказуемость системы

Это хорошо показывает, какие разработчики востребованы в сложных контурах.

Мой курс много лет учил инженерной грамотности — и это важно.
Но в таких компаниях этого уже недостаточно.

Именно поэтому я пересобираю формат обучения.

Почему большинство разработчиков остаются middle

Можно знать фреймворки.
Можно разбираться в многопоточности.
Можно писать чистый код.

И всё равно оставаться middle.

Потому что переход на следующий уровень — это не про глубину технологии.
Это про смену масштаба мышления.

Возьмём простую задачу: добавить поле в API.

Middle думает:
- как правильно реализовать
- как сделать миграцию
- как написать тесты

Senior задаёт другие вопросы:
- зачем это поле появилось?
- кто его будет использовать?
- меняется ли контракт?
- ломаем ли интеграции?
- влияет ли это на отчёты или расчёты?
- что будет при null или некорректном значении?
- как это изменение вписывается в общий процесс?

Middle отвечает за реализацию.
Senior отвечает за последствия.

И нет, senior — это не человек-оркестр.

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

Но он понимает, в какой системе работает.
Понимает ограничения.
Понимает договорённости.
Понимает риски.

Он расширяет не роль.
Он расширяет ответственность.

Пока ты мыслишь границами тикета — ты middle.

Переход начинается тогда, когда ты начинаешь видеть цепочку:

пользователь → API → данные → интеграции → SLA → операционный процесс.

Если твой код ломает цепочку — это уже не “просто поле”.

Именно здесь начинается рост к senior.
А дальше — к архитектуре.

Поэтому и появился трек «Процессинговое мышление».

В базовом курсе мы разбираем инструменты и практики.
В этом треке смотрим на те же задачи иначе —
не как на набор техник,
а как на элементы системы.

Рост происходит не тогда, когда ты знаешь ещё один фреймворк.
А тогда, когда начинаешь видеть систему целиком.

Завтра очередные созвоны с мини-потоками.

В этот раз встречи проведут наставники:

• 1 уровень и 3 уровень — Стас
• 2 уровень — Алексей

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

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

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

Миф: плохое собеседование — это слабый публичный след

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

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

Что останется такой след:
не дотянул, поплыл, не вывез.

Но в реальности собеседование — это не приговор, а практика в боевых условиях.

Никакое мок-интервью не даёт того, что даёт реальное:
стресс, давление, незнакомые вопросы, необходимость быстро собраться и держать мысль.

Именно поэтому на собеседования стоит ходить, даже когда ты не в поиске.

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

Почему в одних компаниях люди растут, а в других — стагнируют

Я сейчас работаю в крупном маркетплейсе и увидел интересную вещь.

Здесь очень системно растят инженеров.

1. Экспертиза распределяется.
Руководитель специально следит, чтобы знания не были у одного человека.
Если только один знает систему — это риск.

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

И это очень сильно прокачивает инженера.
Потому что ты начинаешь понимать систему целиком, а не только свой кусок кода.

На самом деле именно такие вещи и делают из разработчика senior, а не просто человека, который пишет задачи.

Наблюдение из BigTech

Иногда читаю интервью разработчиков, где делают выводы о компании по опыту одной команды.
Но в больших компаниях это почти всегда ошибка.
Там десятки и сотни команд, и инженерная культура может сильно отличаться.
Я это хорошо увидел на простом примере — код-ревью.
В основной команде, где я сейчас работаю, экспертиза распределяется между разработчиками.
Соответственно распределяется и ответственность.
Это видно по ревью:
в нём участвуют все разработчики команды, а не только тимлид.
Когда ты ставишь approve, ты берёшь на себя ответственность за изменения в системе.
И это даёт важный эффект:
разработчики смотрят код друг друга
быстрее понимают кодовую базу
начинают видеть соседние сервисы
постепенно берут больше ответственности
Но я видел и другую модель.
Когда код-ревью фактически делает только руководитель, а остальные ждут его решения.
Тогда экспертиза концентрируется в одном человеке, а команда превращается в исполнителей задач.
И здесь хорошо видно разницу мышления двух тимлидов.
Один понимает, что команда — это способ усилить себя, выращивая экспертизу каждого разработчика.
Другой берёт всё на себя и занимается микроменеджментом задач.
Сейчас я как раз работаю над материалом курса по процессному мышлению, и там есть важная мысль.
Ты не можешь стать senior, если не понимаешь:
как работает твоя команда
как распределяется ответственность
как вы взаимодействуете между собой и с другими командами.
Потому что инженерия — это не только код.
Это ещё и система людей, которые этот код создают.

Встреча в мини-группах

Напоминаю, что сегодня общая встреча в мини-группах.
Ссылки на эфир в чатах мини-групп.

1 уровень в 14:30. Проведет Стас.
2 уровень в 15:00. Проведет Алексей.
3 уровень в 15:30. Проведет Петр.

Так же сейчас уже идет набор в поток "процессинговое мышление".
С ними сбиваемся в 14:00.

Всем спасибо и хороших выходных.

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

Этой зимой я записался на новогодний йога-ретрит на 9 дней.
Была утренняя и вечерняя практика. И я заметил важную вещь: главный результат давали не записи и не сами упражнения. Главный результат давал ритм группы.

Я вставал утром в 7 утра, выходил на коврик, находил время днём не потому, что вдруг стал сверхдисциплинированным, а потому что вошёл в общий темп. Когда занимаешься один, всегда можно договориться с собой: сегодня пропущу, завтра наверстаю.

С обучением разработке то же самое.

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

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

Рост взрослого человека — это не только контент.
Это ритм, нагрузка, практика и среда.

Поэтому многие разработчики годами не растут не потому, что у них нет хороших материалов, а потому что материал сам по себе не ведёт вперёд.

Если хотите расти, не собирайте бесконечно материалы.
Соберите себе систему: небольшой фокус, понятный темп и регулярную практику.

Кросс-командные фичи: где заканчивается кодинг и начинается senior

Когда задача живёт внутри одной команды, всё кажется понятным: получил ТЗ, нашёл место в коде, реализовал, отдал на ревью.

Но как только фича становится кросс-командной, правила меняются.

Теперь уже недостаточно просто хорошо писать код.
Нужно понять:

чей это домен;

где должна жить логика;

какие команды затрагиваются;

какие контракты можно менять, а какие нет;

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

И вот здесь начинается настоящий senior.

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

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

То есть ошибка была не в реализации.
Ошибка была в том, что я слишком рано перешёл к реализации.

В кросс-командных фичах senior отличается не скоростью кодинга.
Senior отличается тем, что до кода делает другую работу:

собирает контекст;

согласует границы;

фиксирует ownership;

проверяет контракты;

и только потом открывает IDE.

Поэтому хороший маркер простой:

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

Перед вами маленький системный дизайн.

И в таких задачах главный навык senior —
не быстрее писать код, а не начинать писать его слишком рано.

Как теперь будет устроено обучение в Job4j

За последнее время я всё яснее вижу одну проблему:
в обучении часто не хватает ритма.

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

В разработке ведь не бывает режима «иду как получится».

Есть план. Есть сроки. Есть этапы. Есть ответственность за результат.
И обучение должно быть устроено так же.

Поэтому я меняю подход. Теперь обучение будет строиться через потоки с чётким ритмом и уровнем входа.

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

Как теперь устроено обучение

В году будет несколько потоков.
Каждый поток — под свой уровень и свою задачу.
Каждый поток проходит 1 раз в год.

1. Весна — Основы серверной разработки

Это первый системный этап для тех, кто хочет войти в backend-разработку.

Что внутри:
- инструменты разработки;
- основы ООП;
- тесты;
- базовые элементы CI/CD;
- дисциплина работы с кодом.

Здесь важное изменение: теперь есть фильтр на входе.

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

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

2. Осень — Выход в IT

Это поток для тех, кто уже знает основы программирования и хочет перейти к реальной backend-разработке.
Здесь мы идём уже в прикладную сторону:
- API;
- базы данных;
- инфраструктура;
- работа с продакшеном;
- backend как реальная инженерная система, а не набор учебных задач.
Цель потока — научиться писать сервисы так, как это требуется в работе.

** 3. Лето — Процессинговое мышление

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

Здесь уже мало просто «уметь писать код».
Нужно уметь видеть процесс целиком.

Это переход от позиции: «я пишу код» к позиции:

«я строю предсказуемую систему»
Что внутри:
- архитектура;
- процессы;
- границы ответственности;
- системный дизайн;
- проектирование решений через реальный проект и реальные технологии.

Это поток для тех, кто хочет расти в сторону senior-уровня не по названию, а по мышлению.

** 4. Зима — Bootcamp Interview 400+

Интенсивная программа подготовки backend-разработчиков к интервью уровня middle+ / senior и компаниям уровня BigTech.

Формат: 5 недель плотной системной подготовки.

Что разбираем:
- алгоритмы;
- базы данных;
- архитектуру отказоустойчивых систем;
- системный дизайн;
- team fit;
- поведение на интервью.

Это не просто набор вопросов.
Это сборка разработчика под собеседование как под отдельный проект.

Что ещё будет отдельно

Помимо потоков, останутся материалы для самостоятельной подготовки:
1. Основы программирования
2. Основы веб-разработки
Это база, которую можно пройти самостоятельно, чтобы потом зайти в поток уже подготовленным.

Сильная команда — это среда усиления

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

Сначала мне казалось, что ко мне придираются. В код-ревью было много замечаний, обсуждение домена уходило глубже, чем я ожидал, а на некоторые вещи команда тратила слишком много внимания. Почему сценарий проходит именно так? Где границы процесса? Какие здесь инварианты? Что будет в исключениях? Не ломаем ли мы соседний участок системы? На старте всё это воспринимается как лишнее давление. Кажется, что задача понятна, код работает, тесты зелёные — значит, всё нормально.

Со временем я увидел, что это были не придирки, а планка. Сильная команда не даёт тебе остаться на том уровне мышления, с которым ты в неё пришёл. Она заставляет смотреть шире: не только на код, но и на домен; не только на локальную задачу, но и на процесс целиком; не только на реализацию, но и на то, правильно ли вообще понята сама задача.

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

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

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

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

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

Сильная команда работает иначе. Она быстрее проявляет твой реальный уровень: в ревью, в обсуждении домена, в дежурстве, в ответственности за решение. Там сложнее спрятаться за формулой «код же работает», потому что вопрос всегда шире: ту ли задачу ты вообще решил, не сломал ли инварианты, не упростил ли процесс до потери смысла, не переложил ли проблему на соседний сервис.

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

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

Поэтому сильная команда ценна не только тем, что делает хороший продукт. Её настоящая сила в другом: она меняет качество мышления своих участников.

Слабая команда нормализует посредственность. Сильная команда нормализует рост.

И если ты действительно хочешь расти, стоит смотреть не только на задачи, стек и деньги. Стоит задать себе ещё один вопрос: моя команда делает меня сильнее — или просто даёт мне комфортно оставаться на текущем уровне?

Микросервисы — это не про Go. Это про процесс

Сегодня общался с учеником по курсу. У него есть сомнение: сможет ли он осилить Go после Java.

И я понимаю, откуда это идет. У Go есть устойчивый образ языка для инфраструктуры и почти системного программирования. Из-за этого разработчику, который до этого писал enterprise-приложения на Java, начинает казаться, что вместе с Go ему придется резко уйти в какой-то другой мир: меньше бизнеса, больше низкого уровня.

Но в продуктовой разработке вопрос обычно не в этом.

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

Язык здесь — только инструмент.

И вот Go в этой роли мне нравится не потому, что он быстрый и не потому, что на нем написаны инфраструктурные сервисы вроде Prometheus. Это правда, такие проекты на Go есть. Но в контексте бизнес-приложений его сила в другом. Он позволяет описывать процесс прямо, без лишнего шума.

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

func (s *Domain) PublishTrip(
    ctx context.Context,
    tripID int64,
    clientID int64,
) (*Trip, error) {
    trip, err := s.repo.GetTripForUpdate(ctx, tripID)
    if err != nil {
        return nil, err
    }
    if trip.DriverID != clientID {
        return nil, ErrForbidden
    }
    if trip.Status == Published {
        return trip, nil
    }
    if trip.Status != Draft {
        return nil, ErrInvalidTransition
    }

    return s.repo.UpdateTripToPublished(ctx, tripID)
}

Вот это и есть обычная прикладная логика микросервиса.

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

Это можно сделать на любом языке. Но Go здесь удобен тем, что у него очень ограниченный синтаксис и нет магии. Поэтому внимание остается на самом важном — на поведении системы. Не на сложной иерархии абстракций, не на фреймворке, не на “красоте конструкции”, а на самом процессе.

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

1 апреля

Пришлось сделать резерв сообщества в максе.

Общий чат https://max.ru/join/536L4xlhzoubVchlrMpSB504E9O5i35rs2KhfPj4EWk

Канал https://max.ru/join/nJbgkY6r_dZI_3eiSAQ-b1r9Qz3bbHaNS29FNatBwgA

Mock interview — это не подготовка. Это проверка готовности

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

Далее https://job4j.ru/article/view/15

Прошел почти месяц мини-групп — и уже видно результат

1 марта я запустил мини-группы для тех, кто хочет корректно завершить обучение в старой программе. Задача была простая: помочь людям не зависнуть в состоянии «когда-нибудь доделаю», а спокойно и последовательно дойти до конца.

Прошел почти месяц, и результат уже заметен.

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

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

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

И для меня это важный вывод: формат с ритмом и групповой динамикой работает.

Definition of Done

Сейчас я активно работаю над курсом про процессное мышление. В одном из уроков я рассказываю про термин Definition of Done. DoD — это зафиксированное состояние завершения задачи. Проще говоря, это ответ на вопрос: что именно заказчик или команда хотят увидеть в результате.

И в какой-то момент я поймал себя на другой мысли: а куда именно я веду учеников этим курсом?

Далее https://job4j.ru/article/view/16

4 апреля встреча в мини-группах

Напоминаю, что сегодня общая встреча в мини-группах.
Ссылки на эфир в чатах мини-групп.

BigTech + Go в 14:00. Проведет Петр
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.

Всем спасибо и хороших выходных.