Kilka razy próbowałem programować w parach, w tym w organizacji, która (krótko) rozważała wdrożenie go jako obowiązkowego procesu dla wszystkich inżynierów (można się domyślić, jak dobrze ten pomysł się sprawdził). Osobiście nienawidziłem tego.
Wymienione poniżej powody to tylko moje subiektywne doświadczenia i nie jestem w stanie „zmierzyć” ich wpływu w konkretny sposób. Ale tutaj wszystkie są takie same:
1 - Posiadanie „nawigatora” i „kierowcy” pomaga tylko wtedy, gdy ten pierwszy mówi, a drugi słucha.
Wszyscy spotkaliśmy programistów, którzy są uparci, gorliwi w kwestii teoretycznych obaw lub patologicznie niezdolni - psychologicznie - do „wyrzucenia” starej pracy, gdy ktoś sugeruje problem. Wszyscy wiemy, że osoby są zbyt nieśmiałe lub niepewne, aby zgłaszać obawy lub sugerować przypadki narożne.
Po sparowaniu tego rodzaju programistów nawigator szybko przyjmuje pasywną rolę, a kończy się na samodzielnym programowaniu z automatycznym przeglądem kodu. To monumentalne marnotrawstwo zasobów.
2 - Parowanie uniemożliwia kreatywność.
W przeciwieństwie do tego, co wcześniej uważano za wartość „burzy mózgów w grupach”, w dzisiejszych czasach panuje zgoda, że twórcza wiedza wymaga niezależności i autonomii . Kiedy pracujesz sam, możesz szybko zhakować jakiś szalony pomysł, aby sprawdzić, czy jest to rzeczywiście wykonalne. Możesz bez słów złożyć jakiś dziwny prototyp, a jeśli zawiedziesz, to nie ma znaczenia, bo nikt nie wie .
Porównaj to do parowania: kiedy chcę wypróbować jakąś nową koncepcję, muszę przekonać mojego partnera, omówić go przez wdrożenie, krok po kroku i mam nadzieję, że nie ocenią mnie, jeśli się nie powiedzie. Tego rodzaju środowisko jest toksyczne dla tworzenia nowych pomysłów.
3 - Najniższy wspólny mianownik.
Kiedy para nie może rozwinąć nowych pomysłów, jak wyżej, lub gdy ludzie nie mogą zgodzić się co do jakiejś fundamentalnej zasady, w jaki sposób należy zaprojektować cechę, to wychodzi na jaw zagmatwany projekt, który próbuje pójść na kompromis i nie satysfakcjonuje nikogo.
Jeśli połączysz programistę, który tworzy wspaniałe, elokwentne, niebiańskie abstrakcje programowania funkcjonalnego z szybkim i brudnym maniakiem wydajności, kod, który wspólnie stworzą, zwykle nie będzie ani strasznie elegancki, ani szczególnie szybki.
4 - Brak autonomii i gwałtowna przejrzystość.
Gwałtowna przejrzystość to fraza, którą wyciągnąłem z umiarkowanie znanej (i dość kontrowersyjnej) polemiki przeciwko metodologii Scrum. Opisuje sposób, w jaki niektóre organizacje infantylną programistów i traktują ich z podejrzeniem zwykle zarezerwowanym dla pracowników nieprofesjonalnych.
Cokolwiek myślisz o „szkodach” powodujących, że praca programistów jest całkowicie przejrzysta (i możesz nie zgodzić się, że to rzeczywiście szkoda), wiele osób ceni sobie ich autonomię i zdolność do samodzielnej pracy, ufając, że zrobią to, co należy. To ważna potrzeba psychologiczna, a zmuszenie programistów do parowania (jak widziałem w co najmniej jednym sklepie) spowoduje, że pracownicy będą przerażeni, zdenerwowani i wyobcowani.
5 - Niektórzy programiści po prostu nie grają dobrze w parach.
Niektóre osoby nie zachowują się lub nie mogą odpowiednio zachowywać się w sparowanym środowisku. Mogą mieć złą higienę, złe nawyki pracy, szorstką osobowość, „głośny” i „intensywny” sposób lub całą masę innych cech, które czynią ich świetnymi indywidualnymi pracownikami, ale słabymi programistami par.
Czy potrafisz to rozwiązać? Nie całkiem. Zmiana osobistego zachowania jest trudna. Sklep zajmujący się programowaniem par musi być bardzo ostrożny przy zatrudnianiu i poświęcić dużo czasu na sprawdzenie, jak ktoś działa i czy będzie w stanie dobrze współpracować z rówieśnikami. Jednak silniejsze dyskryminowanie osobowości oznacza, że zatrudnienie potrwa dłużej, chyba że rozluźnisz swoje standardy umiejętności i wiedzy specjalistycznej.