Почему многие разработчики годами не растут, даже имея хороший материал
Этой зимой я записался на новогодний йога-ретрит на 9 дней.
Была утренняя и вечерняя практика. И я заметил важную вещь: главный результат давали не записи и не сами упражнения. Главный результат давал ритм группы.
Я вставал утром в 7 утра, выходил на коврик, находил время днём не потому, что вдруг стал сверхдисциплинированным, а потому что вошёл в общий темп. Когда занимаешься один, всегда можно договориться с собой: сегодня пропущу, завтра наверстаю.
С обучением разработке то же самое.
Есть иллюзия, что если дать человеку хороший материал, домашки и доступ к урокам, то он вырастет сам. Но хороший программист — ещё не значит хороший преподаватель. Недостаточно просто переложить свой опыт в текст.
Нужно учитывать, как человек вообще учится: какой ритм выдерживает, где перегружается, в какой момент выпадает, как на него влияет группа и внешняя рамка.
Рост взрослого человека — это не только контент.
Это ритм, нагрузка, практика и среда.
Поэтому многие разработчики годами не растут не потому, что у них нет хороших материалов, а потому что материал сам по себе не ведёт вперёд.
Если хотите расти, не собирайте бесконечно материалы.
Соберите себе систему: небольшой фокус, понятный темп и регулярную практику.
Этой зимой я записался на новогодний йога-ретрит на 9 дней.
Была утренняя и вечерняя практика. И я заметил важную вещь: главный результат давали не записи и не сами упражнения. Главный результат давал ритм группы.
Я вставал утром в 7 утра, выходил на коврик, находил время днём не потому, что вдруг стал сверхдисциплинированным, а потому что вошёл в общий темп. Когда занимаешься один, всегда можно договориться с собой: сегодня пропущу, завтра наверстаю.
С обучением разработке то же самое.
Есть иллюзия, что если дать человеку хороший материал, домашки и доступ к урокам, то он вырастет сам. Но хороший программист — ещё не значит хороший преподаватель. Недостаточно просто переложить свой опыт в текст.
Нужно учитывать, как человек вообще учится: какой ритм выдерживает, где перегружается, в какой момент выпадает, как на него влияет группа и внешняя рамка.
Рост взрослого человека — это не только контент.
Это ритм, нагрузка, практика и среда.
Поэтому многие разработчики годами не растут не потому, что у них нет хороших материалов, а потому что материал сам по себе не ведёт вперёд.
Если хотите расти, не собирайте бесконечно материалы.
Соберите себе систему: небольшой фокус, понятный темп и регулярную практику.
👍15🔥2👀2
Кросс-командные фичи: где заканчивается кодинг и начинается senior
Когда задача живёт внутри одной команды, всё кажется понятным: получил ТЗ, нашёл место в коде, реализовал, отдал на ревью.
Но как только фича становится кросс-командной, правила меняются.
Теперь уже недостаточно просто хорошо писать код.
Нужно понять:
чей это домен;
где должна жить логика;
какие команды затрагиваются;
какие контракты можно менять, а какие нет;
не ломаешь ли ты абстракцию чужого сервиса.
И вот здесь начинается настоящий senior.
Я недавно как раз попал в такую ситуацию.
Задача выглядела технической: добавить новые ручки.
Я нашёл сервис, куда это вроде бы логично встроить, согласовал направление на словах и пошёл писать код.
А потом оказалось, что проблема вообще не в коде.
Проблема в том, что ручки были специфичны для одного продукта, а сервис, в который я их добавлял, должен был оставаться абстрактным для всех.
То есть ошибка была не в реализации.
Ошибка была в том, что я слишком рано перешёл к реализации.
В кросс-командных фичах senior отличается не скоростью кодинга.
Senior отличается тем, что до кода делает другую работу:
собирает контекст;
согласует границы;
фиксирует ownership;
проверяет контракты;
и только потом открывает IDE.
Поэтому хороший маркер простой:
Если в задаче участвуют несколько команд,
если есть спор, куда класть логику,
если затрагиваются чужие сервисы и абстракции,
— значит перед вами уже не просто задача на код.
Перед вами маленький системный дизайн.
И в таких задачах главный навык senior —
не быстрее писать код, а не начинать писать его слишком рано.
Когда задача живёт внутри одной команды, всё кажется понятным: получил ТЗ, нашёл место в коде, реализовал, отдал на ревью.
Но как только фича становится кросс-командной, правила меняются.
Теперь уже недостаточно просто хорошо писать код.
Нужно понять:
чей это домен;
где должна жить логика;
какие команды затрагиваются;
какие контракты можно менять, а какие нет;
не ломаешь ли ты абстракцию чужого сервиса.
И вот здесь начинается настоящий senior.
Я недавно как раз попал в такую ситуацию.
Задача выглядела технической: добавить новые ручки.
Я нашёл сервис, куда это вроде бы логично встроить, согласовал направление на словах и пошёл писать код.
А потом оказалось, что проблема вообще не в коде.
Проблема в том, что ручки были специфичны для одного продукта, а сервис, в который я их добавлял, должен был оставаться абстрактным для всех.
То есть ошибка была не в реализации.
Ошибка была в том, что я слишком рано перешёл к реализации.
В кросс-командных фичах senior отличается не скоростью кодинга.
Senior отличается тем, что до кода делает другую работу:
собирает контекст;
согласует границы;
фиксирует ownership;
проверяет контракты;
и только потом открывает IDE.
Поэтому хороший маркер простой:
Если в задаче участвуют несколько команд,
если есть спор, куда класть логику,
если затрагиваются чужие сервисы и абстракции,
— значит перед вами уже не просто задача на код.
Перед вами маленький системный дизайн.
И в таких задачах главный навык senior —
не быстрее писать код, а не начинать писать его слишком рано.
👍12👎1
Как теперь будет устроено обучение в 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. Основы веб-разработки
Это база, которую можно пройти самостоятельно, чтобы потом зайти в поток уже подготовленным.
За последнее время я всё яснее вижу одну проблему:
в обучении часто не хватает ритма.
А без ритма нет рамки. Нет ощущения движения.
Нет понимания, где ты находишься в процессе и что от тебя требуется сейчас.
В разработке ведь не бывает режима «иду как получится».
Есть план. Есть сроки. Есть этапы. Есть ответственность за результат.
И обучение должно быть устроено так же.
Поэтому я меняю подход. Теперь обучение будет строиться через потоки с чётким ритмом и уровнем входа.
Не бесконечный доступ без структуры, где можно всё время «начать завтра»,
а понятный маршрут:
когда старт, какой темп, какие требования на входе и какой результат на выходе.
Как теперь устроено обучение
В году будет несколько потоков.
Каждый поток — под свой уровень и свою задачу.
Каждый поток проходит 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. Основы веб-разработки
Это база, которую можно пройти самостоятельно, чтобы потом зайти в поток уже подготовленным.
🔥11
Сильная команда — это среда усиления
Когда я пришёл в финтех, первое время мне было тяжело. Не потому, что задачи были запредельно сложными, а потому, что команда оказалась сильной. Понял я это не сразу.
Сначала мне казалось, что ко мне придираются. В код-ревью было много замечаний, обсуждение домена уходило глубже, чем я ожидал, а на некоторые вещи команда тратила слишком много внимания. Почему сценарий проходит именно так? Где границы процесса? Какие здесь инварианты? Что будет в исключениях? Не ломаем ли мы соседний участок системы? На старте всё это воспринимается как лишнее давление. Кажется, что задача понятна, код работает, тесты зелёные — значит, всё нормально.
Со временем я увидел, что это были не придирки, а планка. Сильная команда не даёт тебе остаться на том уровне мышления, с которым ты в неё пришёл. Она заставляет смотреть шире: не только на код, но и на домен; не только на локальную задачу, но и на процесс целиком; не только на реализацию, но и на то, правильно ли вообще понята сама задача.
Позже меня подключали к соседним командам, чтобы помочь реализовать часть процессов в других сервисах. И вот там контраст стал особенно заметен. Разница была не в интеллекте отдельных людей, а в среде.
В одной команде нормой было сначала обсуждать домен: какой процесс мы реализуем, где границы ответственности, какие ограничения и побочные эффекты нужно учесть. В другой разговор почти сразу уходил в техническую реализацию: какие поля добавить, какой метод вызвать, как быстрее провести интеграцию. В одной команде ревью помогало увидеть слабые места решения, в другой часто сводилось к косметике: нейминг, форматирование, локальные замечания без разговора о смысле. Даже отношение к дежурству отличалось. Где-то это была часть инженерной ответственности, а где-то — неприятная обязанность, которую нужно просто пережить.
Именно тогда я особенно чётко увидел простую мысль: сильная команда — это не просто набор компетентных людей. Это среда, которая усиливает каждого, кто в неё попадает.
Она усиливает через норму. Через планку качества. Через ритм. Через культуру обсуждения. Через внимание к домену. Через привычку сначала проверять правильность решения на уровне смысла, а уже потом смотреть на код.
Главное здесь вот что: сильная команда делает видимыми слабые места, которые в одиночку можно долго не замечать. В слабой среде человек может годами жить с ощущением, что развивается. Он закрывает задачи, пишет код, участвует в обсуждениях, и внешне всё выглядит нормально. Но если среда не требует глубины, мышление постепенно упрощается.
Сильная команда работает иначе. Она быстрее проявляет твой реальный уровень: в ревью, в обсуждении домена, в дежурстве, в ответственности за решение. Там сложнее спрятаться за формулой «код же работает», потому что вопрос всегда шире: ту ли задачу ты вообще решил, не сломал ли инварианты, не упростил ли процесс до потери смысла, не переложил ли проблему на соседний сервис.
Именно поэтому такая среда ускоряет развитие. Она не даёт долго жить в комфортной иллюзии роста. Она показывает, где ты мыслишь поверхностно, где путаешь реализацию и смысл, где защищаешь код вместо того, чтобы перепроверить модель.
Мы часто выбираем работу по стеку, зарплате, бренду компании или названию роли. Всё это важно. Но есть фактор, который влияет на рост не меньше: среда, в которой ты работаешь. Если рядом команда, которая держит высокую планку, умеет обсуждать домен, серьёзно относится к ревью и к ответственности за общее решение, даже сложный период в такой среде даёт очень много. Если же среда не требует глубины, можно долго оставаться на одном уровне и не замечать этого.
Поэтому сильная команда ценна не только тем, что делает хороший продукт. Её настоящая сила в другом: она меняет качество мышления своих участников.
Слабая команда нормализует посредственность. Сильная команда нормализует рост.
Когда я пришёл в финтех, первое время мне было тяжело. Не потому, что задачи были запредельно сложными, а потому, что команда оказалась сильной. Понял я это не сразу.
Сначала мне казалось, что ко мне придираются. В код-ревью было много замечаний, обсуждение домена уходило глубже, чем я ожидал, а на некоторые вещи команда тратила слишком много внимания. Почему сценарий проходит именно так? Где границы процесса? Какие здесь инварианты? Что будет в исключениях? Не ломаем ли мы соседний участок системы? На старте всё это воспринимается как лишнее давление. Кажется, что задача понятна, код работает, тесты зелёные — значит, всё нормально.
Со временем я увидел, что это были не придирки, а планка. Сильная команда не даёт тебе остаться на том уровне мышления, с которым ты в неё пришёл. Она заставляет смотреть шире: не только на код, но и на домен; не только на локальную задачу, но и на процесс целиком; не только на реализацию, но и на то, правильно ли вообще понята сама задача.
Позже меня подключали к соседним командам, чтобы помочь реализовать часть процессов в других сервисах. И вот там контраст стал особенно заметен. Разница была не в интеллекте отдельных людей, а в среде.
В одной команде нормой было сначала обсуждать домен: какой процесс мы реализуем, где границы ответственности, какие ограничения и побочные эффекты нужно учесть. В другой разговор почти сразу уходил в техническую реализацию: какие поля добавить, какой метод вызвать, как быстрее провести интеграцию. В одной команде ревью помогало увидеть слабые места решения, в другой часто сводилось к косметике: нейминг, форматирование, локальные замечания без разговора о смысле. Даже отношение к дежурству отличалось. Где-то это была часть инженерной ответственности, а где-то — неприятная обязанность, которую нужно просто пережить.
Именно тогда я особенно чётко увидел простую мысль: сильная команда — это не просто набор компетентных людей. Это среда, которая усиливает каждого, кто в неё попадает.
Она усиливает через норму. Через планку качества. Через ритм. Через культуру обсуждения. Через внимание к домену. Через привычку сначала проверять правильность решения на уровне смысла, а уже потом смотреть на код.
Главное здесь вот что: сильная команда делает видимыми слабые места, которые в одиночку можно долго не замечать. В слабой среде человек может годами жить с ощущением, что развивается. Он закрывает задачи, пишет код, участвует в обсуждениях, и внешне всё выглядит нормально. Но если среда не требует глубины, мышление постепенно упрощается.
Сильная команда работает иначе. Она быстрее проявляет твой реальный уровень: в ревью, в обсуждении домена, в дежурстве, в ответственности за решение. Там сложнее спрятаться за формулой «код же работает», потому что вопрос всегда шире: ту ли задачу ты вообще решил, не сломал ли инварианты, не упростил ли процесс до потери смысла, не переложил ли проблему на соседний сервис.
Именно поэтому такая среда ускоряет развитие. Она не даёт долго жить в комфортной иллюзии роста. Она показывает, где ты мыслишь поверхностно, где путаешь реализацию и смысл, где защищаешь код вместо того, чтобы перепроверить модель.
Мы часто выбираем работу по стеку, зарплате, бренду компании или названию роли. Всё это важно. Но есть фактор, который влияет на рост не меньше: среда, в которой ты работаешь. Если рядом команда, которая держит высокую планку, умеет обсуждать домен, серьёзно относится к ревью и к ответственности за общее решение, даже сложный период в такой среде даёт очень много. Если же среда не требует глубины, можно долго оставаться на одном уровне и не замечать этого.
Поэтому сильная команда ценна не только тем, что делает хороший продукт. Её настоящая сила в другом: она меняет качество мышления своих участников.
Слабая команда нормализует посредственность. Сильная команда нормализует рост.
👍8🔥5❤3💯1
И если ты действительно хочешь расти, стоит смотреть не только на задачи, стек и деньги. Стоит задать себе ещё один вопрос: моя команда делает меня сильнее — или просто даёт мне комфортно оставаться на текущем уровне?
👍9
Микросервисы — это не про Go. Это про процесс
Сегодня общался с учеником по курсу. У него есть сомнение: сможет ли он осилить Go после Java.
И я понимаю, откуда это идет. У Go есть устойчивый образ языка для инфраструктуры и почти системного программирования. Из-за этого разработчику, который до этого писал enterprise-приложения на Java, начинает казаться, что вместе с Go ему придется резко уйти в какой-то другой мир: меньше бизнеса, больше низкого уровня.
Но в продуктовой разработке вопрос обычно не в этом.
Микросервисы и продуктовые команды — это в первую очередь не про язык. Это про процессы. Про то, как в системе двигается заявка, поездка, платеж, скоринг или заказ. Про то, какие у процесса есть состояния, какие переходы допустимы, где нужна идемпотентность, где нужны блокировки, а где транзакция.
Язык здесь — только инструмент.
И вот Go в этой роли мне нравится не потому, что он быстрый и не потому, что на нем написаны инфраструктурные сервисы вроде Prometheus. Это правда, такие проекты на Go есть. Но в контексте бизнес-приложений его сила в другом. Он позволяет описывать процесс прямо, без лишнего шума.
Например, у нас есть команда PublishTrip. Нам нужно обеспечить, чтобы поездка перешла в Published. Для этого мы открываем транзакцию, читаем текущее состояние с блокировкой, проверяем, допустим ли переход, и либо возвращаем текущее состояние, либо обновляем его.
Вот это и есть обычная прикладная логика микросервиса.
Мы не пишем драйвер, не работаем с памятью вручную, не решаем низкоуровневую задачу. Мы описываем бизнес-переход. Берем состояние, проверяем правило, выполняем изменение, возвращаем результат.
Это можно сделать на любом языке. Но Go здесь удобен тем, что у него очень ограниченный синтаксис и нет магии. Поэтому внимание остается на самом важном — на поведении системы. Не на сложной иерархии абстракций, не на фреймворке, не на “красоте конструкции”, а на самом процессе.
Именно поэтому я смотрю на Go в микросервисах не как на язык для инфраструктуры, а как на удобный инструмент для продуктовой разработки. Если команда мыслит состояниями, переходами и инвариантами, 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 ложится туда очень естественно.
👍9
1 апреля
Пришлось сделать резерв сообщества в максе.
Общий чат https://max.ru/join/536L4xlhzoubVchlrMpSB504E9O5i35rs2KhfPj4EWk
Канал https://max.ru/join/nJbgkY6r_dZI_3eiSAQ-b1r9Qz3bbHaNS29FNatBwgA
Пришлось сделать резерв сообщества в максе.
Общий чат https://max.ru/join/536L4xlhzoubVchlrMpSB504E9O5i35rs2KhfPj4EWk
Канал https://max.ru/join/nJbgkY6r_dZI_3eiSAQ-b1r9Qz3bbHaNS29FNatBwgA
MAX
MAX – быстрое и легкое приложение для общения и решения пов…
MAX позволяет отправлять любые виды сообщений и звонить даже на слабых устройствах и при низкой скорости интернета.
😢5👍2👎1
Mock interview — это не подготовка. Это проверка готовности
Недавно ко мне обратился человек, который сейчас возвращается на рынок после паузы. Запрос у него на первый взгляд был вполне стандартный: понять, что сейчас востребовано, как скорректировать roadmap и провести mock interview. Но как раз в таких разговорах и видно, где у рынка искажено само понимание подготовки к собеседованиям.
Далее https://job4j.ru/article/view/15
Недавно ко мне обратился человек, который сейчас возвращается на рынок после паузы. Запрос у него на первый взгляд был вполне стандартный: понять, что сейчас востребовано, как скорректировать roadmap и провести mock interview. Но как раз в таких разговорах и видно, где у рынка искажено само понимание подготовки к собеседованиям.
Далее https://job4j.ru/article/view/15
👍4❤3🔥2
Прошел почти месяц мини-групп — и уже видно результат
1 марта я запустил мини-группы для тех, кто хочет корректно завершить обучение в старой программе. Задача была простая: помочь людям не зависнуть в состоянии «когда-нибудь доделаю», а спокойно и последовательно дойти до конца.
Прошел почти месяц, и результат уже заметен.
Ребята, которым действительно важно завершить обучение, включились в работу. Появился ритм, регулярность, движение вперед. Задачи перестали лежать мертвым грузом, а обучение снова стало живым процессом.
Для меня это еще одно подтверждение простой мысли: когда есть рамка, темп и небольшая группа, людям проще держать фокус и не выпадать из процесса.
Отдельно хочу похвалить тех, кто сейчас идет в этих мини-группах. Видно, что вы пришли не просто формально закрыть этап, а реально хотите завершить его достойно. Это чувствуется по вашей работе.
И для меня это важный вывод: формат с ритмом и групповой динамикой работает.
1 марта я запустил мини-группы для тех, кто хочет корректно завершить обучение в старой программе. Задача была простая: помочь людям не зависнуть в состоянии «когда-нибудь доделаю», а спокойно и последовательно дойти до конца.
Прошел почти месяц, и результат уже заметен.
Ребята, которым действительно важно завершить обучение, включились в работу. Появился ритм, регулярность, движение вперед. Задачи перестали лежать мертвым грузом, а обучение снова стало живым процессом.
Для меня это еще одно подтверждение простой мысли: когда есть рамка, темп и небольшая группа, людям проще держать фокус и не выпадать из процесса.
Отдельно хочу похвалить тех, кто сейчас идет в этих мини-группах. Видно, что вы пришли не просто формально закрыть этап, а реально хотите завершить его достойно. Это чувствуется по вашей работе.
И для меня это важный вывод: формат с ритмом и групповой динамикой работает.
🔥14👍8❤5🕊1
Definition of Done
Сейчас я активно работаю над курсом про процессное мышление. В одном из уроков я рассказываю про термин Definition of Done. DoD — это зафиксированное состояние завершения задачи. Проще говоря, это ответ на вопрос: что именно заказчик или команда хотят увидеть в результате.
И в какой-то момент я поймал себя на другой мысли: а куда именно я веду учеников этим курсом?
Далее https://job4j.ru/article/view/16
Сейчас я активно работаю над курсом про процессное мышление. В одном из уроков я рассказываю про термин Definition of Done. DoD — это зафиксированное состояние завершения задачи. Проще говоря, это ответ на вопрос: что именно заказчик или команда хотят увидеть в результате.
И в какой-то момент я поймал себя на другой мысли: а куда именно я веду учеников этим курсом?
Далее https://job4j.ru/article/view/16
❤🔥3👍3💯2
4 апреля встреча в мини-группах
Напоминаю, что сегодня общая встреча в мини-группах.
Ссылки на эфир в чатах мини-групп.
BigTech + Go в 14:00. Проведет Петр
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
Всем спасибо и хороших выходных.
Напоминаю, что сегодня общая встреча в мини-группах.
Ссылки на эфир в чатах мини-групп.
BigTech + Go в 14:00. Проведет Петр
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
Всем спасибо и хороших выходных.
Меняем мышление от монолита к микросервисам
В прошедшую субботу я проводил встречу в мини-группах, где рассказывал ребятам, какие структурные ошибки допустил в блоке по микросервисам.
Сейчас на работе мне дали большую задачу: перевести сервисы из одного контура Kubernetes в другой. Эта задача дает мне возможность глубже понять архитектурные решения, принятые в команде. В этой статье я расскажу, что именно упустил, и дам ссылки на темы, в которых стоит разобраться.
Далее https://job4j.ru/article/view/17
В прошедшую субботу я проводил встречу в мини-группах, где рассказывал ребятам, какие структурные ошибки допустил в блоке по микросервисам.
Сейчас на работе мне дали большую задачу: перевести сервисы из одного контура Kubernetes в другой. Эта задача дает мне возможность глубже понять архитектурные решения, принятые в команде. В этой статье я расскажу, что именно упустил, и дам ссылки на темы, в которых стоит разобраться.
Далее https://job4j.ru/article/view/17
👍4👀4
Метрики и трасы
В этой статье я продолжу описывать то, что упустил в материалах курса.
Во-первых, хочу объяснить, как я нахожу эти недочеты. Сейчас 80% информации я черпаю из текущей работы. Когда у тебя много команд, много сервисов, много ответственности и рисков, в приоритете становятся правила и политики компании. Я смотрю, как ребята решают инциденты, как общаются и выясняют причины проблем, как выстроены мониторинг и профилактика, как проводят code review и доменное review. Я сравниваю это со своим курсом по процессному мышлению и отражаю нужные изменения в материале. Но в то же время мне хочется делиться некоторыми инсайтами и с теми, кто уже проходил у меня обучение, чтобы они тоже двигались дальше по своему пути.
Как говорится, у самурая нет цели — есть только путь.
Далее https://job4j.ru/article/view/18
В этой статье я продолжу описывать то, что упустил в материалах курса.
Во-первых, хочу объяснить, как я нахожу эти недочеты. Сейчас 80% информации я черпаю из текущей работы. Когда у тебя много команд, много сервисов, много ответственности и рисков, в приоритете становятся правила и политики компании. Я смотрю, как ребята решают инциденты, как общаются и выясняют причины проблем, как выстроены мониторинг и профилактика, как проводят code review и доменное review. Я сравниваю это со своим курсом по процессному мышлению и отражаю нужные изменения в материале. Но в то же время мне хочется делиться некоторыми инсайтами и с теми, кто уже проходил у меня обучение, чтобы они тоже двигались дальше по своему пути.
Как говорится, у самурая нет цели — есть только путь.
Далее https://job4j.ru/article/view/18
🔥7
Сегодня (2 мая) общая встреча в мини-группах.
Ссылки на эфиры в плашке job4j.ru
BigTech. Процессинговое мышление в 14:00. Проведет Петр.
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
Ссылки на эфиры в плашке job4j.ru
BigTech. Процессинговое мышление в 14:00. Проведет Петр.
Java 1 уровень в 14:30. Проведет Стас.
Java 2 уровень в 15:00. Проведет Алексей.
Java 3 уровень в 15:30. Проведет Стас.
👍3
Отключены уведомления в Telegram
Сервер платформы Job4j находится в Москве, поэтому работать с Telegramm он не может.
Используйте внутреннюю систему уведомлений.
Сервер платформы Job4j находится в Москве, поэтому работать с Telegramm он не может.
Используйте внутреннюю систему уведомлений.
🤝6😭5❤2🤬1
9 мая встреча в мини-группах
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
telemost.yandex.ru
Звонок в Яндекс Телемосте - 8309 0172 0032 77
По ссылке вы сможете подключиться к звонку
👍4
SDD, AI-агенты и новый сдвиг в обучении программистов
В этой статье хочу поделиться своими наблюдениями за тем, как меняются подходы в программировании с появлением AI.
На днях в рабочем треде я увидел переписку коллег. Они обсуждали, что делать с техническими файлами в репозитории.
Сначала я подумал: “Технические файлы? Это что, мусор?” Но оказалось, что речь идет о файлах, необходимых для работы AI-агента. И тут я понял: ага, значит, это уже внедряют и у нас.
Далее https://job4j.ru/article/view/19
В этой статье хочу поделиться своими наблюдениями за тем, как меняются подходы в программировании с появлением AI.
На днях в рабочем треде я увидел переписку коллег. Они обсуждали, что делать с техническими файлами в репозитории.
Сначала я подумал: “Технические файлы? Это что, мусор?” Но оказалось, что речь идет о файлах, необходимых для работы AI-агента. И тут я понял: ага, значит, это уже внедряют и у нас.
Далее https://job4j.ru/article/view/19
SDD на практике: создаём сервис уведомлений через Cursor AI
В этой статье я хочу поделиться новым способом создания проектов — SDD, Spec-Driven Development.
В предыдущей статье я уже начал говорить об этой методологии, а здесь покажу её на практическом примере. Такой же подход к созданию программы я буду просить использовать учеников в курсе по процессному мышлению, в разделе «Микросервисы».
Почему именно там?
Далее https://job4j.ru/article/view/20
В этой статье я хочу поделиться новым способом создания проектов — SDD, Spec-Driven Development.
В предыдущей статье я уже начал говорить об этой методологии, а здесь покажу её на практическом примере. Такой же подход к созданию программы я буду просить использовать учеников в курсе по процессному мышлению, в разделе «Микросервисы».
Почему именно там?
Далее https://job4j.ru/article/view/20
👍4
16 мая встреча в мини-группах
Завтра (16 мая) общая встреча в мини-группах. Отчеты
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
Завтра (16 мая) общая встреча в мини-группах. Отчеты
BigTech. Процессинговое мышление в 14:00. Проведет Петр. Эфир.
Java 1 уровень в 14:30. Проведет Стас. Эфир.
Java 2 уровень в 15:00. Проведет Алексей. Эфир.
Java 3 уровень в 15:30. Проведет Стас. Эфир.
GitHub
GitHub - job4j/flows
Contribute to job4j/flows development by creating an account on GitHub.