Кодер-одиночка имеет много преимуществ. Работая в личной пещере вдали от всех отвлекающих факторов, одинокий программист может творить удивительные вещи: завоевать новый игровой движок, командовать цирком дронов или построить империю микросервисов.
Но что происходит, когда вы совсем один и сталкиваетесь с противником, с которым никогда раньше не сталкивались? Что, если вашему игровому движку требуется сложное физическое моделирование или трехмерное позиционное аудио, или что, если вы просто никогда раньше не использовали React или Redux, и вам просто нужно опытное руководство, которое покажет вам основы?
Что, если вы преследуете ошибку уже 3 часа, и все, что вам нужно показать, это разочарование, неуверенность в себе и, возможно, даже небольшой синдром ползучего самозванца?
Парное программирование может помочь.
Что такое парное программирование?
Парное программирование - это методология разработки программного обеспечения, которая работает как пилоты авиакомпаний: у вас есть капитан за штурвалом и штурман.
Но давайте оставим это обоснованным. Представьте, что вы отправляетесь в путешествие по пересеченной местности в порт доставки. У водителя есть клавиатура и мышь, а навигатор по пути дает полезные подсказки, корректировки курса или жемчужины мудрости.
Навигатор может даже время от времени брать на себя управление автомобилем. Иногда вам нужно увидеть что-то сделанное, прежде чем вы сможете понять, как это сделать.
Культура наставничества
Я твердо верю в создание команд разработчиков с глубоко укоренившейся культурой наставничества. Ни один разработчик не должен зацикливаться на проблеме более 10 или 20 минут. Если вы испытываете трудности, вы сможете обратиться за помощью и попросить о помощи.
В ваших командах следует всячески поощрять помощь и наставничество. Большинство культур команд разработчиков настроены на скорость призовых билетов во всем, и это может иметь сильный сдерживающий эффект, который блокирует сотрудничество товарищей по команде. Это последнее, чем вы хотите заниматься в своей команде. Прочтите Основное руководство по созданию сбалансированных команд разработчиков, чтобы узнать больше по этой теме.
Сопряжение стилей
Существует 2 общих стиля парного программирования, и оба действительны, хотя у меня есть предпочтение, как вы скоро увидите.
100% сопряжение
Некоторые команды разработчиков всегда работают в паре 100% времени. Члены команды работают в паре с партнерами, и всегда есть навигатор, наблюдающий за каждым нажатием клавиши.
Это отлично подходит для обратной связи, обмена знаниями и проверки кода в реальном времени. Однако после обсуждения культуры с членами 100% парных команд я решил не делать то же самое со своими командами.
Специальное соединение
Иногда партнеры по спариванию любят небольшое разнообразие. Они хотят немного побыть наедине с собой. Иногда, когда вы пишете код и идете по правильному пути и знаете, куда идете, вам просто нужно немного тишины, чтобы вы могли сосредоточиться и выполнить работу. Трудно войти в состояние потока, если кто-то постоянно читает через ваше плечо и говорит вам на ухо.
Вместо этого мне нравится объединяться в пары, когда я зацикливаюсь на чем-то, и мне просто нужен дополнительный набор глазных яблок, чтобы уловить то, что я слеп в этот момент. Иногда мне нужно просто объяснить это кому-то другому.
Каждый разработчик совершает глупые ошибки. Любой, кто говорит вам, что нет, - лжец. Нам никогда не должно быть стыдно просить о помощи. Я часто прошу о помощи, и делаю это большую часть своей жизни.
Когда вы чувствуете, что застряли, и не хотите терять еще час, бьясь головой о кирпичную стену, позовите помощь.
Парное программирование на помощь.
Советы по сопряжению
Вот несколько вещей, которые мне подходят:
- Используйте приложение для удаленного управления, такое как Zoom Basic, для интерактивных сеансов удаленного сопряжения, когда любая из сторон может взять на себя управление и управлять автомобилем.
- Сопряжение требует высокой пропускной способности. Иногда видеочат действительно хорош. Если у вас нет Screen Hero, попробуйте Google Hangouts.
- Прежде чем приступить к делу, четко объясните, что вы пытаетесь сделать, чего вы ожидали, и что произошло на самом деле. Продемонстрируйте проблему, запустив код.
- Если вы помогаете кому-то другому, позвольте ему водить машину. Люди учатся лучше, когда их мозг занят чем-то активным. Они будут лучше помнить, как это сделать в следующий раз, если будут за рулем.
- Если объяснять что-то явно не получается, садитесь за руль. Покажи, не говори.
- Не считайте себя глупым или неполноценным, если помощнику нужно время от времени брать у вас руль. Будьте открыты и восприимчивы к помощи. Оставайтесь с нами. Обратите внимание и постарайтесь следовать за вами.
- Как только вы почувствуете уверенность в том, что на правильном пути, посмотрите, сможете ли вы снова выступить в одиночку. Я знаю, что это не всегда так, но мы учимся лучше всего, когда нашему мозгу бросают вызов. Быть храбрым!
Заключение
Парные программисты - это:
- Отличная моральная поддержка.
- Хорошие слушатели и дека.
- Герои, которые приходят на помощь, когда товарищ по команде попадает в беду.
Не сомневайтесь, сделайте шаг вперед и станьте героем. Даже если вы не уверены, что можете помочь. Иногда бывает достаточно, чтобы кто-то выслушал проблему, чтобы спровоцировать прорыв.
А теперь перестаньте тратить время на то, чтобы стучать головой по клавиатуре, и попросите о помощи.
Нужна помощь прямо сейчас?
1: 1 Наставничество с Эриком Эллиоттом
Эрик Эллиотт - автор книг Программирование приложений JavaScript (О’Рейли) и Изучение JavaScript с Эриком Эллиоттом. Он участвовал в разработке программного обеспечения для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC и ведущие музыканты, включая Usher, Frank Ocean, Metallica и многие другие.
Он проводит большую часть времени в районе залива Сан-Франциско с самой красивой женщиной в мире.
