To jest 204 odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami o pracy w IT o nazwie Solid.Jobs, który to zresztą mam przyjemność współtworzyć, dyskutujemy o narzędziach programisty. Zapraszamy do słuchania i komentowania. 

A teraz życzę Ci już miłego słuchania. 

Odpalamy! 

 

Cześć! 

To już drugi odcinek specjalnej serii w ramach Porozmawiajmy IT, w której z Łukaszem z Solid.Jobs rozmawiamy o różnych narzędziach programisty. Dla tych, którzy nie mieli okazji zapoznać się z wcześniejszym odcinkiem, zapraszamy serdecznie, rozmawialiśmy o Code Review. Myślę, że w dzisiejszej rozmowie też nieraz się Code Review przewinie. Natomiast dzisiaj wzięliśmy sobie na tapet odcinek pair programmingu, dosyć ciekawego narzędzia, ciekawego podejścia do tworzenia kodu. 

Chciałbym Cię, Łukasz, zapytać, co Ty o tym myślisz? Czy pair programming w dobie pracy zdalnej nadal ma sens? Czy w ogóle się sprawdza? Czy da się go zrealizować? Jakie są Twoje odczucia? 

 

Cześć, Krzysztof. Bardzo ciekawe pytanie. Wydaje mi się, że właśnie tym bardziej w dobie pracy zdalnej pair programming ma sens, ponieważ jesteśmy od siebie odseparowani geograficznie i nie ma tej okazji, żeby budować relacje, żeby poznawać siebie nawzajem, poznawać, jak ta druga osoba myśli. I myślę, że to jest właśnie ta wartość, że możemy tutaj wspólnie się docierać i wspólnie właśnie coraz efektywniej budować oprogramowanie dzięki temu.

Wydaje mi się, że właśnie tym bardziej w dobie pracy zdalnej pair programming ma sens, ponieważ jesteśmy od siebie odseparowani geograficznie i nie ma tej okazji, żeby budować relacje, żeby poznawać siebie nawzajem, poznawać, jak ta druga osoba myśli. I myślę, że to jest właśnie ta wartość, że możemy tutaj wspólnie się docierać i wspólnie właśnie coraz efektywniej budować oprogramowanie dzięki temu.

 

No właśnie, bo to jest jak gdyby rodzaj czy też sposób, metodologia podejścia do tworzenia kodu, ale myślę, że wyjdziemy znacznie szerzej poza to zastosowanie w dzisiejszej rozmowie. Oczywiście to jest nadal core, ta podstawowa zasada, czy podstawowa rzecz, dla której w ogóle stosujemy pair programming, czyli tworzenie kodu, ale tak jak już tutaj zaznaczyłeś, to może mieć też inne wartości dla zespołu, dla budowania jakiejś kultury organizacyjnej. Natomiast jestem też ciekaw, co Ty myślisz o tym, jak biznes podchodzi do pair programmingu.

Bo wiesz, takie rozumienie menedżera, który nie miał jeszcze może zbyt wiele doświadczeń z pair programmingiem w swoim zespole, może być takie, że muszę zaangażować dwie osoby do tego, żeby tworzyć ten sam kod. Czy to wobec tego nie oznacza, że po prostu koszty mnożymy razy dwa?

 

To jest właśnie takie typowe myślenie managementu pewnie, ale pamiętajmy, że to, co ja bym chciał tutaj w tych odcinkach z Tobą pokazać, to że to wszystko to są narzędzia i powinniśmy je po prostu stosować w jakiś wybiórczy sposób, to po pierwsze, a po drugie w sposób mądry. I po prostu tam, gdzie jest potrzebne, to przyłóżmy to narzędzie, użyjmy go, tam, gdzie nie jest potrzebne, to nie róbmy tego.

I teraz wracając do tego pytania, czy jest to mnożenie kosztów razy dwa. Jeśli masz np. do wniesienia ciężką szafę na drugie piętro schodami, to jedna osoba albo tego nie zrobi, albo się bardzo będzie męczyć, a w dwie osoby zrobimy to szybko i sprawnie. I myślę, że analogicznie jest z oprogramowaniem. Mamy jakieś ciężkie, trudne zadania, jakieś core’owe decyzje do podjęcia, jednak ta pętla feedbacku tutaj jest dużo szybsza, jeśli pracujemy wspólnie nad czymś.

 

Zgadza się, powiedziałeś, że pętla feedbacku jest tutaj istotna i to mi się jakoś bardzo mocno łączy z tym, o czym rozmawialiśmy ostatnio, czyli Code Review. Code Review jako narzędzie nie tylko do sprawdzenia kodu, ale też jako taka forma poznania się, forma zaznajomienia, albo pracy na dwie pary oczu nad jakimiś core’owymi funkcjonalnościami. Pair programming mocno mi się tutaj z tym łączy, bo kiedy razem siedzimy nad jakimś jednym fragmentem funkcjonalności, to można powiedzieć, że Code Review dzieje się równolegle do powstawania kodu.

Zazwyczaj jest tak, że jedna osoba podczas pair programmingu pisze na klawiaturze, czyli programuje, druga podpowiada, mentoruje, patrzy z lotu ptaka na to, co się dzieje, może stara się zauważyć takie szersze problemy, na które ta osoba pisząca kod nie patrzy.

 

Z perspektywy biznesu to można np. tutaj pomyśleć sobie, że w takim razie oszczędzamy na tym czasie Code Review, bo ten Code Review jest tutaj synchronicznie wykonywany w ramach tego pair programmingu. Jest to jakiś argument na pewno, który można by przedstawić.

 

Dokładnie, pamiętam, ostatnio mówiliśmy o tym, że nie zawsze ten czas potrzebny na Code Review jest gdzieś tam na radarze osób zarządzających, że zazwyczaj po prostu nie wlicza się, np. nie bierze się w estymację tego czasu. Tutaj może to być forma oszczędności, jakby nie było.

 

Mało tego, nawiążę też do wątku, który ostatnio wspomnieliśmy, im wcześniej na etapie powstawania funkcjonalności produktu, kodu, wyłapiemy różne nieścisłości czy tam błędy, tym lepiej, tym mniej będzie nas kosztowało ich naprawienie. Im dalej w las, im bliżej oddania do klienta tej funkcjonalności, tym naprawa tego błędu więcej nas kosztuje. Więc kolejny argument tutaj w sferze biznesowej, że po prostu oszczędzamy. Oszczędzamy albo ryzykujemy mniej, bo jakby wypuszczanie takiego software’u z błędami to też jest zawsze jakieś ryzyko i tylko koszt ich naprawy.

Tak. A powiedz mi jeszcze, skąd w ogóle pomysł na pair programming, jak historycznie to wyglądało?

 

Pair programming pojawił się jako element czy część składowa extreme programmingu. To już taka trochę, mam wrażenie, może nie zapomniana, ale rzadko jeszcze używana metodologia wytwarzania oprogramowania, w której to bardzo mocno skupiamy się na samym powstawaniu kodu. Planujemy w odpowiedni sposób, zwracamy dużą uwagę na to, żeby sam proces powstawania kodu był pełny, żeby był jakościowy, żeby po prostu dostarczył jak najlepsze oprogramowanie i po to, żeby ta jakość wynikowa była na odpowiednio wysokim poziomie, to pair programming jest takim podejściem, gdzie mamy większą pewność, że rozwiązanie będzie kompletne i będzie jakościowe. Taki może być element czy też technika używana właśnie w ramach extreme programmingu.

Wspominałeś Łukasz, że pair programming to może być narzędzie stosowane wybiórczo. Tutaj się zastanawiam, chciałbym z Tobą o tym porozmawiać. Zazwyczaj mówimy, że chcemy podchodzić agile’owo, zwinnie do wytwarzania oprogramowania. Stosujemy metody, które są najlepsze w danym zespole, dajmy na to. Powiedziałeś, że pair programming to nie zawsze musi być najlepsze podejście w każdym przypadku. Czyli nie każdy feature kwalifikuje się na to, żeby być wytworzonym poprzez pair programming. Czy według Ciebie jest jakaś heurystyka, da się określić zasadę, według których powiedziałbyś, że tutaj pair programming ma sens, a tutaj to już może niekoniecznie?

 

Jedno spojrzenie to jest takie, jak właśnie zaproponowałeś, czyli pair feature. Patrzymy, czy ta zmiana jest jakaś bardziej wymagająca, czy będzie miała wpływ na wiele elementów w systemie, czy zasięg tej zmiany będzie ograniczony. Natomiast myślę, że z perspektywy narzędzia ciekawe byłoby takie funkcyjne pokazanie. Czyli kiedy możemy użyć tego pair programmingu, nawet jako ten team lead. Mogę np. zaproponować zespołowi, w jakich sytuacjach powinien być użyty.

Sytuacja numer jeden moim zdaniem onboarding nowego członka zespołu. To jest idealne narzędzie, żeby właśnie, tak jak wspomniałem na samym początku, po pierwsze, żeby się tutaj dotrzeć, żeby zobaczyć, jak dana osoba myśli, żeby też pokazać tej nowej osobie system. Wiadomo, że jeśli jesteś nowy, zaczynasz z nowym projektem, są różne konwencje, niekoniecznie w każdym projekcie są te konwencje identyczne i wtedy też jest możliwość zadawania tych pytań na bieżąco, tym bardziej właśnie w tej dobie pracy zdalnej.

Czyli myślę, że onboarding jest bardzo cenny. Druga teraz skrajność, czyli offboarding, ktoś odchodzi z zespołu i chcemy jeszcze na koniec od tej osoby tę wiedzę specjalistyczną, czy właśnie informacje o tych modułach, za które ta osoba była odpowiedzialna jakoś wydobyć. Myślę, że to jest jeden z fajniejszych właśnie wtedy elementów, żeby ten ostatni miesiąc na przykład ta osoba tutaj pracowała z nami gdzieś, jakoś rotując z różnymi członkami zespołu i po prostu, żeby się tą wiedzą dzieliła. Czyli też tutaj wprowadzamy ten element wymiany wiedzy.

Trzecie zastosowanie, to osobiście używałem takiego pair programmingu w rekrutacjach i uważam, że to jest świetne narzędzie rekrutacyjne jeśli rekrutujemy programistę, bo poznajemy tę osobę, widzimy, jak ona myśli. Wiadomo, że rekrutacja to specyficzny przypadek, bo wszyscy są zdenerwowani, jesteśmy tutaj siłą rzeczy oceniani, więc też popełniamy błędy wynikające ze stresu, ale myślę, że fajniej po prostu zrobić ten pair programming i takie pół godzinki takiego oprogramowania razem z tą osobą, niż komuś dać zadanie, powiedzieć masz tu zadanie na 2 godziny, na godzinę, na 45 minut i potem omawiać z tą osobą to zadanie. Myślę, że tutaj nie zobaczymy tego przepływu decyzji, myśli.

Czyli tak jeszcze szybko podsumowując te zastosowania, moim zdaniem onboarding, offboarding, rekrutacja i oczywiście jakieś takie spojrzenie feature’owe.

Czyli myślę, że onboarding jest bardzo cenny. Druga teraz skrajność, czyli offboarding, ktoś odchodzi z zespołu i chcemy jeszcze na koniec od tej osoby tę wiedzę specjalistyczną, czy właśnie informacje o tych modułach, za które ta osoba była odpowiedzialna jakoś wydobyć. Myślę, że to jest jeden z fajniejszych właśnie wtedy elementów, żeby ten ostatni miesiąc na przykład ta osoba tutaj pracowała z nami gdzieś, jakoś rotując z różnymi członkami zespołu i po prostu, żeby się tą wiedzą dzieliła. Czyli też tutaj wprowadzamy ten element wymiany wiedzy.

Ta wymiana wiedzy, o której tutaj już nieraz mówiliśmy, poprzez takie Code Review, które dzieje się jak gdyby równolegle, to jest rzecz, do której już po raz kolejny gdzieś tam nawiązujemy, ale myślę sobie, że mega istotne jest to flow, o którym powiedziałeś. W momencie, kiedy otrzymujemy jakiś pull request do sprawdzenia, otrzymujemy zadanie rekrutacyjne do oceny, zazwyczaj widzimy efekt końcowy tej pracy. Okej, jeśli w miarę commity są, powiedzmy, w ten sposób tworzone, że widzimy, jak ktoś myślał i przez jakie etapy przechodził, to można w jakiś sposób zastanowić się, jak ten flow u tej osoby wyglądał, ale zazwyczaj oceniamy efekt końcowy.

Myślę sobie, że taka duża wartość dodana wymiany wiedzy podczas pair programmingu polega na tym, że obserwujemy wszystkie te duże i małe etapy powstawania danej funkcjonalności, czy też pisania kodu. Czyli nie tylko daje nam to taki pogląd, jak ta osoba myśli, ale też może np. jakiej wiedzy brakuje. Być może używa, czy też próbuje tworzyć jakieś narzędzia, jakieś funkcje, metody, które już są w trakcie. Być może ewidentnie widać, że nie zna jakiegoś obszaru, jakiejś biblioteki, z której korzystamy. 

I to wszystko może nie wyjść w momencie, kiedy obserwujemy już finalny efekt tej pracy, ale w trakcie kiedy to rozwiązanie powstaje, widać, gdzie są te braki. Więc tutaj możemy przynajmniej zaobserwować, gdzie brak jeszcze tych kompetencji, gdzie brak wiedzy i może spróbować to w ten sposób uzupełnić, albo wskazać, gdzie można tę wiedzę uzupełnić.

 

Chciałem tu trochę przed szereg wyjść i powiedzieć, że na kolejny odcinek planujemy tutaj rozmowę o Spike’u programistycznym, inaczej zwanym proof of concept. I to, co jest fajne w tych wszystkich narzędziach, które dotąd omówiliśmy, czyli tym Code Review, pair programming, właśnie o tym Spike’u, który mamy zaplanowany i potem o kolejnych narzędziach, na razie nie będę zdradzał, jakich, to co jest fajne, myślę i fajne spojrzenie, to że tak naprawdę te wszystkie narzędzia służą do tego, żeby pogłębić naszą wiedzę, albo żeby dzielić się tą wiedzą. Czyli nastawienie po prostu na poznanie.

 

Teraz to ja muszę coś tu dopowiedzieć jeszcze do tego, bo wiesz, można byłoby tak argumentować, że okej, jeśli firma prowadzi dokumentację techniczną w wystarczająco dobry sposób, to teoretycznie dałoby się osiągnąć to samo. Ale myślę sobie, że nie wszyscy są świadomi tego, że to jest jakaś najczęściej nieosiągalna rzecz.

 

Tak, ale dokumentacja nigdy nie będzie aktualna, zawsze dokumentacja staje się po prostu obsolete, a ta wiedza bieżąca i te rozmowy, to mówimy zawsze o bieżącej sytuacji.

 

Tak, ale wiesz co, myślę sobie, że aktualna to jest jedno, ale myślę sobie, że jej pełność też zazwyczaj pozostawia wiele do życzenia. Wiesz, w momencie kiedy czytasz sobie dokumentację, uczysz się, myślę tutaj o wymianie wiedzy, uczysz się na temat tego systemu, czytając dokumentację, masz obraz kogoś, kto tę dokumentację stworzył. W sensie to jest obraz, czy też wiedza tej osoby, która tworzy tę dokumentację. Ona siłą rzeczy nie ma prawa być pełna. Okej, niektórzy mają taką łatwość w tym, żeby dopytać o te brakujące elementy, ale zazwyczaj nie wiemy tego, czego nie wiemy. I może być trudno złapać ten cały kontekst w przypadku takiej dokumentacji gdzieś tam spisanej. A podczas pair programmingu mam wrażenie, że łatwiej jest te elementy wyciągnąć.

Chodzi mi o to, że ta wymiana wiedzy podczas pair programmingu ma okazję dać nam pełniejszy obraz danego feature’a, systemu, mikroserwisu, czegokolwiek niż taka spisana forma.

Oczywiście, onboarding to jest tutaj bardzo ważne zastosowanie, jeśli chodzi o tę wymianę wiedzy i zdobycie jak najszybciej tej niezmiennej wiedzy, żeby wystartować, ale też takie narzędzie dla juniorów, dla osób początkujących, które oprócz wiedzy na temat samego systemu muszą jeszcze nauczyć się wiele rzeczy, jeśli chodzi o język, o framework, o praktyki deweloperskie itd. Z tej perspektywy ja patrzę na pair progamming jako na swego rodzaju benefit.

Oczywiście, zawsze jest jakiś tam stres, jakby nie było. Zwłaszcza jeśli programujesz razem z osobą, która jest dużo bardziej doświadczona od ciebie, to jest jakiś tam stres, ale z drugiej strony uczysz się znacznie szybciej, niż gdybyś musiał do tego dochodzić gdzieś tam sam, albo próbować analizować dokumentację itd.

 

Tak, ale mi się wydaje, że to jest złe podejście. Właśnie taki pair programming to moim zdaniem jest właśnie dobra zabawa. I dla takiego team leada to może być też takie narzędzie jakby team buildingowe, czyli budujące zespół, wspierające integrację w zespole. I właśnie też mówimy o pair programmingu, ale można też do tego podejść jeszcze inaczej. I też w ramach takiej integracji w zespole można takie sesje też robić mob programmingu raz na jakiś czas, np. raz w miesiącu taki dzień można poświęcić.

Poświęcić, no może to jest złe słowo, bo w ramach takiego eventu powstanie jakaś wartość, wcześniej trzeba to zaplanować oczywiście. Można zorganizować taki mob programing, czyli znowu spotykamy się gdzieś w jakiejś salce konferencyjnej, mamy jednego laptopa, rzutnik i wspólnie budujemy jakąś funkcję w zespole. Jedna osoba służy wtedy jako ten mięsień przy klawiaturze i wspólnie podejmujemy decyzje. Jest to na pewno jakiś sposób na budowę zespołu i takiego team spirit.

 

Okej, mamy tutaj wiele tych funkcji takich rekrutacyjno-teambuildingowych, to też jest istotny element, ale ja chciałbym wrócić do tego core’u, którym jest jednak wytwarzanie kodu. Przynajmniej tak to zostało zaplanowane.

Powiedziałem, że można użyć takiej metody czy takiej techniki w momencie, kiedy pojawia się nowy feature do zaimplementowania. Oceniamy, że on jest na tyle istotny, albo może mieć na tyle duży wpływ, że warto zaangażować dwie osoby lub więcej, żeby taki feature wytworzyć już na etapie jego powstawania. Ty powiedziałeś, że to może być tylko jeden z przypadków albo jedna z możliwości, że takie podejście feature’owe sobie stosujemy. Do jakich jeszcze innych zadań programistycznych widziałbyś pair programming jako dobre narzędzie?

 

Pair programming oczywiście możemy zastosować przy nowych feature’ach, przy refaktoryzacji, przy pracy nad architekturą. Tutaj mówimy pair programming, ale też znowu nikt nie będzie tutaj stał z batem i pilnował, czy rzeczywiście ktoś na tej klawiaturze coś pisze. Może to nie musi być programowanie, może to jakiś dokument, może to możemy coś w Wordzie pisać. Nie ograniczajmy się, nie zamykajmy się w pudełku, to narzędzie jest bardzo elastyczne.

Okej, to może teraz, Krzysztofie, opowiedz nam trochę w takim razie, jak taka sesja pair programmingu, Twoim zdaniem, powinna wyglądać, jak się do niej przygotować?

 

Myślę, że niestety jak zwykle to zależy. W momencie, kiedy podchodzimy do tego w taki klasyczny sposób, czyli skupiamy się na wytworzeniu kodu, bo nie wiem, czy to będzie nowy feature, czy refaktoryzacja, to dobrze jest, jeśli faktycznie dwie osoby są na równi zaangażowane w ten pair programming.

Może to oznaczać, że zmieniamy sobie miejsca, czyli pierwsza osoba startuje na początku jako ta pisząca, jako ta, można powiedzieć, wytwarzająca kod, druga ma bardziej zadanie takiego obserwatora, takiej osoby, która patrzy z lotu ptaka, czy to tutaj ma sens, czy brakuje jakichś elementów w tym myśleniu, czy może o jakimś scenariuszu np. zapomnieliśmy, czyli jest bardziej taką osobą analizującą ten powstający kod. Ta pierwsza osoba skupia się na tym, żeby ten kod był poprawnie pod względem różnych praktyk zrobiony. Ale to oczywiście nie oznacza, że tak musi zostać do końca. 

Możemy oczywiście tutaj sobie swobodnie co jakiś czas zmieniać rolę, po to, żeby nie zmęczyć się aż tak bardzo. Bo wiadomo, że jedna albo druga rola inaczej nas angażuje. To bardzo zależy od tego jak się umówimy. Niektórzy mają jakieś tam lepsze skille programistyczne, inni lepsze skille, takie jeśli chodzi o architekturę albo zaproponowanie jakichś rozwiązań. Tutaj możemy się docierać.

 

Może się wtrącę i tak trochę opowiem przykładów z mojej praktyki. Bywało tak, robiłem taki pair programming i bardzo się wkurzałem, bo tutaj ja coś proponuję, żebyśmy zrobili, a ta osoba ociąga się z tym. Tutaj coś kliknie, tam coś doda, ale ciągle nie mogę tej mojej koncepcji przeforsować. A z drugiej strony mam kolegę, z którym się już przez lata tak dotarliśmy, że prawie bez słów tutaj się rozumiemy i bardziej preferuję to, jak on jest przy klawiaturze, a po prostu wspólnie wymyślamy. To nie musi być tak, że się zmieniamy przy tej klawiaturze. On bardzo sprawnie operuje klawiaturą i nie ma potrzeby, żebyśmy się zmieniali, a pomysłami rzucamy po prostu na zmianę. Więc to jak najbardziej może różnie wyglądać. Nie ma tu chyba żadnych sztywno określonych norm.

Bywało tak, robiłem taki pair programming i bardzo się wkurzałem, bo tutaj ja coś proponuję, żebyśmy zrobili, a ta osoba ociąga się z tym. Tutaj coś kliknie, tam coś doda, ale ciągle nie mogę tej mojej koncepcji przeforsować. A z drugiej strony mam kolegę, z którym się już przez lata tak dotarliśmy, że prawie bez słów tutaj się rozumiemy i bardziej preferuję to, jak on jest przy klawiaturze, a po prostu wspólnie wymyślamy. To nie musi być tak, że się zmieniamy przy tej klawiaturze. On bardzo sprawnie operuje klawiaturą i nie ma potrzeby, żebyśmy się zmieniali, a pomysłami rzucamy po prostu na zmianę. Więc to jak najbardziej może różnie wyglądać. Nie ma tu chyba żadnych sztywno określonych norm.

 

Myślę, że nie ma, natomiast jeśli myślimy o takich zastosowaniach jak onboarding, jak offboarding, o których wspomniałeś itd., to tam może być większa tendencja, żeby ta osoba, która wchodzi albo wychodzi z firmy, była w jakiejś tam określonej roli bardziej. Jeśli dopiero wchodzisz do tego projektu, to być może będziesz tą osobą, która bardziej pisze, dajmy na to, a ta osoba, która jest obok Ciebie, która już zna ten system, będzie podsuwała jakieś rozwiązania, mówiła, z czego można skorzystać, być może będzie na swoim ekranie coś rysowała albo na tablicy. Może być większa skłonność do tego, żeby iść w tym kierunku. Tak samo przy offboardingu.

Tak, to zależy od danej sytuacji, od ludzi, od systemu.

 

Dokładnie. Można to podsumować w ten sposób, że to nie oznacza jakichś sztywnych ram albo pracy na akord, że teraz godzinę Ty programujesz, godzinę ja wymyślam, mówię, a potem się zmieniamy. To jest kwestia dopasowania.

 

Tak, i jeszcze dobrą heurystyką na to, kiedy się zmienić, jest po prostu, jak ktoś się zmęczy, jak ktoś straci wenę, to wtedy czujemy, że może czas teraz się zamienić albo może czas teraz pójść wypić kawę.

 

Pewnie, jak najbardziej. Pytałeś też, jak się przygotować do tej sesji. Wydaje mi się, że fajnie jest, jeśli te dwie osoby, czy więcej, ale zakładam taki bazowy scenariusz, mają jakiekolwiek pojęcie na temat tego zadania albo sobie gdzieś tam wcześniej już popatrzą w kod, albo zastanowią się nad tym, co można tutaj zaproponować.

Bo ja kilka razy spotkałem się z kolei z taką sytuacją, że jeśli sobie siadamy do takiej sesji i po raz pierwszy dopiero mamy styk z tym zadaniem, czytamy, to tracimy trochę czasu, każdy sobie siedzi niby razem, ale tak naprawdę osobno, robi taki wstępny research, czytanie różnych materiałów itd. I to jest według mnie niepotrzebna strata czasu. W sensie te rzeczy można zrobić osobno, przed jeszcze tą sesją, żeby już ta sesja była taka efektywna, więc tak to widzę.

 

Tak, tutaj się z Tobą zgodzę, że po prostu nie traćmy czasu, najlepiej podzielić wcześniej między siebie zadania i przyjść już tutaj, kiedy ja już wiem coś więcej od tej strony np. biznesowej, a tutaj ktoś wie coś więcej od strony technicznej.

 

Dobrze, Łukasz, myślę, że całkiem sporo już tutaj o pair programmingu, wielorakich zastosowaniach tego narzędzia powiedzieliśmy, więc próbowałbyś to jakoś podsumować?

 

Jasne. Pamiętajcie tak, że jest to narzędzie, więc używajmy tego narzędzia w sposób po prostu mądry, tam, gdzie to jest potrzebne, przy tych np. trudniejszych, kluczowych zadaniach pamiętajmy o tym nieoczywistym, czy też funkcyjnym, tak bym to nazwał, zastosowaniu pair programmingu, czyli np. przy rekrutacjach, przy onboardingu, offboardingu, ale też jako team leaderzy pamiętajmy, że można użyć tego narzędzia do budowania właśnie tego ducha zespołu. I też pamiętajmy, żeby po prostu do takiej sesji pair programmingu odpowiednio się przygotować i nie zrażajmy się, bo tak jak mówię, im dłużej z kimś współpracujemy, to tym bardziej się docieramy i coraz to lepiej idzie.

Tak że jeśli dopiero chcecie wypróbować coś takiego jak pair programming, nie wyszło Wam, to spróbujcie może jeszcze raz, może z kimś innym, bo też może być to problem charakterów między tymi osobami, które tutaj ze sobą współpracują. Tak że nie zrażajcie się, spróbujcie po prostu potraktować ten pair programming jako narzędzie i mam nadzieję, że będziecie tworzyć fajny kod.

 

Tak, jakościowy kod, bo to też jest ważne. A jak jesteśmy tutaj już w duchu tego, że nie wszystko od razu musi wychodzić, to chciałbym Cię też, Łukasz, zapytać, o czym będziemy rozmawiać w następnym odcinku.

 

Tak jak wcześniej już trochę zdradziłem, kolejne narzędzie to będzie Spike, czyli kolejne narzędzie, które pozwala nam zdobyć jakąś wiedzę. Stay tuned.

 

I do tego odcinka oczywiście już teraz zapraszamy, mamy już w swoim toolboxie Code Review, mamy pair programming, obiecujemy, że będzie tego na pewno więcej i bardzo dziękujemy za czas, który z nami spędziliście, zapraszamy oczywiście do kontaktu, do podsyłania nam pomysłów na kolejne narzędzia, o których warto byłoby wspomnieć, a wszystkie osoby, które poszukują ofert pracy, zapraszamy na Solid.Jobs, gdzie zawsze z widełkami wynagrodzeń te oferty tam odnajdziecie, na pewno będą to oferty, które pozwolą Wam rozszerzyć i rozbudować Waszą karierę, nie tylko programistyczną, bo tam wiele różnych kategorii, wiele różnych specjalizacji mamy w ofercie.

Super, Łukasz. To mamy kolejne narzędzie omówione, zapraszamy oczywiście słuchaczy do kolejnego odcinka, ja Ci za dzisiaj bardzo dziękuję.

Cześć!

 

Dzięki, cześć.