Как учить людей JS: Часть 1. Заметки на полях
Когда я неосмотрительно давал в @jsunderhood обещание рассказать о моем видении обучения JavaScript — я был искренне уверен, что справлюсь в рамках одной, пусть даже большой статьи. Однако попытка систематизировать свои разрозненные заметки вылилась к тому, что я понимаю, что еще даже и близко не приблизился к созданию единой теории “всего” в контексте обучения.
Эта статья — результат промежуточной победы внутреннего философа над перфекционистом — открывает небольшую серию статей о моем видении преподавания.
Disclaimer
Я никогда не учился в педагогическом ВУЗе (впрочем в рамках моего университетского образования изучал педагогику и как магистр, и как аспирант (мне повезло — у меня ее велвосхитительный практикующий психолог)
За долгое время “обинтернетивания” моей грамматической сущности и “отвиттеривания” моего аватара, он изрядно растерял впитанную со школы любовь к правильно поставленным запятым, поэтому любые грамматические, стилистические и прочие правки к любому моему контенту только приветствуются.
Если Вы профессиональный преподаватель или преподаете 10+ лет — боюсь, мои изыскания будут для вас тривиальными и очевидными. Я с радостью выслушаю ваше мнение в комментариях, особенно если укажете на мои ошибки или на, что именно у Вас не работает.
Теперь, что касается JavaScript упомянутого в названии статьи. Да, я буду акцентировать внимание на некоторых реалиях, которые к сожалению специфичны для нашего любимого языка, по одной простой причине — именно этим я занимаюсь долгое время. И хотя общие методики и подходы будут универсальными, по всему циклу статей изюминками (а скорее изюмом) будут рассыпаны мысли об особенностях обучения этой конкретной теме.
Цель
Преподавание ради преподавания — сродни ментальной мастурбации. Еще хуже — когда преподаватель ставит перед собой (или перед ним ставят) задачу “вычитать Х часов”, а не выработать определенные навыки и знания. Я буду акцентировать большее внимание на выработку навыков — передача знаний осуществляется путем рассказа об этих знаниях, самостоятельной работы с материалами и упором на тот тип восприятия информации, который максимально комфортен студенту (нет, я не знаю как максимально эффективно доносить JavaScript кинестетикам).
Итак, я считаю что цель преподавания JavaScript как языка программирования в следующем:
- выработать понимание базовых принципов работы среды выполнения JavaScript (типы данных, event loop, низкоуровневая логика)
- выработать навыки решения реальных задач на JavaScript на базе фундаментальных основ языка. На данный момент я выделяю всего три подобных основы: асинхронность, событийная модель, функциональный подход
- выработать понимание высокоуровневых взаимодействий кода (паттерны проектирования, модули и т.д.)
Хочу обратить внимание, что первый пункт не является измеримым — тем не менее его отсутствие затрудняет дальнейшее развитие программиста
Кто может преподавать?
Преподавание — один из лучших, но один из тяжелейших путей улучшения собственных навыков. Распространенной считается ошибка, что преподавать можно только полностью разобравшись “в теме”. Это не так, и я вообще не верю, что можно в чем-то полностью и досконально разобраться.
- Не бойтесь признавать что чего-то не знаете. На начальном этапе вашей преподавательской жизни лучшим, что Вы можете сделать является фраза “у меня нет ответа на Ваш вопрос, но я обязательно разберусь и расскажу”. Хорошего преподавателя от “заб(и/ы)валы” отличает то, что он приходит и рассказывает с чем разобрался.
- Не бойтесь совершать ошибки. Иногда я на лекции могу 10 минут искать идиотскую ошибку в только что написанном коде. Вы человек и ошибаться — это естественно. Учитесь признавать свои ошибки
- Старайтесь избегать “идеально” заготовленных материалов для обучения. Лучше потратить время и написать код с нуля (при условии что это займет у вас 2–3 минуты), чем воспользоваться готовым куском. Когда вы пишите (и рассуждаете при этом вслух) студенты бессознательно запоминают ваши мысли. Если вы допустите ошибку в коде — то они же научатся искать эти ошибки, подсматривая как это делали Вы.
- Не бойтесь признавать, что у кого-то что-то вышло лучше, чем у Вас. Вы не обязаны делать все самостоятельно. Стойте на плечах гигантов — не бойтесь в своих курсах использовать доступные в Интернете материалы (если тот же Илья Кантор рассказал о webpack’е гораздо лучше вас — воспользуйтесь этим. It’s all about sharing, но не забывайте указывать авторство и пиарить людей, которые делают крутой контент)
“Они ничего не понимают” или коварство аналогий
Да, не понимают. Если вы попытаетесь объяснить зеленым джуниорам механизм работы промисов, вдаваясь в дебри языка (хотя казалось бы, чего тут сложного) — утонут даже самые умные. Ищите аналогии. Аналогии должны позволять вам проводить параллели между понятийным аппаратом области, в которой вы натаскиваете падаван и той, которая ему известна. Вы можете сколько угодно приводить аналогии про прыжок с парашютом, но если у студента не было подобного опыта — все будет мимо.
Теория, это когда все понятно, но ничего не работает.
Еще одна важная мысль — забавные аналогии лучше запоминаются. Ученики лучше запоминают какую-нибудь забавную историю про колонну танков, на башнях у которых нарисованы единици и нолики, чем такую же аналогию про ленту из телеграфного аппарата. Но помните, аналогия может быть забавной, но не абсурдной. Если вы в своей аналогии заставляете, к примеру голубя нырять под воду или бурить скважины — то подобным бредом вы только засоряете мозг слушателей, а не облегчаете понимание.
И еще одно, не совсем про аналогии, но про объяснения. Однажды у Артемия Лебедева спросили, почему он, вроде такой умный человек, а когда его просят дать определение чего-то он начинает со слова “когда”. На что Артемий глазом не моргнув ответил: “Хорошее объяснение — это когда все понятно”.
Злейший враг ученика
В жизни преподавателя JavaScript нет более злого и коварного “помощника”, чем Google и его приспешники — StackOverflow, W3Schools и прочее. Эти сервисы обещают начинающему джаваскриптеру решение всех проблем, и, как “двое из ларца”, готовы помочь с самой сложной проблемой. Но начинающий падаван (а скорее даже юнлинг) сталкивается с тем, что перед ним куча немодерированной информации разной степени устаревания.
С количеством ужасного кода на JavaScript в интернете может поспорить, наверное, PHP, и то я не уверен, кто победит в этой битве слона с китом.
И дело совсем не в потраченном времени. Выработка любого навыка, каким бы rocket science на первый взгляд он ни казался, осуществляется путем повторения цикла “смотрю — пишу”. (на самом деле цикл чуть сложнее и мы детально рассмотрим его в следующих статьях). Человек, который нашел уродливое решение задачи и воспользовался им — не просто тратит время зря. Он формирует у себя на задворках мозга зарубку о том что вот такая-то задача решается вот таким-то кодом. В дополнение к этому его вера в то, что почти любую проблему можно решить Гуглом крепнет и ширится. Наверняка все из нас встречались с программистами, которые вроде бы способны решать реальные задачи (до поры до времени), но их код представляет собой мешанину из разных стилей, парадигм, а иногда даже и отступов. Более того, они при попытке указать на это недоумённо и совершенно искренне говорят: “а что тут такого, я всегда так делал, всё же работает”. И искренне считают, что вы придираетесь.
Практика и обратная связь
Не верьте студентам. Они кивают головами, что все понятно и они правда в это верят. Любую базу, на которую вы рассчитываете опираться в дальнейшем проверяйте минимум два раза в двух разных домашних заданиях — один раз “по горячим следам”, второй раз для закрепления материала (в среднем через две-три недели). Будьте готовы к тому, что вам прийдется повторять уже объясненное еще раз — наличие видеозаписей и прочих подобных штук сильно облегчит Ваши страдания.
Я не верю в автоматизированные тесты при проверке домашних заданий студентов на начинающем уровне обучения. Когда вам доверяют по-сути еще неоперившихся птенцов — ваша задача в максимально короткие сроки отучить их писать лажу. Лажа многолика. Она может притаиться в именовании переменных. Она может спрятаться за одной большой функцией, которая делает все. Она может прикинуться красивым трюком, который нравится студенту, но чреват реальными проблемами в будущем (Пример: одно из заданий на базовом курсе — операция flatten над массивом — превратить массив содержащий массивы произвольной вложенности в плоский массив — и в качестве входных данных используются числа и строки. Каждый год я вижу решение arr.toString().split(‘,’). За такой код надо бить по рукам как можно раньше, приучая людей логически мыслить, находить изъяны в своей логике и подбирать контрпримеры. Автоматизированные тесты эффективно скрывают за видимой успешностью проблемы студента с написанием поддерживаемого и управляемого кода
Я не верю в peer-review работ (когда одни студенты оценивают или хотя бы просматривают чужие работы). Если вы учите людей JavaScript — то у них в голове еще нет правильных и адекватных паттернов написания кода. Любые же ваши слова о том, как должно быть сделано задание, будут извращены до неузнаваемости — и не со зла,а просто в силу особенностей восприятия одних и тех же букв разными людьми.
P.S.
Если вы ощутили некую фрагментарность этой статьи — знайте, вам не показалось. Она писалась в разные временами и порой мне даже кажется что разным мной. Сейчас я занимаюсь тем, что собираю из Evernote, ЖЖ, пары блокнотов и одной тетради свои мысли в одну кучу и самым ценным делюсь с Вами. Я смотрю на некоторые из них, и понимаю, что сам с собой не согласен — боже, мне жалко моих студентов, которых я учил 10 лет назад. И я приятно удивлен, что из некоторых из них выросли действительно крутые специалисты.
Помните, что направление этой серии статей задаете Вы, поэтому я буду Вам благодарен, если вы поставите лайк — тогда я буду уверен, что тема интересна и стоит ее продолжать — и напишете в комментариях волнующие Вас вопросы — это поможет мне со следующими частями.
Учите и учитесь. Становитесь круче.
