Academic Teaching is Hard

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Несколько месяцев назад у меня появилась возможность преподавать один курс для студентов третьего курса бакалавриата в Университете Иннополиса (Россия). Название курса было “Проектирование системного программного обеспечения”. Группа состояла примерно из 150 человек, а продолжительность курса составляла 8 недель. Мне предстояло провести для них шестнадцать лекций, по две лекции в неделю. И мне было поручено проверить их знания в конце курса. В общем, обычная работа для преподавателя университета. И знаете, по моему мнению, я провалил большую часть этой работы. Вот что я узнал.

Кстати, все лекции были записаны на видео, а все презентации доступны на GitHub.

У меня есть много опыта выступлений на программных конференциях, мастер-классах, митапах и тому подобное. Обычно такое выступление длится 30-40 минут, с последующими 10-15 минутами вопросов и ответов в конце. Потом, просто уходишь и расслабляешься.

Здесь было совсем иначе. Во-первых, лекция длится 90 минут с небольшим пятиминутным перерывом посередине. Во-вторых, мне пришлось выступить дважды подряд. В-третьих, у меня было по две лекции во вторник и две в среду. Таким образом, я проводил 180+180=360 минут преподавания каждую вторую неделю. 360 минут! Это почти как 10 конференционных выступлений! Представьте, сколько времени уходит на подготовку к десяти конференционным выступлениям. Все мои вечера и выходные полностью уходили на это. Урок, который я усвоил: начинайте готовить свой курс задолго до первого дня, и рассчитывайте потратить на это много времени.

Как кажется, для некоторых/большинства студентов мой курс был не столько о новом учении, сколько о получении оценки “A”. Они начали докучать мне с самого начала курса: как именно вы будете проверять наши проекты и как будет приниматься решение о выставлении оценки? Я не виню их, я виню себя: я не предоставил им программу курса в самом начале. Где-то посередине курса я ее составил, смотрите здесь.

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

В Учебном плане я предложил некоторые критерии, но они были далеки от объективности. Единственным объективным критерием было количество звезд, которое их репозиторий получил на GitHub. Кстати, все они достигли максимального необходимого числа: пятнадцати. Некоторые из них получили более сорока, что, согласно моему плану, было смыслом: показать им, что хорошее программное обеспечение с небольшим поддерживающим “толчком” (от звезд, которые дают вам друзья и родственники) может легко стать популярным.

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

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

Там были не только лекции, но и практические задания, называемые “Лаборатории”. У меня было трое ассистентов преподавателя (TA), каждый из которых занимался третью частью моих студентов. Ассистенты также обучали их проектированию программного обеспечения, пытаясь следовать тому материалу, который я представлял на лекциях. Получилось ли это хорошо? Нет, и это на 100% моя вина.

У каждого ассистента есть свои представления о проектировании программного обеспечения, о качестве программного обеспечения, о управлении, а также о многих других вещах. Если бы я хотел сделать это правильно, я бы сначала должен был “обучить” ассистентов, потратив для этого некоторое время перед началом курса. Возможно, мне даже пришлось бы дать им некоторые рекомендации, объяснив свои ожидания. Это было бы очень полезно, так как ассистенты взаимодействуют со студентами гораздо больше, чем лектор. Я, будучи преподавателем, не мог обсуждать вещи со студентами: я в основном передавал им свои мысли. Беседы происходят с ассистентами и на Лабораториях.

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

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

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

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

Таким образом, если вы хотите, чтобы ваш класс был полным каждый раз: 1) развлекайте их, 2) делайте оценки зависимыми от посещаемости и 3) не публикуйте видео до экзамена (или вообще не записывайте). Но я не сделаю ничего из этого. Мне нормально с десятью людьми в комнате, тысячами на YouTube и несколькими очень интересными продуктами, созданными теми, кто, вероятно, никогда не посещал (обсуждаю их ниже).

Было четыре возможных оценки: A, B, C и D. Оценка “D” считалась неудовлетворительной, но “C” тоже была неудовлетворительной. Студенты формировали небольшие группы из четырех человек. Каждая группа создавала свой собственный проект на GitHub (на самом деле, три группы из пятидесяти создали их на GitLab), и я их проверял. Вот как я распределил свои оценки:

Формально говоря, я поставил оценку “A” 2+6+22 человекам (включая оценки “A+” и “A++”), но я почувствовал обязанность подчеркнуть разницу между отличными и хорошими проектами, даже если они находятся в одной формальной категории “A”: вот почему есть дополнительные оценки “A++” и “A+”. Конечно, была возможность поставить “A” только тем, кто “A+” и “A++” в моей классификации, сдвинув остальной график вниз и дав больше оценок “C”, но я опасался, что это приведет к множеству жалоб. Проще говоря, я сдался.

Теперь, чтобы вознаградить тех, кто получил оценки “A++” и “A+”, я публикую их проекты здесь, а также их аккаунты. Они могут рассматривать этот блог-пост как мое личное рекомендательное письмо для каждого из них. Если вы, уважаемый читатель, являетесь потенциальным работодателем этих ребят, я настоятельно рекомендую их.

Вот они, двое с оценкой “A++”:

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

Вот шесть репозиториев с оценкой “A+”:

Они также довольно хороши.

Большое спасибо Университету Иннополис и лично его декану, профессору Джанкарло Суччи, за предоставленную мне возможность осознать, насколько сложно и … интересно быть учителем.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 22:22

sixnines availability badge   GitHub stars