Почему совместное кодирование — лучший способ карьерного роста

Делать первые шаги в программировании — все равно что учить иностранный язык. Сначала синтаксис не имеет смысла, лексика незнакома, все выглядит и звучит непонятно. Если вы чем-то похожи на меня, когда я начинал, беглость кажется невозможной.

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

Для меня этим сообществом были Founders and Coders, бесплатный учебный курс по JavaScript, который помог мне сменить карьеру с копирайтинга на программирование. Даже сейчас, менее чем через год после окончания курса, я с трудом могу поверить, что мне платят за разработку программного обеспечения.

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

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

Идеальное сочетание

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

Теоретически это было просто. На практике не так уж и много.

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

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

Парное программирование — невероятно быстрый способ обучения. Магия метода — как только вы преодолеете первоначальную неловкость — заключается в том, что он дает немедленные результаты. Некоторые петли обратной связи, такие как пузыри на фондовом рынке, могут занять часы, дни или даже месяцы, чтобы произвести коррекцию. Парное программирование занимает минуты, если не секунды. Если вы неправильно расставите точку с запятой, две пары глаз заметят ошибку быстрее, чем одна. Нужно искать в StackOverflow подсказки о мошенническом сообщении об ошибке? Вы и ваш партнер можете читать разные темы, вдвое сокращая время, необходимое для поиска ответа.

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

«Все блестящие умы работают над одним и тем же, в одно и то же время, в одном месте, на одном компьютере».

— Вуди Зуилл, Agile Coach и тренер по групповому программированию

Хотя это может показаться неэффективным способом работы, сторонники группового программирования, такие как Вуди Зуилл, говорят, что на самом деле он может сэкономить время, устраняя необходимость в индивидуальном просмотре кода, потому что все просматривают код в режиме реального времени по мере его написания. Помимо продуктивности, я думаю, что моббинг — это отличный способ узнать не только о коде, но и о том, как другие люди подходят к решению проблем. Если парное программирование удваивает количество точек зрения, с которыми вы сталкиваетесь, групповое программирование дает еще больше информации.

Это не значит, что спаривание или даже моббинг — это просто. Что-то, с чем я сначала боролся, заключалось в том, чтобы отложить свое эго в сторону, чтобы задавать вопросы, которые, как мне казалось, могут показаться глупыми. В таких ситуациях полезно помнить, что у вашего партнера могут быть одни и те же мысли, особенно если вы оба только начинаете.

Если вы обнаружите, что работаете в паре с кем-то более старшим, возможно, на работе, не бойтесь ковыряться в их мозгах и впечатлять их своей любознательностью. Даже тот, кто лишь немного опережает вас, может думать о вещах, которые не пришли бы в голову кому-то более старшему. У некоторых из моих любимых парных программистов всего на несколько месяцев больше опыта, чем у меня, но они, кажется, всегда точно знают, какие ошибки я собираюсь совершить и как направить меня в правильном направлении. Когда эти разработчики говорят, что глупых вопросов не бывает, они действительно имеют это в виду. Лучшие программисты пар говорят свободно, без необходимости выглядеть фантастически или бояться выглядеть глупо.

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

Ресурсы и дополнительная литература

• «Роли парного программирования», Джордан Поултон, GitHub
• «Дружба, которая сделала Google огромным», Джеймс Сомерс, The New Yorker
• «Программирование мобов: подход всей команды», Вуди Зуилл, YouTube

Инженерная эмпатия

Когда я начал изучать JavaScript, мой код был очень похож на пол в моей спальне: я позволял ему становиться все более и более беспорядочным, пока у меня не оставалось другого выбора, кроме как привести его в порядок. Пока мой веб-браузер мог понять это, мне было все равно, как это выглядело.

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

Empathy может быть самым недооцененным инструментом в арсенале любого разработчика. Это причина, по которой IDEO ставит исследования пользователей в центр своего процесса проектирования, и почему Etsy просит своих дизайнеров и менеджеров по продуктам выполнять инженерную ротацию. Эмпатия возникает, когда у нас есть возможность увидеть, как наша работа влияет на других людей. Неудивительно, что совместное кодирование — отличный способ его создать.

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

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

«Идеальная реализация неправильной спецификации ничего не стоит. По тому же принципу прекрасно сделанная библиотека без документации также чертовски бесполезна. Если ваше программное обеспечение решает не ту проблему или никто не может понять, как его использовать, значит, происходит что-то очень плохое».

— Том Престон-Вернер, основатель GitHub

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

Ресурсы и дополнительная литература

• «Об эмпатии и запросах на вытягивание», Slack Engineering, Medium
• «Разработка на основе чтения», Том Престон-Вернер, GitHub
• «Чему научился Google, пытаясь создать идеальную команду», Чарльз Дахигг, журнал The New York Times.

Гибкое достижение

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

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

О Agile написаны целые книги, но вот краткое изложение основных концепций:

• Команда разработчиков продукта разбивает большие объемы работы на небольшие блоки, называемые «пользовательские истории», устанавливает для них приоритеты и выполняет их в двухнедельных циклах, называемых «спринтами».
• Пока проект продолжается, циклы повторяются, и новые требования к продукту добавляются в список невыполненных задач для будущих спринтов.
• Команда проводит ежедневные встречи, чтобы обсудить свой прогресс и устранить любые препятствия.
• Этот процесс является одновременно инкрементным и итеративным: программное обеспечение создается и поставляется по частям и совершенствуется в последовательных спринтах.

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

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

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

Применение всех этих Agile-принципов на практике может оказаться сложной задачей, особенно если никто в команде не привык к такому способу работы. В Founders and Coders большинству студентов требуется некоторое время, чтобы выработать привычку проводить ежедневные стендапы. Однако после 18 недель проектной практики вы обнаружите, что ваши процессы и навыки общения значительно улучшились. К тому времени, когда вы приступаете к работе с вашим первым клиентом, у вас уже сформировалась гораздо более четкая ментальная модель того, как подходить к созданию полнофункционального веб-приложения в команде.

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

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

Ресурсы и дополнительная литература

• «Что такое Agile?», Стив Деннинг, Forbes.
• «Внедрение Agile», Даррелл К. Ригби, Джефф Сазерленд, Хиротака Такеучи, Harvard Business Review.
• «Потрясающие возможности для первого пулл-реквеста», Шмавон Газанчян, Deloitte Digital

Рекомендации по удаленному совместному кодированию

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

В этом духе, вот несколько инструментов, которые могут помочь вам и вашей команде совместно писать код на расстоянии:

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