Советы и приемы, позволяющие негодовать в своей работе и обвинять парное программирование

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

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

Принудительное парное программирование к горлу

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

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

Контроль и получение результата как можно скорее

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

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

Давление - лучший способ притвориться, что вы поощряете кого-то работать усерднее и быстрее.

Два разработчика выполняют работу одного

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

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

Всегда старайся быть лучше сверстников

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

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

Всегда делайте вид, что знаете любую полезную информацию, которую вам кто-то сообщает

Скажи, что делать, никогда не спрашивай

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

Если пара сомневается в своем отношении, скажите им, что принципы программной инженерии применимы и в реальной жизни. Принцип, который вы применяете, говоря, что делать, называется Говори, не спрашивай.

Предпочитаю пары с новичками

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

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

Предположим, что отсутствие ответа на вопрос следует считать хуже, чем предоставление неправильного ответа.

Не разглашать основную коммерческую и технологическую информацию

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

Подшучивайте над своим сверстником

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

Если вам нужно что-то объяснять дважды, смейтесь над фактом, что вы объясняете дважды, что вам никогда не нужно, когда кто-то что-то объясняет вам (вы всегда получали это при первом объяснении).

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

Предположим, что все хотят вас проверить

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

Отказаться от любых предложений по архитектуре или ремонтопригодности

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

Когда ваша пара предлагает улучшить ремонтопригодность или архитектуру, предполагайте, что это всего лишь их мнение, и требуйте более объективной оценки того, что действительно важно для компании, а именно рабочего кода.

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

«Деньги», «Стоимость» и «Убыток» - очень важные слова, которые нужно выкрикивать время от времени в процессе спаривания. Предпочитаю приносить его, когда акционеры и менеджмент готовы его услышать.

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

Заключение

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

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

Делайте лучше для себя и своей карьеры и держитесь подальше от людей, которые так думают.

Спасибо за прочтение. Если у вас есть отзывы, напишите мне в Twitter, Facebook или Github.