В Makers Academy мы обучаем студентов процессу изучения Ruby, Sinatra, Rails, JavaScript, jQuery и Angular в течение 12 недель. Возраст учащихся варьируется от 18 до 63 лет, хотя большинству в возрасте от 20 до 30 лет, они уже имеют высшее образование (часто по гуманитарным дисциплинам) и проработали более 5 лет на рабочем месте, занимаясь продажами, маркетингом, дизайном, менеджментом и т. Д. другая относительно нетехническая роль.

Большинство студентов также почти не имели опыта программирования перед подготовкой к собеседованию и процессом отбора, который им необходимо пройти, чтобы пройти курс. Ниже приводится краткое изложение выступлений, которые я провел в London Ruby Users Group и Future Learn, о том, что делает 12-недельный интенсивный учебный курс успешным, и с какими проблемами сталкиваются студенты при изучении Ruby и JavaScript.

Makers Academy тщательно отбирает кандидатов для тех, кто, по нашему мнению, может справиться с суровостью курса. В каждом соискателе мы смотрим на базовые способности к программированию, коммуникативные навыки и умение сотрудничать. Каждые шесть недель мы начинаем новую группу из 25+ студентов, «когорту», ​​которую мы тщательно отбираем из 100 заявок, которые мы получаем каждый месяц.

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

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

Мы умоляем студентов поделиться своими проблемами и опасениями (и подробными трассировками стека) в нашем внутреннем приложении для обмена мгновенными сообщениями (Slack), на нашей доске внутренних проблем (Slack-overflow) и на самом StackOverflow, но студенты, кажется, странно неохотно делятся своей борьбой.

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

В рамках процесса преодоления некоторых из этих барьеров мы предлагаем студентам участвовать в «стендапе» дважды в день, который основан на «стендапах», практикуемых разработчиками в промышленности. В этих стендапах каждый ученик по очереди объясняет, над чем они работают, на чем они застряли (если вообще что-то) и свои планы на следующие несколько часов. Стенд-апы проводятся «байтами» по 8–12 студентов, под рукой есть тренер Makers Academy, чтобы помочь делу пройти гладко. Сразу после этого тренер проведет быстрое секционное занятие, если возникнет какое-то общее недоразумение или проблема, которые можно эффективно устранить на доске или на компьютере.

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

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

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

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

  • A. Разработка через тестирование (TDD)
  • Б. Решение технических проблем
  • C. Эффективное обращение за технической помощью
  • D. Логистика
  • E. Парное программирование

Давайте рассмотрим каждый из них по очереди.

A. Разработка через тестирование (TDD)

Проблемы с TDD знакомы большинству разработчиков. Разработка кода с помощью процесса TDD противоречит обычной практике простого добавления решений в код. Студентам часто может потребоваться несколько недель, чтобы «щелкнуть» по тому, что в тестах указаны «входные данные» и «выходные данные» компонента программного обеспечения. Многие упорно пытаются сначала решить проблему того, как будет работать реализация компонента, и в результате получают запутанные тесты, привязанные к особенностям этой реализации. Несмотря на репутацию Makers Academy, предоставляющей лучших младших разработчиков, многие студенты постоянно задаются вопросом, может ли методология, которую мы им показываем, быть правильным способом разработки программного обеспечения. Ответ, конечно, заключается в том, что тщательная и правильная разработка тестов на начальном этапе может занять больше времени, но в конечном итоге приносит свои плоды, поскольку системы становятся все более и более сложными, а ручное тестирование всего становится непомерно дорогостоящим.

Б. Решение технических проблем

Проблема, с которой сталкиваются новички при использовании TDD, - это, возможно, лишь верхушка айсберга решения более глубоких проблем. Многие студенты, кажется, работают, полагая, что проблемы следует решать с помощью грубых умственных способностей; прочитав соответствующие разделы учебника или учебного пособия, они должны уметь «решать» проблему с помощью рассуждений или просто тяжелых размышлений; и что если они не могут этого сделать, значит, они потерпели неудачу. Похоже, это один из факторов, объясняющих, почему буткемп такой эмоционально тяжелый. Мы настойчиво поддерживаем процесс обхода проблемы, определяя входы и выходы через BDD / TDD; решение простых угловых случаев проблемы путем жесткого кодирования решений, которые проверяют разумность нашего подхода и настройки; проверка предположений путем перехода между рассуждениями и экспериментами.

C. Эффективное обращение за технической помощью

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

  1. Слишком долго бороться с проблемой в одиночку - более 20 минут, скорее всего, плохо, если не будет достигнут постепенный прогресс
  2. Никому не рассказывать о проблеме из-за боязни показаться некомпетентным
  3. Не использовать процесс совместного открытия со своим партнером в паре, когда они обсуждают и исследуют, скажем, все слова, которые они не понимают, из сообщения об ошибке или из документов / руководств.
  4. Просить о помощи неспецифическим образом, на форуме 121, например, направить Slack одному тренеру
  5. Предпочитаете задавать вопросы только внутри Makers Academy из-за боязни выглядеть глупо на публичном форуме, таком как StackOverflow.
  6. Не связывать свой вопрос с конкретным воспроизводимым кодом на Github и т. Д.
  7. Не отображаются точные сообщения об ошибках

Лично я считаю, что части этого, связанные со страхом и смущением, немного трудно понять с логической точки зрения. По моему (и многим другим) опыту, публикация в Stack Overflow позволяет получить ответы от членов сообществ за считанные минуты. В любой ситуации, когда вы просите одного человека о помощи в чем-то, вы возлагаете на него относительно большую нагрузку, и вы также рискуете, что не получите никакой помощи по этой проблеме, пока этот человек не освободится. Если ваша цель состоит в том, чтобы получить ответ на свой вопрос как можно быстрее, то, по логике, большую часть времени вы должны публиковать сообщения на общедоступном форуме, таком как StackOverflow, и сочетать это с размещением этой ссылки в общем чате с вашими коллегами. Мы пытаемся обучать студентов через все эти элементы обращения за помощью и пытаемся объяснить, что, хотя студенты могут подумать: «О, это простая проблема, которую нужно исправить за секунду»; на самом деле для ученика важно не просто получить ответ на свой вопрос, но и научиться лучше обращаться с просьбой о помощи.

Конечно, это может быть сложно для студентов, которые думают, что цель тренеров - передавать фрагменты знаний, и что если бы только студенты могли регулярно получать четкие ответы на все вопросы, возникающие при решении задач курса. что они волшебным образом станут разработчиками. Студенты могут интерпретировать нашу позицию как «не получают должного качества», но в то время как мы могли бы предоставить студентам личного наставника по 8 часов в день; это непрактично из-за затрат и вполне может помешать студенту в процессе попытки стать компетентным независимым разработчиком.

D. Логистика

Еще одна проблема, с которой сталкиваются некоторые студенты, особенно младшие, - это логистика. В первый день в Makers Academy главный совет, который я даю для достижения успеха, - это просто… «будь здесь». Мы регулярно видим, что студенты, которые не приходят вовремя, или те, которые пропускают значительные пропуски, - это те, кто испытывает наибольшие трудности. Конечно, жизнь случается со всеми нами, но простая уловка заключается в том, что если вы стремитесь присутствовать со своим байтом во время стендапа в 9 утра, то постарайтесь попасть в офис в 8:30 утра или, возможно, даже в 8 утра, а так даже если у вас есть проблемы с транспортом, вы можете прийти вовремя. Убедиться, что вы присутствуете на всех мероприятиях и частях курса, очень важно для успеха; и если вы вкладываете значительную сумму в свое образование, как это делают студенты Makers Academy, то вы хотите извлечь из полученного опыта все возможное.

E. Парное программирование

Посещаемость и своевременность также имеют решающее значение с точки зрения парного программирования. Иногда студенты сомневаются в ценности, которую они получают от Makers Academy, если у них не всегда под рукой есть тренер, который ответит на все вопросы. И ответ в том, что вы получаете когорту других студентов, которых мы сочли умными и целеустремленными. Конечно, вы можете заниматься самостоятельно дома или со случайными друзьями, но как часто они доступны? Учеба в составе преданной группы - ключевая ценность опыта Makers Academy. Конечно, многим ученикам нужно время, чтобы увидеть преимущества настоящего парного программирования; не просто «бок о бок», когда два человека работают над связанными проблемами, но настоящее парное программирование, когда обе стороны полностью вовлечены в решение одной и той же проблемы кодирования вместе. Конечно, объединение в пары - это еще один навык сам по себе, и ученики часто падают из вагона объединения, говоря такие вещи, как «Я лучше работаю самостоятельно», «Я слишком медлительный» , «Я замедляюсь» и т. д. Я подчеркиваю учащимся, что ключевым аспектом создания пары является компромисс. Да, один человек всегда будет несколько «медленнее», чем другой; но именно компромисс против вашего собственного предпочтительного рабочего процесса является частью силы объединения и частью того, что делает вас хорошим командным игроком, и именно поэтому выпускники Makers так удобны для трудоустройства.

Таким образом, снижение скорости при объединении дает три преимущества:

  1. Вы практикуете компромисс - станьте лучшим «парным» и командным игроком.
  2. Вы обсуждаете проблемы с кем-то, что из-за эмоционального подтекста, связанного с социальным взаимодействием, означает, что вы сохраните память об этой технике / материале намного дольше.
  3. Гораздо веселее, чем сидеть целый день в одиночестве!

Вот цитата одного студента из первой половины курса:

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

Конечно, иногда в паре могут быть ужасные личностные столкновения. Мы поощряем беспорядочные связи со студентами, меняющими партнеров каждый день. Частично это делается для того, чтобы попрактиковаться в работе с как можно большим количеством разных людей, но также частично для того, чтобы не застрять в «плохой» паре слишком долго. Мы можем многому научиться у кого-то, с кем сложно работать в паре, но это также может стать настоящим угнетателем, который негативно влияет на внутреннюю мотивацию, если продолжается слишком долго. Ежедневное изменение кодовой базы связано с накладными расходами, на которые студенты часто жалуются; на что мы отвечаем, что очень важно практиковаться в освоении разных кодовых баз каждый день, а также, если вы работали над одним и тем же проектом, и один человек опережает другого, переключитесь на менее развитую кодовую базу и работайте, помогая ваша пара через материал, который вы уже рассмотрели, чтобы закрепить это в своем уме. Как мы утверждаем, цель не в том, чтобы добраться до «конца материала»; нужно как можно больше практиковать подробный процесс совместной работы.

Помимо пяти основных проблем, описанных выше, есть еще три связанных проблемы:

  1. Сложность убивает
  2. Переход с Ruby на JavaScript
  3. Спортивные повторы

В заключение давайте кратко рассмотрим каждый из них:

1. Сложность убивает

С мыслью «я должен дойти до конца материала» есть еще одна проблема для некоторых студентов, которые, кажется, думают: «Я хочу быть профессионалом, поэтому я должен действовать быстро, усложнять задачу»; что кажется особенно контрпродуктивным в контексте программирования, где сложность быстро убивает программные проекты. Мы делаем все, что в наших силах, чтобы отговорить студентов от этого заблуждения, сосредотачиваясь на концепциях MVP (минимально жизнеспособный продукт) и MVp (минимально жизнеспособный прототип), и что при решении каждой проблемы речь идет о движении крошечными шагами, разрезая вещи на части. мельчайшие компоненты, которые подтвердят, что техника, или продемонстрируют, что часть ценности может быть доставлена ​​заказчику.

2. Переход с Ruby на JavaScript

Мы начинаем наших студентов с Ruby и проводим их через Интернет и базы данных на Ruby, прежде чем переключиться на JavaScript, а затем перейдем к таким фреймворкам, как Rails и Angular. Ruby кажется хорошей отправной точкой, потому что сообщения об ошибках легче понять, чем JavaScript, а язык более лаконичен. Может быть полезно начать с JavaScript, который позволяет студентам немедленно связывать то, что они делают, с веб-приложениями, которые они хотят разработать, однако часто бывает «щелчок» понимания, который исходит от просмотра программирования на более чем одном языке - « click », который возникает из-за того, что некоторые из одинаковых концепций, таких как поток управления и вызовы методов, отображаются на нескольких языках. Итак, хотя мы рассматривали возможность перехода на «весь JavaScript», как это делали некоторые учебные курсы; мы по-прежнему любим сочетание Ruby / JavaScript.

3. Спортивные повторы

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

Вывод

Таким образом, только половина задачи в Makers Academy - это научиться программировать на Ruby и JavaScript. Остальное - это овладение более общими навыками декомпозиции проблемы, сосредоточения внимания, сотрудничества, командной работы, логистики, самостоятельного обучения и преодоления страха и смущения из-за того, что вы не в себе. Мы часто говорим студентам, что весь фокус в том, чтобы научиться чувствовать себя не в своей тарелке. Это не помогает волшебным образом, и, честно говоря, кажется, что волшебной пилюли не существует; нет волшебного способа научиться продолжать изучать все, что вам нужно, чтобы стать успешным разработчиком; но мы создаем настоящий арсенал в битве, чтобы помочь новичкам в кратчайшие сроки стать готовыми к работе разработчиками.

Первоначально опубликовано на сайте blog.makersacademy.com 12 октября 2015 г.