Czym jest pair programming i jak skutecznie go stosować

Transkrypcja

Dziś moim gościem jest Krzysztof Jończyk. Krzysztof opowie nam o pair programmingu i o tym, jak skutecznie go stosować. Krzysztofie, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.

Cześć. Bardzo dziękuję za zaproszenie mnie do podcastu. Bardzo mi miło.

Krzysztofie, powiedz nam coś więcej o sobie i o tym, co łączy Cię z branżą IT.

Z branżą IT jestem w jakiś sposób związany już od gimnazjum, bo wtedy w 2 klasie pojawił się pierwszy komputer. Z jednej strony były gry, a z drugiej: „Dobra, to co by tu można zepsuć w tym komputerze?”. Wtedy też zacząłem pisać prościutkie programy w C, więc to faktycznie był taki początek kariery, którą wybrałem sobie dosyć wcześnie.

Oczywiście praca to jest już ostatnie kilkanaście. Zaczynałem od prostych wizytówek, od stron pisanych pod IE6 i jakieś wczesne wersje Mozilli. Od paru lat pracuję już w poważnych firmach na dużych projektach: głównie w PHP-ie, ale miałem małe epizody z C#. W międzyczasie byłem też Team Liderem, Scrum Masterem – więc trochę tymi rolami żongluję. Wybieram sobie taką rolę, która tak naprawdę w danej chwili mnie bardziej kręci albo potrzebuję się z niej podciągnąć.

Dobrze, że masz różne role, bo będziesz mógł spojrzeć na nasz dzisiejszy temat z różnych perspektyw. Dzisiaj będziemy mówić o pair programmingu, więc może zacznijmy od tego, co to w ogóle jest.

Zasada jest zasadniczo bardzo prosta. Oczywiście później diabeł tkwi w szczegółach, ale zasada jest taka, że dwóch programistów pracuje nad jednym zadaniem. Jeżeli jest to w biurze, to przy jednym komputerze, ale jest też możliwe w pracy zdalnej, która jest teraz popularniejsza.

Generalnie dwie osoby siedzą nad jednym zadaniem. Jedna, która aktualnie siedzi przy klawiaturze, nazwana jest driverem, kierowcą. Ona skupia się bardziej na technicznym pisaniu kodu (nierobieniu literówek i ogólnie pisaniu), a druga osoba, która towarzyszy temu driverowi, jest nawigatorem (więc troszkę jak w wyścigówce). Ona tak naprawdę mówi, co robić, bardziej myśli, bardziej kieruje driverem, więc zdejmuje z niego to obciążenie odnośnie do tego, co pisać. Bardziej myśli, jak pisać. Ale mimo wszystko i tak obie osoby myślą o kodzie i jest dużo miejsca na dyskusję, na wspólną pracę nad zadaniem – bo tak naprawdę o to chodzi. Nie chodzi o to, żeby jeden dyktował, a drugi pisał.

Ostatecznie pair programming to narzędzie, które można wykorzystać w bardzo różny sposób. Można korzystać z niego z różnych powodów, więc to już zależy od tego, co byśmy tak naprawdę chcieli dla naszego kodu od pair programmingu otrzymać.

Powiedz nam, proszę, jak to wpływa na tworzenie oprogramowania. Czy przyspiesza pracę, może spowalnia, a może w ogóle zwiększa albo zmniejsza jakość kodu?

Oczywiście najprostszą odpowiedzią tutaj będzie: to zależy. To jest – tak jak mówię – narzędzie, więc jeżeli chodzi nam tylko i wyłącznie o przyspieszenie tworzenia kodu i na przykład nie przejmujemy się za bardzo jakością (bo to będzie krótki projekt albo sprawdzamy, czy działa), to dłużej będzie trwało, gdy dwie osoby w jednym czasie będą robić jedno zadanie, które mogłyby robić osobno. Jeżeli jeszcze mamy środowisko, gdzie nie robi się code review, to tak – będzie to wolniejsze.

Pair programming pokazuje pazury w sytuacjach typu: mamy projekt, który trwa długo, albo mamy złożone zadania, albo chcemy nie tyle zajmować się samym kodem, co też onboardować nowego człowieka, wprowadzać go w nasz kod, w nasze standardy – czyli przyspieszyć jego wejście w projekt.

Wydaje mi się, że nawet przy tych bardziej skomplikowanych zadaniach, gdzie robimy code review, pair programming czasowo może wyjść korzystniej. Zasada jest taka (to znowu jest coś, na co się umawiamy przy robieniu pair programmingu), że jak dwie osoby tworzą kod, to code review nie jest wymagany. Możemy więc wtedy ominąć już ten etap, czyli faktycznie skracamy czas.

Przy trudnych zadaniach łatwo jest się zamulić. Jak jedna osoba weźmie sobie zadanie, może się zamulić, może pójść trochę nie w tą stronę. Ktoś drugi zauważyłby coś innego i na samym początku droga byłaby inna, więc pair programming może pomóc wykonać zadanie szybciej. To pewnie trochę zależy od typu zadania czy od celu, jaki mamy w pair programmingu.

Jakie zadania w ogóle nadają się do pair programmingu, a czego w ogóle nie warto robić razem?

Może zacznę od tego, czego nie warto, bo wydaje mi się, że będzie to nawet krótsze. Nie warto robić bardzo prostych czy krótkich tasków, bo sam setup – żeby usiąść razem, dogadać się, kto pierwszy i ogólnie ustalić sobie taki kontrakt pair programmingu – zajmie pewnie trochę czasu. A zadanie zajmie 10 minut i tyle. Takie zadanie się więc nie nadaje.

Może jeszcze zadania typu spike, czyli takie, gdzie nie mamy faktycznie za zadanie stworzyć kodu, tylko na przykład jakiś prototyp, lub zrobić research na temat tego, jak coś może działać. Wtedy gdy dwie osoby działają osobno, mogą zrobić to lepiej – bo każda będzie myślała inaczej, więc znajdzie coś innego.

Ale jeżeli chodzi o takie koderskie zadania, wydaje mi się, że oprócz powyższych nadają się wszystkie, a szczególnie nadają się dwa typy:

• Zadania bardzo trudne lub takie, które wpływają na dalsze zadania, jest to np. wybór architektury lub robienie pierwszej wersji czegoś, po czym później będziemy jeszcze dni czy tygodnie iterować. Tutaj warto zrobić pair programming. Moje doświadczenie pokazuje, że jeśli dwie osoby wykonają zadanie, to później na code review nie będzie czegoś takiego jak: „Ale mogłeś to zrobić tak i tak i byłoby dużo prościej i szybciej, ale już jest zrobione, więc nie będziemy w to brnąć”. Tu się więc dużo upraszcza.
• Zadania żmudne, czyli refaktory, czyszczenie kodu, usuwanie kodu. Wszystko to, gdzie generuje się bardzo duże ilości kodu, gdzie później jest po prostu piekielnie trudno sprawdzić, czy coś działa. Zwłaszcza gdy usuwamy kod – trudno jest sprawdzić, czy usunięty kod działa. Po prostu może się wywalić coś innego, zwłaszcza jeśli pracujemy nad jakimś legacy. Więc tutaj w reflektorach czy w dużych, żmudnych pracach na kodzie po prostu mamy dwa spojrzenia, dzięki którym można więcej takich przypadków obsłużyć. Czyli ktoś wpadnie na pomysł: „Ej, a może zobaczmy, czy tutaj PDF się jeszcze
  generuje” lub może po prostu podrzucać przypadki testowe: „Co tu jeszcze by sprawdzić, żeby zobaczyć, czy to działa”. Code review lub sprawdzanie takiego kodu to byłby koszmar. Pair programming jest więc też takim prezentem dla kolegów, zamiast wrzucenia po prostu: „Masz tu 5000 linii kodu i teraz to Twój problem”.

Myślę, że to też bardzo zachęcające, bo gdy ktoś ma te 5000 linii kodu potem przejrzeć w code review, to pewnie nie jest zachwycony. A przy pair programmingu to jakoś tak nawet przyjemniej idzie, prawda?

Zdecydowanie. Zwłaszcza, że przy takich ilościach kodu to nawet GitHub potrafi się już zawiesić. To jest trudne. Mówi się, że im krótszy jest pull request, tym więcej jest komentarzy. A gdy jest tam 1000 linii kodu to „OK. Wygląda spoko. Możesz wrzucać”. Nikomu się nie chce tego sprawdzić.

Wygląda, że działa.

Tak, dokładnie.

Powiedz nam proszę, jak wygląda przygotowanie do takiej sesji pair programmingu. Co trzeba zaplanować? Z jakich narzędzi warto korzystać?

Tutaj trzeba rozdzielić sytuacje, kiedy pracujemy w parze w biurze przy jednym biurku, a kiedy pracujemy osobno, zdalnie – każdy przy swoim komputerze.

Zacznę może od offline’u, bo to jest chyba naturalniejszy sposób, żeby się łapać. Ważne jest to, żeby warunki były dobre, czyli musimy mieć odpowiednio duże biurko i raczej duży monitor (bo na małym byłoby trudno wszystko widzieć). Ciekawą rzeczą jest to, że gdy siadamy do czyjegoś komputera, to jest to zupełnie inne środowisko – musimy obczaić, czy ktoś ma takie same skróty klawiszowe (na przykład w IDE) albo jakich narzędzi używa.

To z jednej strony wymaga takiego wejścia, z drugiej strony jest super rozwijające, bo inaczej się nie dowiesz, jaki ktoś ma workflow pracy, jakich skrótów można używać i co można osiągnąć. Więc to jest spoko, ale trzeba to jednak przygotować sobie trochę wcześniej. Czyli tak: potrzebujemy komputera, biurka, dwóch krzeseł – żeby ktoś przypadkiem nie musiał stać przez cały czas – i właściwie tyle.

Jeżeli chodzi o online, to jest nawet prościej, bo nie musimy się martwić, że ktoś ma inne środowisko niż my. Wtedy praca bardziej polega na udostępnieniu ekranu. Gdy ja jestem driverem, ja udostępniam swój ekran, a nawigator może sobie patrzeć i nawigować. A jeżeli się zmieniamy, to wystarczy wymienić się kodem. Albo więc robimy commita, albo ewentualnie patcha – żebyśmy pracowali na tym samym. Commit pewnie jest naturalniejszą opcją.

Jeszcze jedną rzeczą, którą trzeba przygotować przed, jest pewnego rodzaju kontrakt, czyli umówienie się, jak będziemy pracować. Zasada jest taka, że w dwie osoby robimy jedno zadanie przy komputerze. Ale
tak naprawdę co to znaczy? Czy tylko ja będę pisał, a Ty będziesz patrzeć, czy się wymieniamy? Jeżeli się wymieniamy, to co ile? Czy robimy przerwy? Są to takie higieniczne rzeczy, żeby było wiadomo, jak będziemy w tej chwili pracować.

To ja jeszcze może dodam jedną rzecz odnośnie do wymieniania się kodem przy onlinie. W Visual Studio Code jest opcja udostępniania sesji i oboje możecie pracować na tym samym kodzie. Również chyba Sandbox i inne narzędziowe wersje IDE udostępniają opcję live. Wtedy nawet nie trzeba przerywać pracy – wystarczy od razu się wymienić, nie trzeba tego nigdzie pushować. Myślisz, że to jest dobra opcja?

Myślę, że tak. Nawet zapomniałem o tym wspomnieć, ale było kiedyś świetne narzędzie o nazwie Screen Hero, które robiło właśnie trochę to, tylko że udostępniało cały komputer, cały ekranu, a nie tylko IDE. Było więc możliwe nawet sprawdzanie czegoś w bazie danych czy w przeglądarce.

W Screen Hero w ogóle były 2 kursory – czyli jak ja kliknąłem w jednym miejscu, by coś napisać, ktoś drugi mógł robić żarty, kliknąć gdzieś indziej i już pisałem w innym miejscu. To było świetne narzędzie i świetnie się pracowało. Niestety zostało wykupione i z tego co wiem, ubite, więc go nie ma. Pewnie tak. Myślę, że jeżeli ktoś ma jakąś alternatywę albo właśnie korzysta z tego samego IDE, to taka opcja też jest jak najbardziej spoko.

Dobrze. Przygotowaliśmy się, porozmawialiśmy z naszym kolegą. Jak będzie wyglądać nasz pair programming. Jak on przebiega? Mógłbyś bardziej szczegółowo opisać cały proces?

Załóżmy, że wiemy, z kim w parze będziemy robić zadanie (bo to, jak się dobiera pary, to jest inna sprawa). Ja mam zazwyczaj taką sugestię, żeby zadanie zaczynała zawsze osoba mniej doświadczona, zwłaszcza jeżeli wymieniamy się rolami. Jeżeli nie, to i tak bym wolał, żeby zaczynała ta osoba mniej doświadczona.

Czyli zaczynała jako driver.

Tak, żeby zaczynała kodowanie od roli drivera z prostego powodu. Jeżeli mamy na przykład juniora i seniora, to może się zdarzyć, że senior zrobi zadanie w 15 minut, a junior nie będzie wiedział, co się właśnie wydarzyło. To nie musi być też junior. To może być drugi senior. Mam takie doświadczenie, że gdy siedziałem z kumplem, to on zaczął od roli drivera. Miał taki flow pracy, tak szybko wszystko robił i śmigał między monitorami (między tym wszystkim jeszcze skróty klawiszowe), że nie wiedziałem, co tam się dzieje. Musiałem go później przyhamować i powiedzieć: „Dobra, powiedz mi, co się dzieje, a następnym razem zaczynam ja”. Wtedy ta doświadczona osoba wie, co chce zrobić, więc lepiej, jak ona będzie kierowała driverem. Wówczas osoba mniej doświadczona będzie mogła faktycznie się wdrożyć.

W pair programmingu, gdy pisze się kod, to trzeba się skupić na samym pisaniu, na literówkach, na pewnym stylizowaniu tego kodu. Jest więc trochę takiej, powiedziałbym, fizycznej pracy nad tym kodem. Za to nawigator, gdy siedzi obok, może myśleć o wszystkim, o całym zadaniu, o problemach, o edge case’ach i o jakichś dziwnych przypadkach, które być może mogą się wydarzyć. I w taki sposób kieruje. Nawigator od razu też wyłapuje błędy, czyli mówi: „Słuchaj, tutaj nie dałeś średnika”, albo: „Słuchaj, tutaj będzie błąd, więc musimy zrobić exeptiona”. Jest więc to osoba, która myśli o zadaniu bardziej od strony tego większego obrazka – nie tak technicznie, tylko z wyższego poziomu.

Powiedziałbym, że to jest trochę tak, jakbyśmy sami robili zadanie i zamiast od razu rzucić się do pisania kodu (jak driver), najpierw byśmy się zastanowili, popatrzyli, odeszli od komputera, pomyśleli z perspektywy dużego obrazka: „Co tu zrobić”, a dopiero później usiedli i zaczęli to klepać. W pair programmingu mamy więc takie połączenie dwa w jednym – kiedy to się dzieje jednocześnie. To jest ciągła rozmowa nad zadaniem, nad kodem. To jest często nie tylko rozmowa o kodzie, ale też o narzędziach, o technikach, o wzorcach projektowych, zwłaszcza jeżeli mamy dwa różne poziomy. Chociaż niekoniecznie. Senior też może się od juniora bardzo dużo nauczyć, bo zawsze jest coś nowego. To jest też ten moment, kiedy można porozmawiać, powymieniać się wiedzą.

Muszę przyznać, że zawsze widzę coś takiego w osobach, które zaczynają: zadają dużo pytań i każde takie pytanie powoduje, że Ty się zaczynasz zastanawiać. Często tak skupiasz się na swoim zadaniu, a nie na tym wszystkim, co się wkoło dzieje, że dopiero po zadanych pytaniach zaczynasz się zastanawiać. Często zapala się lampka: faktycznie, to może być to. Trzeba to było zgłębić wcześniej.

Zdecydowanie może być tak, że mamy dane podejście, że zawsze tak robiliśmy, a ktoś przyjdzie, powie jedno zdanie i nagle wszystko się wywraca. Także tak – tutaj pair programming oczywiście tego nie zapewnia, ale zapewnia więcej tych takich bliskich interakcji między programistami. To jest też bardzo ważne.

A jaki styl pracy polecasz? Czy lepiej się wymieniać rolami, czy może nie? Wymieniać się co zadanie czy w trakcie zadania?

Doświadczyłem obu tych opcji i jestem zdecydowanym zwolennikiem wymieniania się rolami, i to nawet częstszym wymienianiem się niż co zadanie – nawet do takiego, powiedzmy, ekstremum, gdzie działamy w interwałach: 25 minut pracy i 5 minut przerwy. Po tym czasie wymieniamy się rolami. To jest technika pomodoro. Ona świetnie rozwiązuje problem typu: jeśli posadzilibyśmy dwie osoby i tylko jedna pracowałaby przy kompie, a druga by patrzyła, to ta patrząca (jak nie może zająć się czymś technicznym, pisaniem kodu) w końcu się zmęczy. Już nie chce jej się myśleć o tym, co tutaj jeszcze zrobić, jakie błędy wyszukać. Zamiana jest odświeżająca.

To jest trochę tak, jakby jechać samochodem całą podróż z Polski do Chorwacji. Dla jednej osoby to byłoby męczące, zwłaszcza jeżeli obok jeszcze byłby nawigator i mówił: skręć tu, jedź tu. A jak byśmy wymieniali ich co jakiś czas, to jest to jednak zupełnie co innego.

Wymiana daje też pewność, że dwie osoby rozumieją wszystko tak samo – bo jeżeli po 25 min ja przejmuję pisanie kodu, to muszę wiedzieć, co tu się działo. To też nie jest tak, że będę siedział i fajnie: nie muszę pracować, on to wszystko zrobi. Jest wymiana i musimy być na tej samej stronie.

A czy dzieje się też tak, że „a, daj mi jeszcze 5 minut, chcę tylko to dokończyć”?

Tak, tak też się zdarza. Oczywiście nie bądźmy super formalistami. Ja zawsze używałem timera pomodoro: czy na stronie internetowej, czy w jakiejś aplikacji (nie ma to większego znaczenia). Gdy zadzwoni ten dzwoneczek, to to jest ten moment, w którym nie zostawiamy w połowie napisanej nazwy funkcji. Niech to będzie jakiś sensowny kawałek.

Bardzo ważne, moim zdaniem, jest też robienie przerw. I znowu świetne jest tu pomodoro, bo mówi, że po każdym interwale jest 5 minut przerwy, a po 4 interwałach jest dłuższa przerwa. To jest świetne, bo jednak jak posadzimy dwóch programistów jednocześnie przy jednym komputerze, to nagle odcinamy całą komunikację firmową, odcinamy maila. Odcinamy to, że trzeba jakoś kombinować, jak tutaj pójść do toalety albo do kuchni po wodę czy na kawę. Te naturalne przerwy po prostu kończymy.

Mam 5 minut, to sprawdzę teraz maila, pójdziemy sobie na kawę, trochę się przejdę, odmóżdżę i tyle. Zapewnia to higienę pracy – nie jest tak, że siedzimy, jednemu już burczy w brzuchu, a drugi jest wkręcony w ten kodzik i zupełnie nie chce słyszeć, żeby robić przerwę, bo straci flow itd.

Oczywiście to pomodoro jest pewnym przykładem. Przy pomodoro można dostosowywać też interwały. Dwadzieścia pięć minut może się okazać po prostu za krótkie, można wykorzystać 50 minut. Ale jednak umówiłbym się na to, żeby coś nam tego czasu pilnowało, żeby były te zmiany i żeby były przerwy w trakcie.

Powiedz nam proszę, jak wygląda debugowanie podczas pair programmingu. Co wtedy robi driver, co nawigator? Czy się wymieniają, czy jedna osoba pisze na przykład testy do tego, co napisała druga osoba? Czy jest na odwrót?

Powiedziałbym, że driver te bugi często pisze, a nawigator je wyłapuje na bieżąco – to jest jedna część takiego debugowania. Po prostu one się dzieją na bieżąco, czyli w trakcie pisania kodu. Gdy się skupię, nie przewidzę pewnych okoliczności, a ta druga osoba powie: „Dobra, jak tutaj będzie to, to się wywali” albo „Zrobiłeś tutaj błąd, bo przypisujesz zmienną gdzieś tam”. Po prostu widzi to na bieżąco, więc to jest pierwszy sposób na debugging.

A jeżeli debugging to zadanie (znalezienie buga czy debugowanie kodu), to tutaj jest różnie. Może być tak, że wartość da burza mózgów: „Gdzie tutaj zajrzeć” – i wtedy można znaleźć błędy. Czasami może być też tak, że jeżeli faktycznie nie wiemy, co się dzieje, dlaczego coś nie działa, to często lepiej jednak rozsiąść się z tej pary (tak jak przy tych zadaniach typu spike, gdzie nie wiemy, co trzeba zrobić albo co się dzieje). Każda osoba będzie szukała tego na własną rękę, a później, jak już znajdziemy ten błąd, to możemy znowu wrócić do pary i naprawiać go razem.

Wydaje mi się, że pair programming jest świetny wtedy, kiedy chcemy wspólnie osiągnąć jeden cel, ale trochę wiemy, o co chodzi. Przy debugowaniu często po prostu nie wiadomo, o co chodzi, więc lepiej jest, jak jedna osoba pójdzie zupełnie inną ścieżką niż druga, bo wtedy jest większa szansa na znalezienie buga.

W zasadzie w IT zawsze pracowało się zdalnie, ale teraz to już w ogóle. Pytanie: czy uważasz, że praca zdalna utrudnia pair programming? Bo powiedzieliśmy sobie, że można, ale czy to jest Twoim zdaniem trudniejsze?

Wydaje mi się, że jest troszeczkę trudniejsze i że daje troszeczkę mniej niż taka praca w biurze. Z prostego powodu: nie mamy wszystkich tych niewerbalnych sygnałów od drugiej osoby. Ogólnie w pracy zdalnej nie mamy tych niewerbalnych sygnałów i też mimo wszystko tracimy to spojrzenie, jak ktoś dokładnie pracuje, jakie ma flow, jakich narzędzi używa. Trochę to widać i faktycznie można, ale nie widać na przykład, jak śmiga na klawiaturze albo jak coś robi. To zawsze był taki fajny smaczek, który widziałem. Ale jak najbardziej się da.

To są takie rzeczy, których trochę szkoda, gdy nie można pracować w biurze, ale zdalnie jak najbardziej się da, bo mamy technologię. Internet jest na tyle dobry, że nie ma z tym żadnego problemu. Zazwyczaj plusy z samego wykonywania zadania są takie same – czyli mamy cały czas drivera, mamy nawigatora, oni mają swoje role i jak najbardziej robią to dobrze.

Plus jest taki, że jest łatwiejszy punkt wejścia, bo pracujemy na swoim komputerze, na swoim setupie. Ktoś może pracować na dwóch monitorach, ktoś może na trzech, ktoś może na jednym. W biurze zawsze może być problem, gdy ktoś pracuje na przykład na Macu, a druga osoba na Linuksie – będzie ciężko im współpracować. Przestawienie się jest jednak ciężkie, a w pracy zdalnej nie ma tego problemu, bo choć wtedy bardziej obserwuję, to jak już jestem tym driverem, to jestem driverem, mam swoją kierownicę, a nie czyjąś.

Reszta zasad też zostaje ta sama, czyli nadal przerwy, nadal zamienianie się rolami. Wszystko zostaje to samo. Tak naprawdę tracimy to, co przy pracy zdalnej, czyli te niewerbalne rzeczy i na przykład wspólne pójście na kawę w czasie przerwy. Zdalnie jest raczej tak, że ja sobie pójdę na kawę i ktoś sobie pójdzie na kawę, ale to nie jest wspólne wyjście, gdzie mimo wszystko często nie jest tak, że nie mówimy o zadaniu i robimy jakiś small talk. Jesteśmy w tym kontekście cały czas, więc tam się może dziać dużo fajnych rzeczy.

A może fajne jest też to, że zmienia się otoczenie i to powoduje, że też inaczej zaczynamy patrzeć na problem? W czasie tej kawy dużo rzeczy, dużo problemów się rozwiązuje.

Tak. Może być tak, że pójdziemy na 5 minut na kawę, a wrócimy po godzinie, bo oboje będziemy rozmawiać jako tacy nawigatorzy.

Czy nie opłacałoby się bardziej, gdyby jedna osoba tworzyła kod a druga robiła code review? Każda pracowałaby w swoim tempie, nie rozpraszałaby się inną osobą i pracowałaby we własnym otoczeniu. Może są takie osoby, które nie lubią współpracy z innymi i wolą pisać samemu?

Powiedziałbym, że pair programming to jest narzędzie, więc możemy go używać wtedy, kiedy potrzebujemy albo gdy chcemy coś osiągnąć. Myślę, że oba te sposoby pracy jak najbardziej mogą koegzystować. Nigdy nie miałem tak, że na przykład pracowaliśmy zawsze tylko w parze. Chociaż miałem okres, kiedy pracowałem tydzień, dwa, trzy (nie pamiętam) tylko w parze, więc bywało i tak. To znowu zależy od zadań, jakie mamy. Mogą być zadania, które się bardziej nadają, które się mniej nadają, i to też zależy od osób, które mamy. Faktycznie para – że dwie osoby zrobią lepszą robotę niż każda z nich osobno – też wymaga odpowiedniego doboru. Może być tak, że z kimś będziemy chcieli pracować w parze, a z kimś nie.

Może być też tak, że po prostu od czasu do czasu chcielibyśmy samemu usiąść nad problemem, samemu sobie go rozkminić i zrobić to troszeczkę spokojniej – bo pair programming jest intensywny. To jest intensywna praca, bo to jest jednak cały czas zamienianie się. Tu nie ma takiego zamyślenia się na dłużej. To jest bardzo, bardzo intensywne, więc ja też sam czasami czułem, że wolałbym coś wziąć, żeby nie robić w parze, żeby troszkę odpocząć, może troszeczkę bardziej zrobić to po swojemu.

Jeżeli chodzi o opłacalność, to zależy ona od tego, czy bardzo chcemy robić taski jak najszybciej. Wtedy lepsza może być praca samodzielna plus code review. Chociaż przy bardziej złożonych rzeczach może być zupełnie odwrotnie, ale jeszcze trzeba spojrzeć na aspekt rozwojowy tych ludzi, takie budowanie więzi, ogólnie integrację zespołu.

Dobrze, to teraz właśnie zahaczyłeś o następny temat. Jakie korzyści pair programming przynosi samemu programiście?

Może zacznijmy od początku, gdy ktoś przychodzi do firmy. Bywają firmy, gdzie jest bardzo dobry onboarding. Mamy buddy’ego, mamy osobę w zespole, która nas wprowadza, pokazuje co, gdzie, jak, przygotowuje proste zadania. Ale jeżeli w takiej firmie jest kultura pair programmingu (jest to stosowane narzędzie), to możemy taką nową osobę od razu złapać do wspólnego zadania i zamiast tłumaczyć tak na sucho: „Tu mamy kodzik, tu robimy to tak, tutaj tak” (takie jakieś prezentacyjne rzeczy), to pokazać po prostu w praktyce, jak to wygląda.

Więc pierwsza rzecz, to jest dużo szybszy onboarding. Zwłaszcza jeżeli chodzi o jakieś standardy czy konwencje (bo one mogą się diametralnie różnić między firmami, między zespołami) i zrozumienie, dlaczego coś robimy – a nie takie tylko podążanie na ślepo. Później na code review to wychodzi. To jest trochę strata czasu. A jak przeskoczymy te rzeczy (takie, powiedziałbym, formalizmy), to mamy dużo szybciej onboardowaną osobę.

Wspominałem już o tym: tak widzimy flow pracy innych osób, więc to też jest rozwijające. Możemy zobaczyć, jakich aplikacji używają, i to nie tylko do kodowania – bo to mogą być jakieś aplikacje do baz danych, jakieś to-do listy, notatniki, wtyczki do Chrome’a, do przeglądarek. Albo nawet ustawienie okien na monitorach, jak ma się ich więcej. „Dlaczego masz to na tym ekranie, a to na tym? Bo ja zawsze mam odwrotnie”. Można sobie pogadać.

To jest intensywna praca, więc naturalnie zbliży do siebie te osoby. One będą się lepiej znały, trochę bardziej się zintegrują i ja uważam, że ta codzienna praca z innymi jest bardziej integrująca niż jakakolwiek impreza integracyjna. To jest jednak zupełnie inny kontekst. A tutaj mamy pracę z tymi, z którymi współpracujemy na co dzień i możemy się po prostu wiele, wiele, wiele od nich nauczyć i więcej o sobie nawzajem dowiedzieć. W tych przerwach też możemy naturalnie sobie z kimś pogadać – na przykład jak kogoś do tej pory nie znaliśmy.

Dobrze. To kolejne pytanie w nawiązaniu do tego, co przed chwilą powiedziałeś. Czy uważasz, że junior może programować w parze?

Tak, jak najbardziej. Praktycznie każda konfiguracja w pair programmingu jest spoko. Choć parowanie dwóch juniorów może po prostu wymagać później i tak code review, spojrzenia na kod przez kogoś bardziej doświadczonego. Tutaj więc bym się ograniczył, ale jak najbardziej: junior plus senior, junior plus mid, senior–senior. Każda ta konfiguracja jest w porządku. Mamy chociażby seniora, który od wielu lat robi w danym projekcie – on to wszystko zna od podszewki i „zawsze jakoś się tam robiło”. Ma swoje standardy, projekt ma swoje standardy, a gdy przyjdzie taki junior i zada pytanie, zada jedno jakieś proste pytanie: „Dlaczego tak robicie?”, to wtedy senior musi się zastanowić. Może mu to wywrócić światopogląd: „Zawsze tak robiłem, ale nigdy o tym nie myślałem”.

Potem weźmie urlop na cały tydzień, żeby odpowiedzieć na to pytanie. Będzie musiał zagłębić się w temat, bo nigdy się nad tym nie zastanawiał, a głupio będzie nie odpowiedzieć.

Tak. Takie filozoficzne pytania mogą być dosyć ryzykowne (śmiech), ale tak – mniej więcej o to chodzi. My też lepiej rozumiemy temat, gdy coś komuś tłumaczymy, bo żeby ktoś faktycznie zrozumiał to, co do niego mówimy, sami musimy najpierw to sobie dobrze poukładać w głowie. Senior też jak najbardziej ułoży sobie to wszystko w głowie, tłumacząc po prostu juniorowi, a junior w bardzo naturalny sposób z tego skorzysta.

Konfiguracji „junior plus junior” nie zabraniałbym w żaden sposób, skoro dwie osoby chcą tak pracować. Tylko prawdopodobnie będzie trzeba jeszcze spojrzeć, czy faktycznie coś przewidzieli itd. Definicję pary „junior plus junior” rozszerzyłbym na dwie nowe osoby w zespole, nawet niezależnie od seniority, bo też mogą nie znać dobrze systemu.

Wspomniałeś, że każda konfiguracja ma sens, ale jakie będą wady i zalety tych różnych konfiguracji? Czy lepiej, żeby osoby były na różnym poziomie?

Chyba największe niebezpieczeństwo widzę w dwóch seniorach, bo tu może już trochę wchodzić ego. Może tu być walka np. na wzorce projektowe.

Na siłę, udowadnianie sobie.

Troszkę tak. To oczywiście wszystko zależy od człowieka, bo to, o czym mówimy, może zdarzyć się niezależnie od konfiguracji, ale jednak ta seniorowatość potrafi dać takie poczucie: „Przecież ja wiem lepiej”. Wydaje mi się więc, że każda z tych opcji jest w porządku i w każdej z tych opcji, pomijając seniority, każdy z tego w jakiś sposób skorzysta.

Pomyślałem teraz, że pair programming wymusza na takich osobach rozwój umiejętności miękkich – trzeba umieć powiedzieć „tak” albo „nie”, ale w takiej formie, żeby nie zrazić tej drugiej osoby. Jest to więc dodatkowy plus. W IT jest istotne, bo nie każdy potrafi komunikować się w odpowiedni sposób. Co sądzisz?

Jak najbardziej. Tak. To może być trudne, żeby powiedzieć: „Ej, tutaj masz błąd, musisz poprawić” albo coś takiego. Chociaż za chwilę i tak to wyjdzie, czy przy kompilacji, czy odświeżeniu przeglądarki. To bardzo rozwija, bo to jest właśnie ciągła rozmowa. Ale to jest też fajnie – bo to nie jest jakaś sztuczna rozmowa na nie wiadomo jaki temat. To jest wspólne rozwiązywanie problemów. Może też pomóc osobie, która jest bardzo introwertyczna i raczej woli wszystko robić sama, ma nieufne podejście do innych osób. W pair programmingu dzięki jednemu celowi, skupieniu może być jej po prostu łatwiej. Łatwiej się tutaj rozwijać, więc to jest bardzo słusznie powiedziane, że to rozwija też umiejętności miękkie i interpersonalne.

Wróćmy jeszcze do tego tematu wad i zalet różnych konfiguracji. Chciałbyś coś dodać?

Myślę, że tutaj sprawa jest prosta. Ja jak najbardziej łączyłbym każdego. Znaczy: nigdy bym nie łączył, mówiąc: „ty i ty będziecie teraz w parze programować przez 3 tygodnie”, tylko raczej patrzyłbym na to, jak osoby się dobierają. I tak – mid czy junior zawsze skorzystają z wiedzy seniora. Wydaje mi się, że to też jest ważne dla seniorów, żeby tę swoją wiedzę przekazywać innym. Przekazywanie jej tylko przez pokazywanie kodu, przez code review, to jest nie do końca to. Ktoś zobaczy i stwierdzi: „Ciekawe rozwiązanie”. Spoko, ale za tym może być długa historia, doświadczenia itd. Wydaje mi się więc, że ta mentoringowa część u seniorów może być po prostu ważna. Nowe osoby w projekcie – czy to będzie senior, czy junior – korzystają z tego, że wchodzą w ten biznes, w ten kod dużo szybciej.

Myślę też, że seniorzy są w stanie dużo wyciągnąć z tej współpracy. Wydaje mi się, że oni już tyle się nauczyli, że niekoniecznie chcą śledzić nowości. Taki junior, gdy przychodzi, zawsze coś powie: „A, bo ja wczoraj oglądałem taki super filmik i ktoś to zrobił tak i tak. Jak to działa?”. A senior: „Nie widziałem tego filmiku. Muszę się zastanowić”.

Tak, zwłaszcza gdy przychodzą osoby z innych firm – to są zupełnie inne doświadczenia. Albo po prostu ktoś ma inne doświadczenia, a dopiero tutaj, w tym problemie przy pracy w parze o tym powie. I nagle się okazuje, że wzorce projektowe można wymienić albo że jest nowa biblioteka. Jednak wydaje się, że zwłaszcza te młodsze osoby mają większy głód wiedzy. Faktycznie chłoną jak taka gąbka i tu mogą zdarzać się rzeczy typu: „Stary słuchaj, tak się już nie robi w dzisiejszych czasach”. Może tak być.

Co według Ciebie jest najtrudniejsze w pair programmingu?

Wydaje mi się, że najtrudniejsze będzie dobranie sobie pary. To znaczy nie mówię, że jak dobierzemy sobie parę, to jest jak małżeństwo – czyli do śmierci będziemy pracować nad zadaniami wspólnie. Chodzi o takie dobranie, żeby skorzystać ze wszystkich dobrodziejstw: nie tylko lepiej, szybciej czy dokładniej rozwiązywać zadania, ale też szlifować te umiejętności interpersonalne.

Mam swoje doświadczenia, gdzie pracowałem w parze z osobami, z którymi mieliśmy regularne bitwy na kod, typu „damy tu ifa czy switcha”, lub o typ pętli. Problemem był brak takiej sympatii między nami, więc tam już faktycznie wchodziło ego: „Gdzie ty mi tego ifa zmieniasz? Ja go napisałem, to tak ma być”. Powiedziałbym więc, że to jest trudne, zwłaszcza jeżeli chcemy na przykład wprowadzać ten pair programming szerzej. Tutaj jest duża rola liderów czy osób, które wprowadzają pair programming – żeby nawigować takie konflikty i może powiedzieć ludziom, że oni mogą sobie dobierać te pary tak, jak uważają. Bo jeżeli to załatwimy, jeżeli mamy osobę, z którą się będzie fajnie pracowało, to ja potrafiłem pracować naprawdę długie tygodnie wspólnie nad trudnymi zadaniami bez problemu. To było męczące, ale bardzo satysfakcjonujące.

Myślę też, że w tej trudności zawiera się kontrakt, który musimy zawrzeć. Wydaje mi się, że nie jest on oczywisty. Gdy wchodziłem do nowych zespołów i rozmawialiśmy o pair programmingu, to to zrozumienie było inne. Na przykład nie było tak, że się zmieniamy, że pomidorami załatwiamy interwały, że mamy przerwy, tylko to było raczej takie: „Dobra. Ja będę robił, ty będziesz patrzył”. To powodowało szybkie zamulenie, nie było tych przerw i nagle się robiło kiepsko. Wydaje mi się więc, że to też jest trudność, którą warto sobie załatwić kontraktem. Jak ktoś zna pomodoro, to łatwo będzie wytłumaczyć, a jak ktoś nie zna, to po prostu ważne jest, żeby się zamieniać i żeby robić przerwy – żeby każdy miał ten swój kawałek czasu.

Dopytam Cię jeszcze o temat doboru partnera. Wspomniałeś, że warto przynajmniej mieć kogoś, z kim się lubimy, ale czy jest coś jeszcze, na co warto zwrócić uwagę?

Wydaje mi się, że to jest higieniczna sprawa – jak kogoś lubimy czy szanujemy itd., to dużo lepiej będzie się pracowało. Oczywiście można bardzo profesjonalnie podejść do wykonywania zadania i zrobić to nawet z osobą, z którą kontrakt może dużo załatwić. Nie musimy się bardzo lubić, ale wystarczy, że mamy kontrakt i zmieniamy się za klawiaturą. To też nie jest tak, że ktoś mi będzie tylko wytykał błędy przez cały dzień i będziemy te błędy wytykać sobie na zmianę.

Fajnie jest dobierać sobie osoby, które są dużo lepsze od nas, zwłaszcza jeśli jesteśmy niżej w seniority. Wtedy możemy od tej osoby bardzo dużo, bardzo bezpośrednio się nauczyć. Z drugiej strony można też patrzeć na osoby, które chcielibyśmy wprowadzać, które chcielibyśmy mentorować, którym chcielibyśmy trochę pomóc się podciągnąć. Dobrze, by starać się nie zamykać – że będziemy pracować tylko z tym, kogo lubimy, a z całą resztą nie. Wtedy cały zespół się nie integruje, tylko te dwie osoby robią się jakąś tam grupką.

Myślę, że każdy musi trochę podejść do tego samemu. Ja bym raczej nie sugerował, żeby tworzyć sztucznie pary, chyba że robimy jakiś eksperyment typu: teraz wszyscy będziemy pracować w parach 2 tygodnie. I tak wtedy bym te pary rotował. Właśnie – może ta rotacja też jest tutaj istotna, tak jak przy zmienianiu się za klawiaturą.

Zahaczyłeś o kolejny temat. Czy pair programming może zepsuć relacje w zespole? Tak jak wspomniałeś – w zasadzie można trochę pokłócić się o te ify, switche i inne tematy. Czy to powoduje, że nagle potem z dobrego przyjaciela robi się wróg?

Na pewno tak może być. To jest narzędzie. Jak mamy młotek w ręku, to też możemy narobić szkód. Myślę, że tak, zwłaszcza jeżeli mamy jakieś dwie osoby z takim mocnym ego, z których do tej pory każda robiła zadania po swojemu i wymieniały się doświadczeniami czy uwagami na code review w komentarzach. To jest trochę co innego, niż gdy nagle siedzimy obok siebie. Może nawet dojść do rękoczynów. Zwłaszcza że to jest też bardzo intensywna praca. Tu nie ma co się oszukiwać.

Są takie badania czy wyliczenia, że dana osoba może konkretnie pracować maks 4-5 godzin dziennie (nie chodzi spotkania, nie jakieś takie rzeczy około). Przy pair programmingu to potrafi być bitych 7 godzin. Siadamy rano, kończymy po południu, mamy tylko przerwę na obiad, na kawę i tak dalej. Jest to więc bardzo intensywne. Zwłaszcza gdy jest to coś trudnego albo gdy coś nie wychodzi samo, to zmęczenie może po prostu troszeczkę popsuć te relacje. Ale generalnie nie martwiłbym się tym jakoś bardzo, raczej byłbym świadom takiego niebezpieczeństwa.

Na wszelki wypadek warto mieć gdzieś pod ręką apteczkę.

Tak. I nie być samemu w dwie osoby w pomieszczeniu, tylko mieć kogoś, kto przyjdzie i powie: „Ej, chłopaki, nie kłóćcie się”.

Wiesz, może powinien być taki czerwony guzik, żeby każdy z nich mógł kliknąć, jak będzie miał dość. To by oznaczało, że się rozchodzą w spokoju.

Tak, może być. Mam też z drugiej strony takie doświadczenie, że właśnie takie osoby wprowadzały kulturowe rzeczy do zespołu, np. po każdym deploy’u albo przy deploy’u na produkcję puszczali muzykę z Rocky’ego albo coś takiego. To było dla nich takie: „A zrobiliśmy, wrzucamy”.

„Jesteśmy bohaterami”.

Tak, coś takiego.

Jak do pair programmingu przekonałbyś osobę, która nigdy tego nie robiła? W ogóle uważa, że najwydajniej pracuje się jej samodzielnie.

Niewykluczone, że nawet bym nie przekonywał, bo ktoś może mieć faktycznie taki styl pracy, kiedy lepiej pracuje sam. Zwłaszcza na przykład teraz, gdy pracujemy zdalnie. Często jest tak, że oprócz tego, że możemy pracować skądkolwiek, to możemy pracować o jakichkolwiek porach. Coraz częściej więc nie siedzimy 8–16, 9–17, tylko mamy być na spotkaniach, mamy zrobić robotę, mamy zrobić ileś tam godzin, ale czy Ty to zrobisz od 6 rano do 12 i później 2 godziny wieczorem, to nie ma znaczenia. Może być więc tak, że te osoby po prostu będą miały taki flow pracy, że ciężko będzie się złapać na pair programming.

Tutaj pewnie jakimś tipem jest to, że niekoniecznie musimy robić całe zadania w pair programmingu. Możemy też je tylko zaczynać lub robić od środka. Ja mam raczej takie doświadczenie, że robiliśmy całe zadania od A do Z, ale obie te opcje – czyli też pomoc w jakimś konkretnym elemencie, gdzie na przykład się zamulimy, już nie mamy pomysłu – jak najbardziej są spoko.

Ja jestem ogólnie fanem eksperymentów, więc pewnie mniej więcej w taki sposób próbowałbym przekonywać drugą osobę: to nie tak, że od teraz już zawsze pair programming, ale spróbuj. Spróbuj wziąć kogoś i coś zrobić albo dawaj, zrobimy to zadanie razem. Nie przekonywałbym: „Ej, to jest fajne, bo daje to, to i to”, tylko: „Ej, może zrobimy to zadanie wspólnie? Tylko za 25 minut zmieniamy się za klawiaturą” – więc tak kogoś bym w to wciągnął, troszeczkę „wrednie”.

Możemy też takiej osobie po prostu powiedzieć, że na przykład robimy refraktor albo usuwamy kod i jak nie chcesz później robić code review 3000 linii, to dawaj, zrobimy to razem i będzie z głowy. Można więc też w taki sposób przekonać – że przy żmudnej robocie w dwie osoby jest jednak trochę więcej funu niż oddzielnie.

Pomyślałem o innym argumencie. Oczywiście to jest pół żartem, pół serio, ale może by się okazało, że ta Jola podoba się temu Adamowi, który nie chce programować w parze. Można by mu powiedzieć: „Słuchaj, Jola chciałaby uskutecznić pair programming. Może byście razem podziałali?”. Myślę, że Adam mógłby być wtedy przekonany, żeby spróbować.

Myślę, że tak. Raczej nigdy nie narzucałbym nikomu pair programmingu, bo to jest faktycznie zupełnie inny styl niż własny, ale myślę, że żeby komuś pokazać, że jest taka technika i że można zrobić z tego coś fajnego, to wszystkie chwyty dozwolone.

Jakich argumentów byś użył, aby do wdrożenia pair programmingu przekonać np. Product Ownera?

Takie argumenty, że tak powiem, sprzedażowe – na pewno bym wspomniał o tym, że szybciej się wdraża nowe osoby, zwłaszcza jeżeli tych nowych osób się pojawi dużo. Byłby to taki spory argument typu: „Nie będzie siedział 3 tygodnie i się zastanawiał, co zrobić, tylko po tygodniu już będzie w miarę się po tym kodzie poruszał”.

Z mojego doświadczenia wynika, że faktycznie architektura jest lepsza do pair programmingu. Gdy są dwie osoby, to nie jest tak, że ktoś pójdzie ślepą uliczką albo tą bardziej wyboistą i już później nic z nim nie zrobimy, bo już robota zrobiona i nie będziemy tygodnia pracy wywalać do śmieci.

Też z mojego doświadczenia: bugów jest mniej, bo dwie osoby widzą na bieżąco, jak ten ficzer się tworzy, i na bieżąco mogą przegadywać inne ścieżki, inne sposoby użycia. Mogą więc od razu wyłapywać więcej tych bugów na bieżąco i faktycznie tych bugów może być po prostu mniej. A tak, to dealowanie z bugami jest zawsze dużym problemem i rozwala pracę. Jak zrobimy kod, a później trzeba go trzy razy poprawiać, to to jest dopiero kosztowne.

Fajnym sposobem na przekonanie Product Ownera może być też sparowanie się z Product Ownerem. To jest też o tyle ciekawa sprawa, że nie musimy w parze programować, tylko możemy w parze rozwiązywać jakiś problem. Może być tak, że na przykład weźmiemy sobie jakiegoś spike’a, gdzie musimy rozpoznać jakiś temat, zrobić jakiś prototyp, zobaczyć, jak coś może działać, i wtedy jeśli będziemy takie coś robić z Product Ownerem obok, to na bieżąco będziemy wiedzieli, co on tak naprawdę by chciał mieć. Może on trochę pokierować technicznie. Tu nie będziemy zmieniać się za klawiaturą, ale PO może wrzucać wiedzę na bieżąco. Nie będę musiał pisać do niego na Slacku czy na komunikatorze: „Ej, to o to ci chodziło?”. A akurat on będzie na lunchu i odpowie za godzinę, i nie wiadomo, co z tym zrobić.

Akurat ja mam doświadczenie z Product Ownerem i z analitykiem chyba też – gdzie trzeba było wyciągnąć jakieś statystyki. Fajnie było pisać SQL-ki z tą drugą osobą. Ja pisałem SQL-kę, wypluwałem jakieś dane i pytałem: „To te dane?”. „Nie”. „Dobra, to szukamy dalej”. A gdyby to robić osobno, to ta pętla zwrotna jest dużo dłuższa, dużo dłużej to trwa, więc byłoby trudniej.

Myślę, że to też ograniczyłoby przygotowywanie dokumentacji. Może dokumentacja to za dużo powiedziane, ale taki analityk najpierw musiałby Ci powiedzieć, co on dokładnie chce, jak to ma być wyliczone itd., a dopiero potem Ty byś to pisał. To mega dużo dodatkowej pracy niż jeśli usiądziecie razem. Niby siedzicie razem nad jednym tematem, ale tak naprawdę to trwa godzinę dla dwóch osób, a nie dwie godziny dla niego i potem jeszcze dwie godziny dla Ciebie.

Tak, absolutnie. Plus jeszcze od razu mamy takie spojrzenie, jak ktoś pracuje, czyli ta osoba nietechniczna może zobaczyć, o co tak naprawdę chodzi i dlaczego my czasami mówimy, że czegoś się nie da zrobić albo żeby zrobić inaczej.

Z drugiej strony programista może zrozumieć, po co coś robić. „Chcesz takie dane wyciągnąć, ale po co chcesz je wyciągnąć?”. „Bo chcę to i to sprawdzić”. „A dobra, to ja mogę zrobić to tu i będzie trzy razy szybciej”. „OK”. Można wtedy bardzo łatwo połączyć te rzeczy: co chcę, jak to mogę osiągnąć. Może się okazać, że ktoś przychodzi i mówi: „Zrób to”, ale tak naprawdę chce osiągnąć coś innego, tylko myśli, że to się da rozwiązać w ten sposób, a programista zobaczy, że tego nie da się tak zrobić. A z drugiej strony wie, jak to zrobić w zupełnie inny sposób.

Pair programming może pojawić się na rozmowie rekrutacyjnej. Jak osoba, która jeszcze nie pracowała w IT, może się do niego przygotować?

Ja bym się skupił na tym, co taki pair programming mógłby dać tej osobie – może mówić, że szybciej się wdroży, że dużo się nauczy, oczywiście jeżeli zna już podstawy. Na pewno więc sugerowałbym przesłuchanie podcastu, bo wydaje mi się, że jest tutaj troszkę danych, jak ten pair programming wygląda i co może on dawać.

Jeżeli na rozmowie pair programming będzie jako zadanie, to tutaj ta osoba na pewno będzie driverem. Tu skupiłbym się na tym, żeby zadawać pytania, zobaczyć, co trzeba rozwiązać, i żeby to nie było tak, że ta osoba będzie czuła, że ktoś jej patrzy na ręce. Może to być stresujące, ale jeżeli pracujemy w parze, to pracujemy w dwie osoby – to nie jest tak, że ktoś jest nadzorcą. Warto mieć taki mindset, że to nie tak, że ktoś sprawdza, jak my coś robimy, tylko jak współpracujemy: czy zadajemy pytania, jak je zadajemy, jak rozwiązujemy problemy.

Z drugiej strony warto też pomyśleć o tym, co taka osoba swoim wkładem może dać, pracując w pair programmingu. Na przykład: „Tu tacy starzy seniorzy pracują, a ja znam ciekawe rzeczy i mogę im wywrócić ten ich świat, ten ich status quo”.

Mam też doświadczenie z wieloma osobami, które się przebranżawiały. Te doświadczenia z innych branż są bezcenne. Programiści mogą być też tak czasami postrzegani, że „koszula w kratę i każdy tam sobie coś robi”, i tyle. A takie osoby po przebranżowieniu często mają lepsze interpersonalne umiejętności, więc mogą właśnie to wnieść do pracy: że one czegoś nie wiedzą, ale wiedzą, jak zapytać na przykład seniora. Po prostu wezmą i zmienią takiego seniora, który siedzi w domu i robi rzeczy samemu, w mentora, który zobaczy, że na przykład dzielenie się wiedzą z innymi jest fajne.

Jaką książkę polecisz osobie, która chce być lepszym partnerem w pair programmingu?

Książek o samym pair programmingu nie znam. Robiłem kiedyś takie rozpoznanie pod prezentację o pair programmingu i samej takiej literatury nie znalazłem. Wydaje mi się, że fajnym pomysłem jest każda książka, która pomaga nam być lepszym człowiekiem.

Niedawno czytałem książkę Ego is the enemy. To jest książka o tym, że ego potrafi bardzo mocno napsuć i lepiej jest się od tego ego odłączyć i pracować troszkę lepiej – nie tak, że „moje rozwiązania są lepsze”, tylko „OK, mamy trochę inny punkt widzenia. Zastanówmy się, dlaczego coś jest tak czy tak”. Wydaje mi się więc, że z takiej mocnej literatury nic nie mam.

Przygotowałem kiedyś bibliografię pod moją prezentację (pewnie będzie w notatkach). Tam są artykuły – nie tyle książki, co właśnie artykuły – z różnych eksperymentów z pair programmingiem. Jest też artykuł o tym, że programiści przez 2 tygodnie pracowali codziennie i zmieniali sobie pary. Robili eksperyment, czy to się opłaca czasowo. Mierzyli, ile jest bugów. Jest to więc takie całkiem fajne, naukowe podejście.

Link do bibliografii na pewno załączymy pod naszym nagraniem.

Gdzie możemy Cię znaleźć w sieci?

Od czasu do czasu bloguję. Mam jeden blog po angielsku pod domeną jonczyk.me. To jest taki bardziej techniczny blog, więc można tam sobie troszkę poczytać o PHP-ie, ale nie tylko. Wrzucam też artykuły bardziej miękkie – jeżeli chodzi o pracę. Mam też polską wersję, ale to jest już blog bardziej lifestylowy. Oczywiście można też łapać mnie na Linkedlinie. To jest pewnie najprostszy sposób.

Można też nawet poszukać na YouTube tej prezentacji o pair programmingu. Jest nagrana z konferencji Boiling Frogs, można więc tam zobaczyć dosyć podobne rzeczy, o których mówiliśmy, tylko ze slajdami.

Tak jest. Tak że zapraszamy osoby, które są zainteresowane. Jeżeli chcielibyście o coś Krzysztofa podpytać, to pewnie właśnie na Linkedlinie będzie najwygodniej.

Krzysztofie, bardzo dziękuję za tę rozmowę i podzielenie się z nami swoimi doświadczeniami.

Bardzo dziękuję. Bardzo fajnie się rozmawiało. Mam nadzieję, że przyda się to niejednej osobie i pair programming będzie żył cały czas i się rozwijał.

Myślę, że tak. Dzięki jeszcze raz.

Dzięki.