14 листопада CS центр втретє запускає онлайн-програми "Алгоритми та ефективні обчислення", "Математика для розробників" та "Розробка на C++, Java та Haskell". Вони створені, щоб допомогти поринути у нову область і закласти фундамент для навчання та роботи в IT.
Щоб вступити, вам потрібно буде поринути в атмосферу навчання та скласти вступний іспит. Детальніше про програму, іспит та вартість читайте на .
А поки що асистенти викладачів та куратор програм минулого запуску розкажуть, як організовано навчання, хто приходить навчатися, як і навіщо асистенти роблять код-рев'ю під час навчання і чому їх навчило участь у програмах.
Як влаштовані програми
У CS центрі є три онлайн-програми на платформі Stepik: , и . Кожна програма складається із двох частин. Це курси, підготовлені досвідченими викладачами та вченими:
- Алгоритми та теоретична інформатика у складі програми за алгоритмами.
- Матаналіз, дискретна математика, лінійна алгебра та теорія ймовірностей у програмі з математики для розробників.
- Курси C++, Java та Haskell в онлайн-програмі з мов програмування.
А також додаткові активності, наприклад, код-рев'ю, вирішення теоретичних завдань на докази, консультації з помічниками та викладачами. Їх складно масштабувати, тому навчання відбувається у невеликих групах. Активності допомагають глибше розібратися в темі та отримати якісний зворотний зв'язок.
Артемій Пестрецов, асистент викладача: «Мені здається, що код-рев'ю — головна відмінність онлайн-програм з мов і алгоритмів. Щоб знайти відповідь на своє запитання, можна просто погуглити. Це важко та довго, але можливо. А ось код-рев'ю гугл не зробить, тож це дуже цінно».
Кожен курс усередині програми триває приблизно два місяці. У фіналі студенти повинні скласти іспит або отримати заліки з усіх курсів.
Хто наші студенти
Студенти онлайн-програм:
- Хочуть заповнити прогалини в математиці чи програмуванні. Наприклад, досвідчені розробники, котрі хочуть підтягнути математичну базу.
- Починають знайомитися з програмуванням і включають програми центру до свого самоосвітнього плану.
- Готуються до вступу до магістратури чи CS-центру.
- Студенти з іншою профільною освітою, які вирішили кардинально змінити напрямок. Наприклад, хіміки чи педагоги.
Артемій Пестрецов: «У нас був студент, чоловік у самому розквіті сил, який працював у нафтогазовій компанії і взяв відстрочку дедлайнами, бо поїхав у відрядження на свердловину. Прикольно, що люди з різним досвідом бачать, що IT-технології та математика набрали обертів. Це люди, які відбулися, які можуть і так чудово жити, але намагаються дізнатися щось нове, хочуть розвиватися в інших областях».
Михайло Веселов, : «Рівень у всіх різний: хтось не до кінця розуміється на базових речах у мові, а хтось приходить програмістом на Java або Python, і з ним можна підтримувати розмову в дусі «як зробити краще». Головне, орієнтуватися не на кращих із кращих, а на середній рівень, щоб курс виявився корисним для всіх».
Як організовано навчання
Декілька інструментів допомагають організаторам та викладачам будувати процес.
Листування у пошті. Для важливих та формальних оголошень.
Чат з викладачами та організаторами. Діти часто починають допомагати один одному в чаті ще до того, як викладач або асистент побачать питання.
YouTrack. Для питань та здачі завдань викладачам та асистентам. Тут можна ставити приватні питання та обговорювати рішення віч-на-віч: ділитися рішеннями один з одним студенти, звичайно, не можуть.
Організатори спілкуються зі студентами та намагаються швидко вирішувати проблеми. Христина Смольникова: «Якщо кілька студентів запитують те саме, значить, це загальна проблема і треба розповісти про неї всім».
Як допомагають помічники
Код-рев'ю
Студенти програм здають домашні завдання, а помічники перевіряють, наскільки їх код чистий і оптимальний. Ось як хлопці організували реву минулого разу.
Артемій Пестрєцов намагався відповідати на запитання протягом 12 годин, бо студенти складали завдання у різний час. Читав код, знаходив проблеми з погляду стандартів, загальних практик програмування, докопувався до дрібниць, просив оптимізувати, підказував, які імена змінних треба виправити.
«Всі по-різному пишуть код, люди мають різний досвід. Були студенти, які взяли та написали з першого разу. Мені все подобається, це чудово працює та перевірка займає 25 секунд, тому що все ідеально. А буває, що сидиш і протягом години намагаєшся зрозуміти, навіщо людина написала такий код. Це абсолютно адекватний навчальний процес. Коли в житті проводиш код-рев'ю, так і буває».
Михайло намагався збудувати процес незалежно для кожного студента, щоб не було ситуації «Я це вже комусь пояснював, спитай у нього». Давав детальний перший коментар до завдання, потім студент ставив уточнюючі питання та оновлював рішення. Послідовним наближенням вони отримували результат, який влаштовував якість і наставника, і студента.
«У перші один-два тижні навчання люди пишуть не дуже акуратний код. Їм потрібно дбайливо нагадати про стандарти, які є і в Python, і в Java, розповісти про автоматичні аналізатори коду на предмет очевидних помилок та недоліків, щоб потім на це не відволікатися і щоб весь семестр не діставати людину тим, що у неї перенесення неправильно зроблено або кома не там стоїть».
Поради тим, хто хоче проводити навчальні code review
1. Якщо студент написав проблемний код, треба просити переробляти його заново. Важливо, щоб він зрозумів, у чому проблема цього коду.
2. Не варто брехати студентам. Краще чесно сказати "я не знаю", якщо немає можливості розібратися у питанні. Артемій: «У мене був студент, який копав набагато глибше за програму, спускався на рівень заліза, потім знову піднімався і ми з ним постійно каталися на цьому ліфті абстракцій. Мені доводилося згадувати якісь речі, але відразу сформулювати було дуже важко.»
3. Не треба загострювати увагу на тому, що студент-початківець: коли людина щось робить вперше, вона серйозніше ставиться до критики, зовсім не знає, як це роблять зазвичай, і що в неї виходить, а що ні. Краще обережно говорити лише про код, а не про мінуси студента.
4. Здорово навчитися відповідати на запитання у «освітній» манері. Завдання відповісти не прямо, а зробити так, щоб студент дійсно зрозумів і сам дійшов до відповіді. Артемій: «У 99% випадків я міг відразу відповісти на запитання студента, але не часто міг відразу взяти і написати відповідь, тому що треба багато що зважувати. Написав п'ятдесят рядків, стер, знову написав. Я відповідальний за репутацію курсів та знання студентів, і це непроста робота. Дуже круте почуття виникає, коли студент каже: "О, у мене осяяння!" І я теж такий: "У нього осяяння!".
5. Важливо бути уважним і сильно не критикувати. Надихати, але не надто щоб студент не думав, що робить все шикарно. Тут доведеться навчитися грамотно керувати рівнем своїх емоцій.
6. Корисно колекціонувати загальні зауваження та однотипні помилки, щоб заощаджувати час. Можна записати перше таке повідомлення, а потім просто копіювати і додавати деталі у відповідь іншим на таке саме запитання.
7. Через різницю у знаннях та досвіді деякі речі здаються очевидними, тому спочатку асистенти не розшифровують їх у коментарях для студентів. Допомагає просто перечитати написане та дописати те, що здавалося банальним. Михайло: «Мені здається, що довше я допомагаю з перевіркою рішень, тим зрозуміліше я студентам нового курсу від самого початку. Перші коментарі до коду я зараз прочитав би і сказав: «Треба було акуратніше, докладніше».
Викладати та асистувати — класно
Ми попросили хлопців розповісти, який корисний досвід вони здобули, поки проводили код-рев'ю та спілкувалися зі студентами.
Артемій: «Головне, чому я навчився — такому, викладацькому, терпінню. Це абсолютно нова навичка, я освоюю для себе зовсім нові, не технічні галузі. Думаю, що викладання дуже допоможе, коли я виступатиму на конференціях, у розмові з колегами чи презентації проектів на мітингу. Раджу всім спробувати!
Михайло: «Цей досвід допоміг трохи терпиміше ставитися до того, що хтось пише код не так, як я. Особливо коли тільки починаєш дивитися на рішення. Курси з Python і Java я проходив сам і схожі завдання вирішував інакше. Інакше називав змінні та функції. І рішення хлопців усі трохи інші, бо в програмуванні немає еталонного рішення. І ось тут потрібне деяке терпіння, щоб не сказати: "Треба було робити тільки так!" Це допомогло потім на роботі обговорювати плюси та мінуси конкретних рішень, а не плюси та мінуси того, що це зробив не я».
Джерело: habr.com