Что я понял за полтора года преподавания

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

Будьте аккуратнее с новыми терминами

Если вы объясняете новичкам незнакомые термины, то это стоит делать понятиями, которые им уже известны. Следовать этому правилу труднее, чем кажется.

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

Но как только вы начнёте объяснять это другим людям, у них вполне оправданно появится куча вопросов. Что за маржины, что значит «схлопываются», как сбрасывать флоты, зачем они нужны, откуда отступы, зачем они там?

Чтобы объяснить эти тонкости, надо использовать уже знакомые понятия. Потому что иначе вы не только не объясните, что хотели, но и отобьёте интерес к теме. Никому не хочется разбираться в непонятной фигне, по крайней мере — в чересчур непонятной.

Поэтому объяснение нового термина должно:

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

Избегайте путаницы

Если у термина есть синонимы (флот ⇔ плавающий элемент), надо это пояснить на старте.

Можно также объяснить, почему эти термины взаимозаменяемы. (Флот переводится, как плавающий, а используется такой элемент, чтобы его «обтекал» текст. Поэтому он как бы плавающий, это такой грубый перевод.)

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

Автоматизируйте всё, что можно

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

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

Нетипичные ошибки более редкие. Они особенно важны, потому что как бы ставят под вопрос рациональность технологии. На них отвечать на них надо ещё более полно.

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

Объясняйте на примерах

Объяснение с примерами понятнее. Я пробовал объяснять и абстрактно, и на примерах — на примерах лучше.

Абстракция — ресурсозатратная штука. Даже чтобы представить что‑то уже знакомое, требуется внимание и сосредоточенность. Чтобы представить какое‑то новое понятие, ресурсов потребуется больше.

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

Делайте перерывы во время занятия

Во время объяснений стоит делать небольшие перерывы.

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

Ученикам перерыв даёт время передохнуть и восстановить внимание. Вам — перевести дыхание.

Стимулируйте обратную связь

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

Если вопрос задан расплывчато, и вам непонятно, как ответить, просто уточните, что имелось в виду. И, если в чём‑то сомневаетесь, не стесняйтесь гуглить прямо во время занятия. Я так и говорю: «не уверен, давайте прямо сейчас и загуглим».

Пейте воду во время занятия

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

Пить воду ещё можно, если чувствуете, что плывёте или сильно волнуетесь. Это работает как микротаймаут: пока пьёте воду, можно перевести дух, сформулировать мысль и продолжить.

Дозируйте время на ревью

Любую работу стоит дозировать и разбивать на кусочки. Если два часа подряд ревьюить домашки, то к концу вы будете чувствовать большую усталость, чем если бы чередовали ревью с задачами по другим проектам.

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

Получайте пользу

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

Если есть возможность заниматься менторством, то пробуйте. Вы глубже поймёте то, что знаете, научитесь объяснять сложные понятия и сможете помочь кому‑то разобраться с новыми для них вещами.

Как я избавился от иррационального страха потерять работу

Это сложный для меня пост, потому что он получился довольно личным. Но мне кажется, что его стоит опубликовать, потому что кому‑то мой опыт может быть полезен.

У меня была проблема, с которой я жил несколько лет и не мог разобраться. Это был страх однажды потерять работу и никогда её больше не найти.

«Тоже мне проблема!»

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

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

Эта же проблема мешала работать. Из‑за страха я мог реагировать на критику реактивно, быстрее уставал и не мог нормально отдохнуть. Было ощущение, что мозг пытается майнить бетховенов на фоне, пока я что‑то делаю. Короче, меня это достало и я решил пойти к психологу.

Первый сеанс — всегда знакомство

Не скажу, что с первого раза всё стало понятно, и проблема исчезла. Нет, конечно. Первый сеанс — это знакомство: мало кто просто так откроется незнакомому человеку.

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

Придётся делать «домашку»

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

На первом сеансе среди прочих мы обозначили причину, которая мне казалась главной и основной — перфекционизм. Ну типа хочется сделать всё идеально, расстраиваешься, когда не можешь. Угу, окей. А почему? Ну эм, это…

Первый результат — не финальный

Будьте готовы, что нельзя будет просто что‑то откопать и думать, что проблема решена. Дальше предстоит понять, откуда взялось то, что высплыло, а потом — откуда‑то, что всплывёт в следующий раз.

Это не значит, что копание не закончится и нельзя радоваться прогрессу. Наоборот — радоваться надо, не надо думать, что всё будет быстро и просто.

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

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

Решение

Возможное решение проблемы состоит из 4 частей.

  • Осознать, что ответственности меньше, чем кажется. Не всё на свете зависит от моих действий, есть куча внешних факторов, которые я не могу контролировать.
  • Собрать обратную связь от людей, мнение которых я ценю. По этой обратной связи определить действительный уровень квалификации и работать с этим: поднимать уровень до приемлемого, если он таким не кажется.
  • Работать с ожиданиями других людей, чтобы не беспокоиться, что меня неправильно поняли.
  • Больше ценить себя. Не загонять себя в рамки «должен», «обязан», «надо». Уделять больше внимания таким штукам, как «хочу» и «неплохо бы».

Первый пункт не значит, что надо наплевательски относиться к работе. Это бы противоречило пункту 2 — ведь своё мнение как специалиста о себе мне тоже ценно. Последний пункт меньше относится к работе и больше к образу жизни в целом.

«И чо, работает?»

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

«А нафиг ты всё это рассказываешь?»

Я тоже вначале думал, кому какое дело. Но пришёл один парень в телеграм и сказал правильную мысль:

Диалог из телеграма

Вот я и написал.

Документация

Польза документации по проекту не в только том, чтобы она описывала «что это за хрень», а ещё и «почему эта хрень сделана вот так».

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

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

Как мы делали «Фронтенд — это не больно!»

«Фронтенд — это не больно!» — длинная статья, цель которой помочь разработчикам научиться справляться с рутиной и получать удовольствие от работы. В этой заметке я расскажу, как появилась идея и почему этот проект для меня был важен.

Предпосылки

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

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

Этого казалось мало, потому что теперь я очутился на другой стороне: видел других фронтендеров с теми же проблемами. У меня был опыт того, как начать работать без напряга. Я хотел им поделиться, но не знал как.

Идея

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

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

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

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

Тогда я написал Андрею и предложил вместе сделать серию статей. Андрей же предложил сделать нечто вроде пособия. Получилось — вот это.

Запуск, результаты и планы

Статья разлетелась по соцсетям, о ней написали Форвеб и Вебстандарты, обсудили в паре подскастов. Судя по всему, разработчикам она тоже понравилась. Мы даже получили несколько писем с благодарностями, надеемся кому‑то действительно помогло.

Сейчас у нас в планах сделать более весёлое дополнение к проекту. Если вам интересно поучаствовать, то заходите в чат в Телеграме, там уже есть наработки :–)

Заказ доставки

Это рубрика «фронтендер переписывает хреновые таблички».

Вот на столе инструкция к заказу еды из КФЦ. Когда её читаешь, взгляд спотыкается.

Инструкция до

А вот я её переписал:

Инструкция после

Кажется, что изменился только вид у первых двух глаголов. Но смысл тоже поменялся.

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

Во втором варианте я поменял вид глаголов на совершенный, и ненужный повтор исчез.

А спонсор этой заметки — совет Максима Ильяхова об упорядочивании списков.

Раньше ↓