Эксперименты с тиграми и другие способы преподавать программирование студентам, которым скучно

Привет, Хабр! Я Маша, старший инженер-разработчик iOS в КРОК и аспирант на кафедре Прикладной математики и Искусственного интеллекта в московском вузе. А еще я уже четыре года преподаю. Два года назад мы с коллегами с кафедры, преимущественно аспирантами, основали кружок спортивного программирования, который вырос в большое IT-коммьюнити в стенах универа, где мы делимся разного рода знаниями со студентами.

В рамках этой затеи мы решили улучшить процессы обучения дисциплинам Computer Science (до чего дотянулись). К нему у всех уже было много вопросов.

Первый ужас я испытала на первом же занятии со студентами. Одна группа не могла привести ДНФ в КНФ, другая — не смогла даже общим усилием воли вспомнить таблицу истинности для конъюнкции и дизъюнкции. Третья — не понимала как программно устроены списки (это у нас проходят годом ранее). А потом я вспомнила себя — про мой курс преподы говорили то же самое. И про курсы до нас, и про курсы после меня. И школьную учительницу Ольгу Николаевну вспомнила: «В этом году класс еще слабее, чем в прошлом — если так пойдет и дальше, вернемся к жизни на деревьях!». В школе мне казалось, что это такой изощренный педагогический прием, который должен подхлестнуть нас учиться усерднее чтобы «доказать, что мы лучше чем кажется». Ошибалась.

Решили мы с коллегами порефлексировать — а почему так происходит? Результаты, наши грабли и опасные эксперименты с тигром под катом!

За что я так с ними? За что они так со мной?

Осознание, что что-то не так ко мне пришло, когда мой научный руководитель, который ругал мою группу во время обучения, три года спустя теми же словами ругал группу, в которой я преподавала. «Вот вы-то были умненькие, старательные! А эти! Тьфу!»

Тут мне подумалось, что, кажется, дело не в студентах. И вовсе даже не в их старательности или умненьковости. Возможно, что дело и не в преподавателе… А в чем тогда?

Так началось мое грандиозное расследование.

Сначала, где-то осенью 2018, я решила пообщаться с первокурсниками, чтобы проследить, в какой именно момент «все идет не по плану», но не по плану пошло уже у меня:


Вечером после рабочего дня. Кайф.

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



Фидбек от студентов

Стало ясно, что саботировать обучение студентов заставляют два фактора:
— внутренний: я не понимаю, зачем мне это («скучно рассказывают», «говорят ни о чем», «какая-то устаревшая фигня», «я это уже умею»)
— внешний: все в группе ничего не делают, почему я должен?

Первый фактор очень забавно выглядит со стороны препода. Это нам с вами понятно, что есть всякие там фронтенд, бэкенд, фулстек, а студенты что слышат? «IT — круто!», «машинное обучение — будущее!» В итоге выходит, как в этом забавном твите у Брагилевского:


Виталий Николаевич плохого не скажет (ну разве что иногда и в шутку)

А вот второй фактор занимателен сам по себе. Студенты, если честно, не делают ничего предосудительного, даже наоборот. Они стремятся оптимизировать свои ресурсы, и делают это очень даже эффективно! Представьте, что чтобы получить Х, у вас есть два пути: вложить очень много сил и времени или воспользоваться уже готовым рабочим решением. Какой вы выберете? А если речь про сдачу экзамена по профильному предмету?

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

Студенты:
— ничего не понятно, слишком высокий порог входа
— куча «бесполезного»/«устаревшего» материала (зачем мне это все? Где хайповые темы, нейросетки и популярность?)
— не видно корреляции между вложенными на изучение предмета усилиями и профитом от этого в будущем
— я уже это все умею, зачем мне тратить время на «подтягивание» остальных?
— зачем так много работы? Можно же сделать всего одну лабу и предмет уже зачтут

Преподаватели:
— студенты считают, что я несу какую-то бесполезную ахинею
— но они об этом молчат, а я не телепат — соответственно, курс улучшить не могу
— студенты много мухлюют, пытаются меня обмануть ради оценки (списывают, подделывают подписи и т.п.)
— отношение студента к образованию как к сервису: «преподаватель должен мне услугу», «вы меня не научили!»

И все мы страдаем от глобального:
— программа «устарела» и не поспевает за развитием области (и мотивацией студентов)
— когнитивной нагрузки слишком много

Что по мотивации и программе?

Кто раньше шел учиться на кафедры прикладной математики? Увлеченные школьники-олимпиадники по физике и математике. Еще раньше — члены кружка радиолюбителей. Я клоню к тому, что это были ламповые нерды — люди, которым действительно интересна наука и сложные задачи.

Сегодня IT — это хайп. Просто для сравнения: вы давно видели агитацию становиться ветеринаром? А инженером-энергетиком? А врачом? А вот в IT зазывают буквально на каждом углу!


Да дайте уже позалипать в соцсеточки!

Более того, IT это не просто реклама «перспективности». IT буквально вокруг нас. Для современного студента быть программистом — все равно что быть «ветеринаром для смартфона» (так видит мою профессию шестилетний племянник).

Зачем абитуриенты шли в IT двадцать лет назад:
— интересные задачи!
— много математики!
— можно проектировать схемы и делать роботов!
— можно написать свой язык программирования!
— можно писать пРоГрАмМы!

Зачем абитуриенты идут в IT сегодня:
— многа деняк!
— хочу писать видеоигры! Это же весело, да?
— хочу делать крутые продукты и делать жизнь людей проще! (это приложение Х такое …, я бы — сделал лучше если б умел!)

Что они получают?
— задачи
— математику
— проектирование схем
— теорию построения трансляторов

… погодите, а видеоигры где?

Отсюда и получается ощущение «устаревшей» программы. Низкоуровневое воспринимается как «древнее», а хайповое просто не находит отклика в закрепленных терминах (десять лет назад мы говорили «индуктивный вывод», а сегодня — «машинное обучение»). Связь низкоуровневого с актуальными технологиями и обновленных терминов с «классическими» также по разным причинам не доносится до студентов, что только укрепляет их в мысли что «это все не то».

Более того, какие-то области и вовсе никак не вплетаются в канву образования, просто не успевают: лет пять назад мы почти не знали про микросервисы и DevOps, а сегодня это уже целая профессия. Адаптироваться к такому развитию индустрии трудно, но не невозможно. Ниже спрятала интересные источники, где можно наглядно отследить, как появляются и отмирают области знаний.

Когнитивная нагрузка: это who?

Теория когнитивной нагрузки (Cognitive Load Theory, CLT) появилась в поздних восьмидесятых в рамках когнитивной психологии. Вкратце, эта теория описывает использование рабочей памяти человека и трудности, которые могут возникать в этом процессе. Значительная часть этой теории посвящена изучению вопросов обучения и обучаемости.

Если не вдаваться в подробности, то CLT постулирует мысль о том, что объем рабочей памяти ограничен и его переполнение может вызывать сильные провалы в «производительности» (да, аналогия с ОЗУ тут вполне прямая).

TED Talks про CLT для тех кто любит смотреть и слушать,
статья в журнале Learning and Instructions для тех любит читать!

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

Мы с коллегами постарались следовать этой теории, и вот чего добились.

Что мы делали и что получили: факапы, интриги, расследования

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

Автомат за курсеру/литкод

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

Схема была озвучена такая: проходишь три курса из специализации Яндекса по С++, в личной беседе доказываешь преподавателю, что ты реально слушал, а не прокликал (отвечаешь на вопросы, решаешь задачи: как на техническом интервью) — получаешь автомат за курс «Теория Графов и Комбинаторики» (ТГиК).

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

В итоге выяснилось, что подавляющее большинство задачи списали. Кто из интернета, кто друг у друга. Часто попадались вот такие забавные ситуации:

DiffChecker довольно наглядно показывает, что код был списан

Мы все-таки хотели научить студентов решать задачи, поэтому после подозрения на списывание перед получением автомата им открывался новый круг ада: защита. Очно на паре мы давали задачу прямо на литкоде — сиди решай на компе как хочешь. После решения надо было объяснить это преподу (то есть нам) и ответить на дополнительные вопросы. По итогу это больше походило на алгоритмическую секцию технического интервью.

После защиты нескольких таких задач автомат подтверждался. Однако было и ограничение. За одну пару можно решить две средненьких задачи. Если не решает — отправляется с этими задачами домой. На следующей паре объясняет решение этих + получает на решение в классе еще одну. Если после трех таких попыток студент все еще не решил ни одной задачи в классе (в реальном времени) — автомат ему не ставим. Ибо не надо DDoS-ить препода! В итоге автомат по этим правилам получило 3-4 человека из 50 (две учебные группы).

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

Проблема была в том, что мы не сообразили, что первую задачу студентам будет решать так же тяжело, как и вторую. Мы-то считали, что они уже умеют в С++. А они не умели!


Отзывы студентов

Результат:

• в погоне за одобрением студентов и модными подходами мы упустили пользу: кажется, что курсера и литкод не помогли ребятам разобраться в теории графов
• зато одобрение догнали: получили много отзывов, что кому-то было приятно учиться «по-современному», а кому-то курсера/литкод здорово помогли развить скилл программирования в целом (по данным нашей институтской курсеры «белый пояс» по C++ прошли 40 студентов, а еще 20 — следующий уровень. А в общем — 350 курсов и более 500 студентов!)

Проектирование когнитивно-простых тестов

Другой мой коллега решился (был вынужден) экспериментировать прямо во время локдауна. Он с февраля по июнь вел дисциплину под названием «Теоретические Модели Вычислимости» (ТМВ), предмет в известной мере сложный для студентов, с большим количеством математики и формализма. До и после локдауна мы использовали совершенно разные способы улучшить процесс подачи и проверки материала.

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

— сдаешь все 5 контрольных работ по ключевым темам -> молодец, допускаешься до экзамена!
— не сдаешь -> не допускаешься ¯\_(ツ)_/¯, иди пересдавай пока все не сдашь!
— очень хотелось отучить студентов списывать: отбирали телефоны пока они писали контрольную (в прозрачный контейнер на преподском столе). О таком порядке проведения контрольных было сообщено заранее. Любого, кого поймали с телефоном, отправляли на пересдачу к/р.

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


Вариант с заготовленными ответами для преподавателя

Неожиданностью и факапом для нас было то, что невозможность списывания и последующая неотвратимость наказания не мотивировала студентов изучать предмет. Вовсе наоборот: студенты дружно поддались общему потоку отчаяния с мыслью «всех все равно не отчислят». Неотвратимость наказания сработала не как честный метод разделения «молодцов» и «халтурщиков», а как бичевальная система злого дяди-препода, который «валит ВСЕХ!».

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

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


Результат:

• поняли что «кнут и пряник» с современными студентами не работает, а только вгоняет их в тоску
• срез знаний нужен чаще, чем в самый последний момент (на сессии) и чаще, чем раз в тему, чтобы отловить момент, когда студенты «поплыли»
• ты можешь быть самым дружелюбным и открытым преподом на свете, но если студенты ничего не понимают — с вопросами они не придут
• автомат студентов не прельщает, если он не освобождает от «обычного» прохождения курса. Хотя может это мы их избаловали предыдущим кейсом :)

Участие в командной разработке в GitLab: issues, merge requests, pipelines…

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

RegLang Calculator — это проект на Kotlin (хотели актуальных технологий вместо LISP — ну и пожалуйста!), в котором студентам было нужно наполнить алгоритмами 5 языковых конструкций (например, проверить, может ли регулярное выражение определить слово в языке). Для каждой задачи были описаны методы и их семантика (входные и выходные данные). Студентам предлагалось пойти и зарезервировать за собой задачу комментарием:



Дальше процесс шел как обычно:
1. студент создает issue
2. решает задачу
3. отправляет MR на code review
4. если все ок, MR мержится и закрывается, если нет — студент возвращается к шагу 2

master ветка естественно была protected, все студенты были помечены ролью developer. Работа предполагалась в одном репозитории, так как на объяснение форков ушло бы слишком много времени, а мы и так потратили целое занятие на объяснение гита и гитлаба. Еще был ридми с подробным планом действий:


Был и пайплайн сборки, который проверял:

— проходят ли автотесты (часть, которая проверяла, что ничего не ломается, была написана преподавателем при подготовке проекта, другую часть (что задача работает корректно) должен был дописать студент для своей задачи)
— кодстайл. Использовали Detekt. На его настройку потратили не очень много времени, поэтому часть MR пришлось вмерживать с непроходящим линтером, так как он не пропускал большую вложенность (много if внутри других if)



Некоторые студенты начинали DDoS-ить препода вопросами (прямо как на скрине в начале статьи). Для них пришлось ввести прогрессивную шкалу: чем больше вопросов — тем больше интервал между ними.

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

Результат:

• студенты научились работать с гитом через пот и слезы — однозначно плюс! (хотя теперь они нас ненавидят)
• студенты прочувствовали хотя бы один алгоритм из курса, реализовав его своими руками на незнакомом языке
• студенты изучили Kotlin, потратив на это минимум усилий (правда, за это они нас тоже ненавидят)
• студенты не слишком прониклись GitLab и GitFlow — на это надо было потратить больше времени. Основной фидбек студентов на гитлаб: «ОЧЕНЬ КРУТО, НО НИЧЕГО НЕПОНЯТНО»
• разным студентам понадобилось разное количество итераций code review, чтобы сделать все правильно, но они сошлись в одном: после того, как лабы зачли, никаких правок (даже если оставались unresolved review) они не вносили, даже самые умненькие и мотивированные

Вычисление списывальщиков: mission MOSSible

Для проверки и вычисления жуликов мы открыли для себя и использовали стенфордский алгоритм Moss (Measure Of Software Similarity). По итогу он был реализован как веб-сервис, который прогоняет алгоритм на файлах, которыми в него кидаешь, а потом показывает результаты на веб-страничке. Его код для доступа к сервису написан на Perl, но есть и несколько других community contributions, некоторые перечислены и на странице с описанием алгоритма. О том, как он определяет степень похожести программ, можно прочитать здесь. Небольшая инструкция, как получить ключ доступа и пользоваться перловым скриптом есть здесь. Подробно о том как пользоваться Moss можно прочитать здесь.

Есть еще сервис DiffChecker, его мы использовали для проверки задач с литкода. В отличие от Moss, DiffChecker не дает оценку «похожести» программ, а только выделяет различающиеся слова/строки (обычный diff). Особенность Moss в этом плане в том, что он «умным» способом определяет различные примеси/шумы и тому подобное, что часто сбивает с толку и человека и «наивные» плагиат-чекеры. Выбирать какой из файлов считать «оригинальным» все равно придется преподавателю. Но, по крайней мере, Moss поможет избавиться от ощущения «мне кажется или они похожи?» Не кажется. Похожи. Вот процент схожести. Оценку пополам делить будем? :)

Подробности по данному вопросу в рамках этой статьи уже too much, но если интересно — давайте пообщаемся в комментариях!

«У вас было два месяца, чтобы сдать» или эксперимент с группой VK и Google Classroom для приема лабораторных по БКП

В сентябре этого года меня снова поставили на Базовую Компьютерную Подготовку (БКП), и я, боясь, что забуду все сроки, которые назвала мне лектор, решила вывалить эту инфу из головы прямиком… в закрытую группу VK.



В этой группе я сразу опубликовала в виде текста с картинками описание учебного процесса (когда и как сдавать лабы, что нужно для допуска к экзамену и т.п.), а заодно постила срочные объявления и анонсы занятий.



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



Как видите, мне даже лайки накидали, а охват намного шире моих 25 студентов — ребята делились со своими однокурсниками (это факт, я видела :))

Мое изначальное предположение было в том, что наличие текстовых «конспектов» по орг.процессу, а также размещение материалов и общение в известной соцсети поможет снизить когнитивную нагрузку на ребят. И — О ЧУДО! — это сработало!

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


Количество отчетов по лабораторным, уносимое мной домой с каждого занятия, начиная с середины семестра

Коллега посоветовал мне Google Classroom, которым сам пользовался на тот момент уже третий год, и я поддалась искушению.

Classroom — это очень прикольная и гибкая штука, которая позволяет:
1. формировать темы с заданиями
2. формировать задания разного типа (в том числе тесты и анкеты)
3. проставлять оценки автоматически на основе критериев оценки работы и аккумулировать их, например, по темам
4. все это работает на базе G-Suite


Удобно заранее сформулировать критерии оценки работы

Помимо этого все работы студентов загружаются автоматически на гугл диск, а проверяются вот в таком удобном интерфейсе:


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

Проверка работ в Classroom похожа на игру в пинг-понг и работает по следующей схеме:

1. учитель создает задание и оно назначается всем ученикам
2. ученик прикрепляет файлы с выполненным заданием и сдает работу
3. учитель проверяет работу, выставляет оценку и возвращает ее ученику
4. если ученика не устраивает оценка он может внести исправления в свою работу и вернуть работу на проверку учителю (в таком случае на ней появится пометка «сдано повторно»)

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

Любой, кто преподавал на младших курсах (да и вообще в вузе) знаком с этой ситуацией:


Совсем не смешно, между прочим

Я своим студентам выставила в этом семестре такое условие:
1. заранее известны сроки сдачи каждой лабы
2. если сдаешь в срок — получаешь оценку как обычно
3. если сдаешь позже — получаешь минус балл (то есть вместо 3 ставлю 2, вместо 5 — 4)

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

В прошлом году условия, кстати говоря, были те же, но сдавать лабы можно было только очно и нигде не были зафиксированы требования и сроки. В результате я часто забывала кто, когда и что сдал, кому надо минусовать, а кому — нет. Неотвратимость наказания, о которой я говорила, не работала вообще никак. Classroom же сам мне подсвечивает сроки сдачи. В итоге и мне удобно, и механизм минусования прозрачный (нет надежды на любимый «авось»).

Результат:

• снижать когнитивную нагрузку за счет соцсети — работает! Но приходится быть админом паблика
• неотвратимость наказания в виде зафиксированных правил и критериев оценки работы — работает! Главное не перегнуть палку, как в предыдущем примере.«Это не я злая, это ты задание не выполнил, вот смотри критерии» воспринимается намного лучше, чем: «я поставлю тебя в сложную ситуацию и потом отругаю за то что ты ничего не смог поделать». Грань действительно тонкая, надо экспериментировать.
• электронная ведомость очень помогает следить за прогрессом и сложными правилами выставления оценки (круто, если ее можно экспортировать в Google Sheets, например!) не только каждого конкретного студента, но и всей группы в целом. Так, например, я заметила что
• в этом году группа сдает лабораторки «быстрее», чем ребята в прошлом и позапрошлом году. То есть к середине семестра сдано чуть меньше половины всего плана по л/р. Для сравнения — в прошлом семестре было чуть меньше четверти.
• результаты контрольной работы (проводится по классике, на листочках) ощутимо лучше, чем в прошлом и позапрошлом году!

И напоследок

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

1. Студенты в ужасе от количества требований (проблема с когнитивной перегрузкой):
— облегчить им жизнь (ну и себе тоже) — четко пропишите структуру курса, сроки сдачи работ и критерии оценки;
— попробовать схему с неотвратимым наказанием (если знаешь правила — не лажай, а лажаешь — пеняй на себя). Дисклеймер: применять с осторожностью.

2. Студентам кажется, что курс занудный и вообще не пригодится:
— потратить пару семинаров на объяснение, как им в реальном мире пригодится то, что они будут изучать (это — фундаментальная истина, и вряд ли она изменится). Рассказать, в каких продуктах, которые они используют, применяют технологии и методологии курса. Как то, чему вы посвятите семестр, связано с хайповыми темами;
— не стесняться периодически напоминать им об этом, и чем разнообразнее тем лучше! (А вот в Mail, а вот в Яндексе, а вот в Google…) Очень круто работают ссылки на конференции, где сотрудники рассказывают о релевантном опыте: студенты скорее всего смотреть не будут, но зато точно станут больше вам доверять;
— объяснить, что учиться придется всю жизнь, а «мерзкая дискретка» здорово поможет в будущем учиться быстрее. Потому что на ней строятся технологии X, на которых строятся методологии Y…
киньтесь в них для усиления Computing Curricula или любым другим источником, которому доверяете.

3. Студенты DDoS-ят жалобами «Я ничего не панимайю и разбираться с этим не хочу»:
— регулярно просить обратную связь по курсу и не ругать за ошибки. Цель — чтобы студенты не боялись признаваться вам, что что-то не понимают. Да, придется стать эджайл-коучем для учебной группы, но что поделать :)
— если студент сдался, то попробовать честно с ним поговорить (можно слукавить — это не ты ничего не понимаешь, это я плохо объясняю): «В какой конкретно момент ты понял, что ничего не можешь решить?», «Почему ты решил, что не справишься и ничего не будет работать?», «Как я могу улучшить курс, чтобы он стал лучше/интереснее/проще?»
— поощрять всех — и тех, кто хардово работает, и тех, кто еле-еле успевает за программой. Речь не о том, что «все дети способные», а о том, что у каждого свой порог входа, и если студент прикладывает усилия — он молодец. Есть такие, кому все дается легко «от балды» — их поощрять не надо, это медвежья услуга: сейчас играют навыки, которые он уже получил в прошлом, но так как новые сейчас он не получает, то в дальнейшем споткнется о самое простое. Может и нет, конечно, но в любом случае поощрять надо не оценки, а получение компетенции (в идеале эти метрики совпадают).



В комментариях будет интересно обменяться мнениями: какие новые подходы вы обкатываете на студентах (а если нет, то почему), как часто контролируете понимание предмета, как находите контакт с новой группой, что демотивирует ваших студентов и вас?

Студенты тоже присоединяйтесь — как справляетесь со своими мудрыми старцами-профессорами? Что полезного они делают с вами и наоборот? Что вас бесит в образовательном процессе?