Как мы писали курс для Python-разработчиков с опытом и зачем сделали упор на асинхронное программирование

Два года назад Практикум запустил первые курсы для разработчиков с опытом. Один из этих курсов — «Мидл Python-разработчик». За это время его успешно закончили 140 студентов. Но мир разработки не стоит на месте, и это повод постоянно добавлять что-то новое в учебную программу.

О том, как создавался курс «Мидл Python-разработчик», что с ним происходит сейчас и что войдёт в программу нового дополнительного модуля, рассказала его команда:

• Анастасия Волошина, продакт-менеджер;

• Роман Моисеев, экс-продакт-менеджер;

• Михаил Николаев, автор и техлид;

• Мария Бондаренко, автор;

• Наталья Которева, редактор и контент-менеджер;

• Элла Шарафиева, лид сопровождения;

• Роман Володин, наставник и ревьюер;

• Артём Пахомов, наставник.

С чего всё началось

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

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

Ещё одна цель исследования — посмотреть, какие есть сегменты компаний и что требуется от Python-разработчика в каждом из них. Это было важно для составления портрета выпускника: мы хотели, чтобы в итоге человек умел работать с основой и перед ним открывался большой выбор вакансий, не только, скажем, в финтехе или ecommerce.

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

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

Этап проб и ошибок

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

Одна из наших первых ошибок — чрезмерная серьёзность подхода (а может, это и плюс). Мы решили сделать максимальный упор на качестве уже в бесплатной части: тщательно прорабатывали темы, долго обсуждали, как рассказывать о той или иной технологии и в каком порядке. На тот момент у нас было два автора: Миша Николаев, Technical Unit Lead в Авито, и Серёжа Козлов, на тот момент бэкенд-разработчик в Озоне, а также один редактор и по совместительству контент-менеджер Наташа Которева.  

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

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

Примерно через полтора месяца мы отправили бесплатную часть на бета-тест. И получили не самый лучший фидбек. Сильно бросалось в глаза то, что уроки написаны разными людьми, а также подтвердилась гипотеза, что такой объём информации может испугать потенциального студента. Мы быстро доработали уроки и запустили бесплатную часть в продакшен.

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

От старта до рефакторинга

После этого мы начали создавать основную часть курса. К нам присоединилась ещё одна автор — Маша Бондаренко, ведущий разработчик в Rambler. Но чтобы не повторять ошибок с раскрашиванием текстов, мы решили наладить процесс заново. В этом нам помог GitLab. Он как раз покрывал наши требования в плане организации работы и защищённости информации. Наш редактор Наташа писала об этом подробную статью.

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

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

Таким опытным путём мы скорректировали портрет потенциального студента и стали лучше понимать, на какую аудиторию ориентироваться. Это мы учли при рефакторинге курса.

Было сложно с командными проектами. До этого в Практикуме не было подобных практик по выстраиванию командной работы студентов: все курсы, которые были рассчитаны на новичков, подразумевали прохождение в одиночку. Так что создание базы командных проектов делали мы и команда курса «Мидл фронтенд-разработчик». При этом делали мы их по-разному.

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

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

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

К нам приходили ещё несколько авторов, которые помогли решить проблему нехватки рук при создании контента. Когда мы закончили курс, многие из них ушли, так как задачи больше не горели. Было здорово, когда команда авторов активно ревьюила тексты друг у друга, — это помогало выпустить более глубокий материал.

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

Что мы изменили в первую очередь

Рефакторинг ― это не то, что заканчивается в измеримые сроки. Изначально казалось, что мы берёмся за какую-то часть, дорабатываем её и продолжаем жить дальше, все проблемы починились. Но на самом деле всё не так. Многие проблемы пришлось решать достаточно долго.

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

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

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

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

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

• в блоке «Python» — минимум 9 правильных ответов из 14;

• в блоке «Базы данных» — минимум 3 правильных ответа из 7;

• в блоке «Архитектура» —  минимум 4 правильных ответа из 8;

• в блоке «Контейнеризация» —  минимум 2 правильных ответа из 5.

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

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

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

Про фидбек от студентов

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

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

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

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

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

О сопровождении: кураторы, наставники, ревьюеры

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

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

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

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

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

Ещё один классный момент, который касается не только нашего курса, но и всего Практикума, — Мастерская. Это наш «сервис», куда могут прийти реальные заказчики с задачами на разработку чего-либо, например сайта или приложения. А студенты разных профессий Практикума применяют свои знания на практике. И с недавних пор наши студенты тоже стали принимать участие в создании таких проектов в качестве тимлидов. Это даёт им опыт и возможность прокачать софт-скилы.

Кстати, часто наши выпускники продолжают работать на курсе в качестве наставников или ревьюеров. 

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

Асинхронное программирование

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

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

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

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

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

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

В программе курса «Асинхронное программирование» сначала мы даём общую теорию о том, как процессы и потоки работают в системе. Рассказываем, как с ними взаимодействовать, что можно с ними делать, как ускорить программу, которая работает последовательно.

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

Затем объясняем все необходимое о библиотеках и фреймворках, а последний, пятый спринт можно назвать базовым курсом про DevOps. Здесь разбирается, как перенести проект в продакшн, как работать с облаком и что можно сделать дальше.

За 2,5 месяца студенты выполнят пять проектов.

1. Анализ данных Яндекс Погоды. 

2. Планировщик задач.

3. Простой мессенджер.

4. Сокращатель ссылок.  

5. Облачное хранилище файлов. 

Кстати, курс подойдёт не только разработчикам на Python. Его могут пройти и те, кто работает с другими языками. Это будет полезно тестировщикам, аналитикам, специалистам DevOps и даже продакт-менеджерам.

---

Наш курс всё ещё растёт и развивается, несмотря на то, что с момента запуска прошло больше двух лет. И мы всегда рады видеть новых студентов, ведь только благодаря им возможно наше движение вперёд. Приходите на наш основной курс «Мидл Python-разработчик» или станьте одним из первых студентов «Асинхронного программирования» — ближайшие занятия на мини-курсе стартуют 29 августа и 26 сентября.