YtYt - платформа для обучения программированию без инфоцыганства и вебинаров

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

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

У этих проблем есть следующие решения:

Все эти идеи были реализованы, и вот что получилось в результате:

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

Одна из ключевых проблем, с которой сейчас сталкиваются новички в программировании - это переизбыток информации. Тысячи видеороликов, книг и статей, десятки языков и фреймворков - всё это находится на расстоянии 1 клика мышкой. Здорово, правда? Но на практике такая доступность информации приводит к тому, что начинающие хаотично мечутся между разными языками и технологиями, потому что в прошлом месяце человек начал учить Python, а в этом месяце ему попались несколько статьей о том, что Go - это язык будущего, и учить нужно именно его.

Поэтому было принято решение создать чёткий пайплайн, по которому студент будет двигаться от "Ура, я умею в helloworld!" до "Вот мой репозиторий с пет-проектами, здесь Flask, а здесь Django, возьмите меня на работу".

Рассказывать ли об исключениях во вводном курсе "Основы основ"? Если да, то насколько глубоко? Стоить ли упоминать об объектной модели в отрыве от классов? Можно ли называть print() встроенной функцией до того, как было введено понятие "функция"? Показывать ли сразу, как работает WSGI-сервер, или сначала полностью разобраться с клиентской стороной?

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

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

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

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

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

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

После того, как студент сам напишет код, а потом сравнит результат с эталонным решением, он понимает, что конкретно можно было улучшить. Такой опыт куда сильнее закрепляется в памяти, чем абстрактный код, написанный кем-то другим. В результате количество грубых ошибок, выявляемых на ревью, снизилось раза так в 2 - 2.5 (субъективная оценка, учёт не ведётся). И теперь на ревью можно уделять больше внимания алгоритмам, декомпозиции и структуре программы, а не названиям переменных и прочим базовым вещам.

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

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

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

Любая критика, которая поможет проекту стать лучше, нереально важна на текущем этапе. Если вы вдруг решите зайти к нам на огонёк и заметите какие-то недочёты, то пожалуйста, поделитесь ими в комментариях или напишите на timur@ytyt.ru. Дадим людям и качественное образование, и удобный интерфейс :)

Спасибо за внимание!