Это самое важное, что я узнал о программировании мобов.

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

Это самое простое определение программирования толпы, которое я когда-либо встречал:

Мобовое программирование предполагает создание одних и тех же вещей в одно и то же время в одном и том же физическом или виртуальном пространстве.

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

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

1. Это снизило первоначальный барьер на пути к новому рабочему месту и новому проекту.

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

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

Для меня моббинг снял напряжение, связанное с адаптацией к новому рабочему месту, и облегчил знакомство с моими коллегами. Аспект обмена знаниями в программировании мафии — это реально, и его нельзя переоценить, но это не то, что происходит автоматически.

💡 TLDR: если вы новичок в команде, не бойтесь задавать вопросы: обмен знаниями — это весь смысл группового программирования. Если вы приветствуете нового члена команды, будьте внимательны: сделайте так, чтобы он чувствовал себя комфортно, и найдите время, чтобы объяснить как можно больше контекста. Эти первоначальные затраты времени и энергии окупятся достаточно скоро.

2. Можно поиграться с интервалами

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

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

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

3. Это было непродуктивно для сложных исследовательских задач.

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

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

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

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

Через несколько месяцев я вернусь к вам, чтобы узнать, как это продвигается.

💡 TLDR: подумайте, насколько хорошо ваша команда работает в толпе для задач, связанных с исследованиями. Если они профи в этом, отлично. Если нет, то можно сначала провести индивидуальное исследование, а затем снова собраться толпой.

4. Это не дает толпе волшебным образом хорошие коммуникативные навыки.

В настоящее время я работаю в команде из четырех человек, и мы работаем как банда более 6 часов в день.

У нас много споров и мы быстро развиваемся. Мы предполагаем, что если вы не высказались, это потому, что вы согласны; если вы не задали вопрос, это потому, что вы понимаете. А в толпе мы все спокойно высказываемся и задаем вопросы. Такие фразы, как «Подождите, вы можете объяснить это еще раз?» и «Слушай, я не уверен, что это лучшее решение» — обычные, повседневные вещи.

По большей части это работает для нас.

Но вскоре мы поняли, что у такого рода общения тоже есть свои подводные камни.

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

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

Как неуклюжий (хотя и откровенный) человек, я понимаю это.

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

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

💡 TLDR: если у вас возникают проблемы с общением во время моб-сессий, попробуйте обратиться за советом к беспристрастному наблюдателю. Используйте удобные точки остановки, чтобы убедиться, что все находятся на одной странице, и сделайте все возможное, чтобы общение стало улицей с двусторонним движением.

5. Функция рисования экрана Slack очень удобна

Попытка изложить свои мысли об определенных фрагментах кода неизбежно заканчивается примерно так:

«Я думаю, что нам нужно перебрать массив перед первым вызовом функции — нет, нет, перед другим. Прокрутите вверх. Продолжайте — нет, прокрутили слишком далеко. Подождите, дайте мне номер строки... одну секунду... строку тридцать вторую!"

— Любой участник толпы, примерно раз в час.

Мы опробовали несколько различных приложений для демонстрации экрана, включая Google Meets, Zoom и Slack. Slack — явный победитель по одной причине: его функция рисования экрана великолепна.

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

Это означает, что вы можете буквально указать на правильную линию. Или обведите линию. Или нарисуйте на нем стрелку. На самом деле, если вы особенно искусный художник, вы можете буквально набросать изменение кода, которое хотите внести. Или нарисуйте блок-схему, чтобы проиллюстрировать свою идею.

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

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

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

💡 TLDR: если вы выбираете инструмент для общения/демонстрации экрана, я рекомендую Slack. Функция рисования экрана, как правило, достаточно полезна, чтобы компенсировать то, как она потребляет вычислительную мощность.

6. Уменьшено время на тупые баги

Возможно, это одна из моих любимых вещей в моббинге: когда 3+ человека смотрят на один и тот же код, кто-то всегда замечает опечатки. В общем до двух часов обязательного ада отладки.

Использовали весь массив, когда вы действительно хотели использовать элемент массива? Забыли проверить переменную на нулевое значение? Забыли добавить оператор return в свою функцию? Не можете вспомнить разницу между оператором ?? и оператором ||? Толпа прикроет твою спину.

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

7. Увеличилось время, затрачиваемое на обсуждение архитектурных решений.

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

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

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

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

8. Это был ключевой фактор в создании безупречной культуры

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

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

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

9. Мне стало труднее сосредоточиться на определенных задачах

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

В случае с моббингом достаточно легко подумать: «Хмм, давайте я просто проверю свою электронную почту по-быстрому, остальная мафия может еще минуту пожить без меня». Это правда, что одно из преимуществ группового программирования заключается в том, что толпа может позволить себе продолжать работу без участия — например, если кто-то из команды идет на прием к дантисту, заболел или ему нужно дать совет другой команде и т. д.

Но и это не повод отвлекаться.

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

10. Это очень помогло мне справиться с тревогой

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

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

💡 TLDR: не забывайте получать удовольствие. Вся работа и отсутствие игр делают рабочее место глубоко угнетающим. Это нормально время от времени тратить несколько минут на мемы золотого уровня.

Спасибо Габриэлю Менезесу,Раулю Андраде,и Фелипе Аугусто за огромную помощь в написании этого поста и за то, что были отличными друзьями как на работе, так и вне ее.