Перевод статьи «Should You Take a 100% Pair Programming Job?».
Парное программирование. Этот термин может пониматься по-разному. Кто-то из читателей может иметь смутное представление о том, что парное программирование это когда два программиста работают вместе… или что-то типа того. Другие могут иметь более четкое понимание деталей и специальные термины в словарном запасе – «водитель-штурман», «эксперт-новичок». А некоторые могут даже знать историю происхождения парного программирования как основной части экстремального программирования.
К истории происхождения этого подхода я еще вернусь. Но сначала расскажу, почему вообще взялся за эту тему. Я, собственно, отвечаю на вопрос читателя:
«Я проходил собеседование в компании, где практикуют исключительно парное программирование. Мне очень не нравится идея проводить весь день с кем-то, кто будет следить за тем, как я пишу код. Что вы об этом думаете?»
Итак, давайте немного проясним ситуацию. Мы здесь будем говорить о компании, где применяется правило экстремального программирования: «весь код в продакшене написан в ходе парного программирования». Это означает, что, невзирая ни на какие обстоятельства, разработчики в этой компании пишут код только попарно. Таковы правила.
Стоит ли устраиваться на работу в такой компании?
Честно говоря, на такой вопрос очень сложно ответить, ведь все зависит от вашего характера и личных предпочтений и склонностей. Поэтому, вместо того чтобы просто повернуть большой палец вверх или вниз, я более широко рассмотрю, что представляет из себя парное программирование. Я не буду говорить о том, хорош ли подход парного программирования в принципе, я сделаю больший упор на том, хорош ли он для вас как разработчика.
Оговорка насчет моих личных предубеждений (поскольку они у меня есть)
В своей работе я уже неоднократно сталкивался с парным программированием. И, честно говоря, это был позитивный опыт:
- Я создал курс для Pluralsight, который должен был помочь разработчикам пояснить скептически настроенному менеджменту пользу парного программирования для бизнеса.
- Я писал посты о парном программировании, где рассматривал этот подход с профессиональной точки зрения.
- За много лет моей карьеры мне неоднократно приходилось участвовать в сессиях парного программирования в различных ситуациях.
Но, с другой стороны, я довольно типичный интроверт. В связи с этим к парному программированию я отношусь примерно, как к открытым офисным пространствам: это интересный формат, но для меня он утомителен и не слишком продуктивен.
Так что у меня двойственное отношение к парному программированию. Я могу объяснить его пользу для команды/компании, но считаю, что эта польза скорее всего больше, чем та, которую может извлечь для себя отдельный человек. По крайней мере, некоторые люди.
Все это я оговорил потому, что дальше собираюсь приводить доводы в пользу осторожного отношения к подобной организации труда, несмотря на всю ее эффективность.
Экстремальное программирование. Как парное программирование стало популярной практикой
Сначала давайте вернемся к истории зарождения экстремального программирования. Конечно, я не стоял у его истоков, так что не ждите подробностей из уст очевидца. Но дело было так.
Несколько выдающихся разработчиков-консультантов (которые в дальнейшем подпишут Agile-манифест) собрались вместе и сказали более-менее следующее:
«Хм, если такие вещи как ревью кода и разработка на основе тестирования хороши, давайте включим их в экстремальное программирование и посмотрим, что будет».
И вышло хорошо. Настолько хорошо, что повлекло за собой написание wiki-страниц, статей, книг и т. д. А остальное, как говорится, уже история.
Естественно, это вызвало волну подражания. Нам, рабочему сообществу, ничто так не нравится, как попытки воспроизведения вещей, которые хорошо сработали у других людей. А почему бы и нет. Это один из самых фундаментальных подходов к учебе и росту.
Однако следует помнить, что правила экстремального программирования были написаны для разработчиков-консультантов, которые и были их авторами: «Эй, а что если сделать Х? Давайте попробуем и посмотрим, что будет». Никто не думал, что двадцать лет спустя в каких-то компаниях эти правила станут обязательными для рядовых разработчиков, и вам придется раздумывать, идти ли туда работать.
Доводы против работы, предусматривающей исключительно парное программирование
Перейдем к сути. Я приведу доводы, по которым вы, возможно, захотите притормозить с принятием такого предложения.
Только, пожалуйста, обратите внимание, что речь идет о 100% парном парном программировании. Это не о компаниях, где разработчики иногда устраивают сеансы написания кода, в которых участвует больше одного разработчика. Таких компаний, наверное, 90% на рынке. Также, если вам действительно нравится программировать в паре с кем-то, вам, безусловно, стоит просто принять оффер. Подобная организация работы имеет кучу преимуществ, так что, если она вам еще и нравится, то вперед. Также мы здесь не рассматриваем эффективность парного программирования как такового.
1. Возврат к необходимости физического присутствия
Начнем с простого. Множество практик и философий из движения 1990-х в сторону Agile, завязаны на физическом мире, что имело смысл в эпоху факсов и Citrix. Вы сидите в открытом офисном пространстве, пишете вполне физические заметки, которые прикрепляете к настоящей стене, посещаете ежедневные стендапы и весь день (ежедневно) сидите за столом рядом с кем-то еще.
В 1999 это нормально, но в 2019? Вы серьезно?
Если вы обратите внимание на современную работу в коммерческих компаниях, придерживающихся Agile, вы увидите существенные изменения. В некоторых случаях это движение в сторону модернизации: отказ от дресскода, установка Jenkins, практика DevOps и т. д. Но в других случаях все идет в обратном направлении: отказ от инструментов менеджмента проектов, использование белой доски для записей и стремление собрать всех в одной комнате.
Таким образом, мы видим в качестве варианта «прогресса» в подходах к разработке возврат к прошлому.
Я работаю и веду свой бизнес только удаленно, и придерживаюсь такого подхода уже много лет. Так что я определенно имею свои предубеждения, хотя и не собираюсь здесь рассказывать о преимуществах удаленной работы (просто скажу, что мне сложно представить, почему бы я захотел бы вернуться в прошлое).
Но я заостряю ваше внимание на том, что в компании, где практикуется исключительно парное программирование, практически наверняка будут жесткие правила, касающиеся нахождения на рабочем месте. Если вы все время программируете в паре, использование ненадежных инструментов для удаленной работы это риск. И гибкий график также неприемлем.
То есть, скорее всего перед вами предложение работы, где вам нужно будет сидеть на рабочем месте с 8:30 до 5:00, в полной готовности к общению с людьми, а иначе вы просто подведете свою команду.
2.Исключительно парное программирование это фактически микроменеджмент
Давайте немного сместим акцент и посмотрим на ситуацию с организационной точки зрения. Когда все ваши разработчики пишут код исключительно в парах, это официальная политика микроменеджмента.
За годы, проведенные в путешествиях в роли коуча/консультанта, мне приходилось иметь дело с непрекращающимися трениями между менеджерами и разработчиками по поводу модульного тестирования. Мне доводилось слышать о том, что менеджмент не позволяет разработчикам писать автоматизированные тесты. И о том, что менеджмент хочет видеть покрытие модульными тестами.
Во всех подобных случаях я советовал менеджменту отцепиться от разработчиков. Модульные тесты должны интересовать менеджеров не больше, чем то, насколько часто разработчик компилирует свой код или заходит на Stack Overflow. То, как разработчики работают, должно быть делом самих разработчиков.
Вернемся к нашей ситуации.
Есть в ней некая ирония, учитывая тот факт, что методологии Agile продвигают плоские структуры и самоорганизующиеся команды. Когда Кент Бек и прочие создавали эту методологию, никакого лицемерия, конечно, не было. Они-то, прописывая свои правила, как раз были вполне самоорганизующимися. Но вы, приходя в компанию, где «парное программирование является правилом», самоорганизовываться не будете.
Так что вам нужно осознавать, что вы собираетесь войти в компанию, которая будет осуществлять микроменеджмент относительно того, как именно вы будете создавать программы.
3. Вы присоединяетесь к компании, где экстроверт это «правильный» тип личности
Давайте немного свернем. Сколько бы выступлений на тему «парное программирование для интровертов» я ни посмотрел, они меня не переубедят. Парное программирование не предназначено для интровертов. Честно говоря, все эти выступления сводятся к тому, «как слегка уменьшить ваше неизбежное утомление и отсрочить выгорание».
Но напрямую вам об этом никто не скажет. А причина этого – в идеале экстроверта, описанного Сюзан Кейн в ее прекрасной книге об интровертности. По мере роста популярности «продажников» экстровертность стала «правильным» типом личности.
Вспомните школу. Если вам не нравилась идея групповой работы и вы просто хотели почитать в тишине, учитель чувствовал необходимость «исправить» ваше поведение, чтобы вы не получили ярлык «антисоциального» ребенка.
Это продолжается и в рабочем окружении. Если вам некомфортно от выступлений на публике, групповой работы, small talk и прочего, мир говорит вам, что вам нужно исправиться, чтобы продвигаться вперед. «Вот 5 полезных советов о том, как избавиться от странного стремления к одиночеству».
Не все компании одинаковы в принятии экстровертности как идеала. Но вы можете смело ставить на то, что компания, где программируют исключительно попарно, будет лидером в отношении исправления вашей «неправильной» интровертной личности.
4. Компания играет в беспроигрышную лотерею
Я рассмотрю выгоду компании от исключительно парного программирования в отдельной статье. Сейчас лишь отмечу, что основные преимущества – постоянное сфокусированное состояние разработчиков и отсутствие ошибок (относительное). Отрицательная сторона в том, что у вас не будет всплесков креативности и вдохновения, которые проявляются исключительно в тех случаях, когда вы заходите в тупик или отходите в сторону от запланированного маршрута.
Посмотрите на хрестоматийный пример Google с их 20% времени. Основной посыл там – «мы достаточно доверяем нашим сотрудникам, поэтому еженедельно предоставляем им один день, когда они могут делать, что хотят и как хотят. Мы верим, что эти их неуправляемые усилия каким-то образом окупятся и принесут землепотрясную выгоду».
Это игра на выигрыш. А вот исключительно парное программирование это игра на отсутствие проигрыша.
Подобный подход является индикатором того, что компания главным образом заинтересована в предсказуемой скорости разработки, а не в потрясающих идеях или разработке чего-то такого, что вообще поменяет правила игры. В этом нет ничего плохого, это очень рациональный подход. Ожидаемая прибыль предсказуема, и в условиях, когда вы просто не допускаете ошибок, эта прибыль будет выше, чем ожидаемая прибыль компании, где разработчикам позволяется блуждать по закоулкам в надежде на потрясающие озарения.
Я говорю об этом только для того, чтобы вы знали, на что идете. Эта компания хочет, чтобы вы пахали по 8 часов в день, предсказуемо и незаметно.
5. Парное программирование это один из признаков субординации
Завершу я аргументом, который тяжело изложить в нескольких словах. Более широко я рассуждаю о нем в своей книге «Developer Hegemony», а здесь опишу кратко.
Когда разработчики работают непременно попарно, они создают более концентрированную атмосферу субординации, чем их коллеги, имеющие возможность работать по своему усмотрению. Чтобы понять, что я имею в виду, давайте рассмотрим три неоспоримых преимущества парного программирования с точки зрения бизнеса.
- Коллективное авторство способствует распространению знаний в команде и снижает «фактор автобуса».
- Парное программирование означает постоянное ревью кода, а следовательно – меньшее количество внезапно проявляющихся дефектов и проблем в проектировании.
- Разработчики, программирующие в паре, не подвержены многим отвлекающим факторам.
Прекрасный план, верно? А теперь давайте посмотрим на парное программирование с точки зрения финансового директора. Эта организация труда:
- делает человеческие ресурсы более взаимозаменяемыми,
- помогает преодолевать врожденную неряшливость разработчиков,
- мешает разработчикам следовать их естественной склонности отлынивать от работы.
И теперь, когда финдир прогулялся по открытому офисному пространству, вы думаете, он вернется в свой кабинет и будет там на пару с другим финансовым директором заниматься управлением финансами?
Конечно, нет! Начальство так не работает. Он вернется в свой офис и будет работать один. То же самое касается scrum-мастеров, менеджеров проектов и аналитиков. Работа в паре предназначена только для разработчиков, ведь только им непременно нужен надежный товарищ.
Конечно, вслух об этом никто не говорит, да и не думает об этом, пожалуй. Это тонкие материи, пронизывающие всю организацию в целом. Но это приводит к тому, что руководство меньше прислушивается к разработчикам и как бы «прикрепляет» их к техническим позициям, затрудняя переход на другие должности. По крайней мере, так происходит до тех пор, пока вы не сумеете найти способ избавиться от признаков подчиненности.
Почему разработчику стоит согласиться на работу, предусматривающую 100% парного программирования
Этот раздел будет до смешного коротким и милым. Чтобы написать раздел с причинами, по которым не стоит соглашаться на такую работу, мне пришлось многое объяснять. А вот привести довод в поддержку такой работы очень легко.
Спросите себя:
- Нравится ли вам парное программирование и идея о том, чтобы заниматься им постоянно?
Если ответ «да», то принимайте предложение. Команды разработчиков с высокой степенью сотрудничества очень эффективны, и это очень хорошо для компании. Для вас тоже хорошо: вы подписываетесь на ситуацию «всеобщего выигрыша».
Обязательное парное программирование имеет некоторые отрицательные стороны в плане вашей личной карьеры, но есть ведь и положительные:
- Очень, очень быстрое обучение – если вы новичок, а работать будете с опытными ребятами.
- Раннее приобретение большого опыта в наставничестве, что потенциально полезно для построения карьеры консультанта.
- Вы быстро разберетесь в офисных правилах и узнаете, кто есть кто в компании.
- Если все идет хорошо, то трудно даже передать то ощущение братства, которое возникнет у вас с товарищами по команде.
- Большая вероятность завязывания дружеских отношений на всю жизнь.
И, конечно, в идеологическом плане вы будете на одной волне с компанией и ее интересами. Я не могу придумать ни одного аргумента насчет того, почему это может быть плохо.
Итак, принимать предложение или нет?
Обычно любая статья, где взвешиваются достоинства и недостатки какого-нибудь подхода, заканчивается словами «итак, как вы видите, выбор зависит только от вас». Я так не напишу, потому что какой тогда вообще смысл разбирать все «за» и «против»?
Отвечая на вопрос читателя, я считаю, что ему, вероятно, не стоит соглашаться на такую работу.
Я интроверт, я не фанат групповой работы. Но каждый раз, как я устраивался на работу в крупную компанию, где было больше ситуаций сотрудничества, чем мне бы хотелось, я обнаруживал, что мне это нравилось больше, чем я ожидал. Это не только не было кошмаром: довольно часто работа в открытом офисном пространстве или с большей долей парного программирования на самом деле доставляла мне удовольствие.
Но этот мой опыт показал, что в моем случае ситуация не была стабильной. Я работал весь день в сотрудничестве с другими людьми, а потом, когда все уходили, работал дополнительно в одиночестве, потому что коллективная работа не казалась мне настоящей. В конечном итоге я уставал даже не столько от переработки, сколько от постоянного сотрудничества. И тогда я переходил в другой проект или на другую должность.
К чему это я. Очень может быть, что парное программирование понравится вам больше, чем вы думаете. Но, с учетом ваших склонностей, оно также быстро вам надоест.
В мире множество компаний, исповедующих самые разные философии. Я бы поискал такую, которая будет вам ближе.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]