Недавно я закончил коучинг нескольких инженеров по разработке Node.js в рамках шестинедельной коучинговой программы Blue Harvest. Я ни в коем случае не эксперт в вопросах коучинга, обучения, тренинга или как вы хотите это называть (в этой статье я буду использовать эти термины как синонимы), но этот последний опыт побудил меня поделиться одной-двумя мыслью. об этом.
Независимо от контекста (будь то Blue Harvest, Hack Your Future, где я давал воскресные уроки, или на работе, где я трачу как можно больше времени на наставничество с младшими), я заметил одну вещь: преподавание и изучение программирования (или язык программирования, в частности) - длительный, но относительно простой процесс. Есть только одно правило, то же самое, что и при изучении естественных языков: практика.
Однако научить и научиться тому, как стать хорошим программистом, - гораздо более сложная задача.
Что я имею в виду под «хорошим программистом»
Существует множество определений и критериев того, что такое хороший программист, но эта цитата из Мартина Фаулера очень хорошо подводит итог для меня:
«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям ».
Роберт С. Мартин оттачивал ту же идею на протяжении всех своих книг и говорит о чистом коде: быть профессиональным инженером-программистом - это не столько управление сложностью на машинном уровне (т.е. просто заставить код работать), сколько о работа с этим на человеческом уровне (т.е. написание поддерживаемого и предсказуемого кода, о котором легко рассуждать).
О том, что все это означает, уже написано много теории (если вы не поняли намек, прочтите материал Фаулера и дяди Боба), но чтобы освоить это, применить на практике, просто следование бесчисленному набору руководящих принципов и принципов просто не годится. Вот тут-то и приходит на помощь обучение.
Что такое обучающий код и зачем он нам нужен
Зная то, чего ты не знаешь
Предпочтительно - и в некоторой степени даже необходимо - предпринять интеллектуальное путешествие, чтобы научиться «писать код, который может понять компьютер» в одиночку.
Как наставник, я считаю, что моя роль в этой области должна быть в основном ролью куратора или ограждения: я буду ориентировать своих студентов или подопечных на ресурсы (книги, статьи, учебные пособия и т. Д.) И концепции, которые им необходимо получить. началось или отклеилось. Я помогу им не тратить время зря и не сбиться с пути, рассказав им о том, чего они не знают. Но очень важно, чтобы они взяли на себя тяжелую работу, пришли к решениям самостоятельно и наслаждались этими очень важными, очень личными моментами ага.
Это дает мне дополнительное преимущество: я могу сосредоточиться на том, что является ключевым, а для чего письменные и видеоматериалы не подходят: формирование правильного мышления.
«Вы не станете мастером программного обеспечения, изучив список эвристик. Профессионализм и мастерство проистекают из ценностей, которые определяют дисциплину ».
- Роберт С. Мартин
Конечно, эвристика - множество акронимических парадигм (ООП, DDD, TDD, BDD, AOP и т. Д.), Паттерны проектирования, принципы и лучшие практики для конкретных языков - прокладывают путь. Но суть всего этого лежит в более фундаментальных ментальных конструкциях, требующих развития дискурсивного подхода.
«Все, что хорошо задумано, ясно сказано»
В первую очередь, хороший программист - это методичное решение концептуальных проблем. Большая часть этого происходит вне среды IDE: чистый код - это побочный продукт ясного мышления, и его написание должно казаться легким.
Передача этой умственной дисциплины требует от учителя больше вопросов, чем ответов, в духе Сократа. В то время как проблема изучения эвристики заключается в переваривании большого объема информации, формирование определенного образа мышления может возникнуть только в результате оспаривания точки зрения и подхода к проблемам.
Когда я вижу, что подопечный борется с проблемой или придумывает трудный для чтения код (что довольно часто бывает одним и тем же), я начинаю с того, что тяну за нить их рассуждений, прося их описать, шаг за шагом. шаг, чего они пытаются достичь. Цель состоит в том, чтобы они мысленно или на бумаге изложили составные части как проблемы, так и решения наиболее простым из возможных способов.
Получить четкое представление о поставленной задаче обычно не так уж сложно, если вы сосредоточитесь на создании решения, состоящего из очень простых, очень глупых компонентов, что в конечном итоге приведет к очень простым классам, функциям, циклам. Выполнение этого посредством обсуждения делает этот процесс еще проще, поскольку ограничения вербального общения, как правило, обеспечивают определенную степень упрощения.
К сожалению, это слишком часто упускается из виду, особенно молодыми разработчиками, которые «просто хотят, чтобы это работало», а затем «очистить его». Если я могу убедить вас только в одном, пусть будет так: воздержитесь от написания кода, пока вы не создадите ясную и простую картину его общей структуры. По мере роста этой привычки вы не только будете решать проблемы все быстрее и быстрее, но и другие разработчики будут понимать ваши решения с меньшими усилиями.
Эти обсуждения с моими подопечными и учениками также помогают мне улучшить свои навыки программирования и прояснить мои собственные взгляды на программирование. На ум приходит известная цитата Ричарда Фейнмана: «Если вы не можете объяснить что-то простым языком, вы этого не понимаете». Я не знаю, сделало ли меня обучение программированию «хорошим» программистом, но оно определенно делает меня намного лучше. И я могу только порекомендовать как можно чаще пытаться объяснить или просто обсудить то, что вы изучаете и знаете, кому-то еще, даже если вы только начали программировать.
На практике
Что означает правильное мышление для любого человека, полностью зависит от его конкретного происхождения и опыта. Само собой разумеется, что для выпускника CS, только что закончившего университет, и для самоучки с несколькими годами профессионального опыта потребуются совершенно разные подходы. Наставник и подопечный должны выяснить потребности подопечного вместе, итеративно, с помощью коротких циклов обратной связи и открытых обсуждений.
В Blue Harvest мы пытались достичь такой гибкости, предлагая набор руководящих принципов, а не строгий план для нашей программы коучинга. Что-то достаточно гибкое, чтобы мы могли быстро исследовать новые возможности и адаптировать формат наших коучинговых сессий к инженерам, которые к ним присоединятся. И - что, может быть, более важно: что-то сосредоточенное на реальной практике и реальных инженерных проблемах.
Учиться и учить на практике
Еще раз, коучинг должен быть направлен на преодоление разрыва между эвристиками и их применением. Например, абстрактное знание принципов SOLID практически бессмысленно без целостного и инстинктивного понимания того, как применять их к конкретным проблемам.
Чтобы решить эту проблему, мы построили нашу программу коучинга на основе реального проекта. Вместо того, чтобы придумывать собственное, мы выбрали пример приложения realworld.io. В нем достаточно движущихся частей, чтобы предлагать широкий спектр проблем и поднимать некоторые фундаментальные и общие вопросы, но требования и функции очень просты и могут отойти на второй план.
На самом деле цель заключалась не в том, чтобы создать работающее приложение, а в том, чтобы иметь повод для практики, анализа кода, парного программирования и неформальных бесед о преобразовании абстрактных принципов в строки кода очень ощутимым образом.
Экономьте время с хорошими учебными материалами
При любой возможности мы ориентировали наших тренеров на образовательные ресурсы, чтобы избавиться от эвристики и у нас было время сосредоточиться на остальном во время занятий.
Группе не требовалось фактическое представление синтаксиса, поскольку все они имели опыт работы с другим языком и хотя бы однажды попробовали свои силы в JavaScript. Но если вам действительно нужно официальное введение в язык, для начала работы с вашей первой программой будет достаточно шпаргалок и видеороликов, подобных тем, что из серии Дерек Банас Учитесь в одном видео. Держите их под рукой и начинайте взламывать. Мастерство придет позже.
Что касается библиотек и фреймворков, мы кратко представим их, сделав обзор их философии, а затем обратимся к их документации, не вдаваясь в подробные описания их идиоматического использования. Изучение новых библиотек, фреймворков и API на лету - важная часть работы. Так что, если отсутствие руководства в этой области становится проблемой, имеет больше смысла учить, как эффективно разбирать документы в целом, чем кропотливое знакомство студентов с той или иной конкретной библиотекой.
Уроки и дискуссии
Как правило, короткие беседы и / или чаты, иногда с живым кодированием, на общие темы (например, архитектура микросервисов, базы данных, безопасность, языковые варианты использования и т. Д.) Либо начинают день, либо завершают его. Отнюдь не чисто теоретические, они должны были пролить свет на то, почему и как код, который мы писали или собирались написать.
Некоторые другие области, такие как функциональное программирование, лучшие практики git, модульное, интеграционное и функциональное тестирование и т. Д., Также были в меню, но мы решили отказаться от них, поскольку участники просили обсудить другие конкретные темы и получить особенное удовольствие. время, потраченное на кодирование (поэтому мы позаботились о том, чтобы их было достаточно).
Научиться быть хорошим программистом - это не то, чего можно просто достичь и с этим покончить. Это тоже не то, что вы можете сделать в одиночку. Надеюсь, мне удалось убедить вас, что простые технические знания - это только часть истории и что я вдохновил вас на поиски наставников и становление ими.
