Story pointy - bezsens i robienie przedszkola

Bo PP to development i review w jednym, uśredniając. Z tą różnicą, że sugestię są omawiane na bieżąco a nie w komentarzach pod pr.

Tak jak piszesz może i było w latach 90 i początku 2000 gdy powstawało XP.

Teraz jest inaczej:

• Toole typu sonarqube skanują i liczą pokrycie, robią statyczną analizę kodu i dodają komentarze do PRów.
• Pojawiły się nowe narzędzia (IDE) i praktyki takie jako code review, które są stosowane powszechniej przez liderów branży (FAANG) niż nadal niszowe pair programming.
• Mamy narzędzia AI jak chatGPT i CoPilot które pozwalają na "pair programować z botem".
• Kod jest coraz bardziej złożony, poleganie na liczbie głów z N nie wiadomo jak wielkim nie skaluje się. Należy polegać na narzędziach, przykładowo lepiej skanować podatności secuity w zależnościach skanerem niż robić okresowy upgrade ręcznie.

Wydaje mi się że PP to jak komunizm, piękny w teorii słaby w praktyce, działa w małych komunach ale się nie potrafił wyskalować.

Podaważanie jedych badań przez @Riddle podczas gdy podane przez niego zostały opisane przez jednego z "trenerów Agile" to dla mnie hipokryzja.

Riddle napisał(a):

... Ale za to mamy dużo lepszy software, który w niedalekiej przyszłości okaże się dużo łatwiejszy, prostszy, tańszy i szybszy do zmian...

Pelna zgoda, ale problem polega na tym, ze biznes nigdy nie mysli w kategoriach jakiejkilwiek przyszlosci, nawet tej najblizszej.

@0xmarcin A spytam się - stosowałeś kiedyś Pair Programming przez jakikolwiek sensowny okres czasu, np 3 tygodnie+?

0xmarcin napisał(a):

Tak jak piszesz może i było w latach 90 i początku 2000 gdy powstawało XP.

Teraz jest inaczej:

• Toole typu sonarqube skanują i liczą pokrycie, robią statyczną analizę kodu i dodają komentarze do PRów.
• Pojawiły się nowe narzędzia (IDE) i praktyki takie jako code review, które są stosowane powszechniej przez liderów branży (FAANG) niż nadal niszowe pair programming.
• Mamy narzędzia AI jak chatGPT i CoPilot które pozwalają na "pair programować z botem".
• Kod jest coraz bardziej złożony, poleganie na liczbie głów z N nie wiadomo jak wielkim nie skaluje się. Należy polegać na narzędziach, przykładowo lepiej skanować podatności secuity w zależnościach skanerem niż robić okresowy upgrade ręcznie.

Soft powstały w wyniku takiego procesu jest bardzo słaby, ma sporo bugów, i wysiłek który należy w niego wkładać żeby go rozwijać rośnie:

• Lintery i sonary w żaden sposób się nie umywają do review prowadzonego przez człowieka który siedzi obok i wytwarza oprogramowanie razem z Tobą.
• Code Review przez IDE nadal ma te same problemy jak CR przez PR: ogromny feedback loop, jesteś praktycznie skazany na opóźnienie informacji, czekanie z feature'ami, opóźnienia praktycznie wbudowane w Twój proces - nie da się w ten sposób np dostarczyć 20-30 tasków dziennie, a z PP się da.
• Programowanie wspierane przez AI jest bardzo fajne, sam korzystałem z Github Copilot, i to jest super. Ale to w żaden sposób nie pomaga lepiej rozumieć wymagań, lepiej rozumieć klienta, lepiej dostarczyć coś w szybki sposób. Praca programisty nie polega na klepaniu kodu (w którym bot Cię może wyręczyć), tylko w dobrym projektowaniu systemów pod ich userów - i na razie boty tego nie umieją, a ludzie tak.
• Nie wiem jaki kod jest bardziej złożony - ale nic takiego nie jest obserwowane. Software teraz wygląda bardzo podobnie do tego jak software 50 lat temu - mamy co prawda trochę nowsze języki, ale w gruncie rzeczy nic się nie zmieniło. Jedynym "boom" który zmienił programowanie był polimorfizm, oprócz tego rozwiązania stosowane dzisiaj są bardzo podobne do tych stosowanych dziesiątki lat temu.

Soft powstały w wyniku takiego procesu jest bardzo słaby, ma sporo bugów

To już klapki na oczach. Google, AWS, FB - niezawodność jakiej świat nie widział od wielu lat przy skali nie bójmy się przyznać globalnej. GMail, GitHub - awarie się zdarzają ale są to produkty i bardzo dopieszczone i bezkonkurencyjnie niezawodne.

Nie miałem okazji PP w pracy, bo takie oferty odrzucam. Czuł bym sie psychologicznie przytłoczony taką praktyką.

0xmarcin napisał(a):

Nie miałem okazji PP w pracy, bo takie oferty odrzucam. Czuł bym sie psychologicznie przytłoczony taką praktyką.

To o czym my w ogóle rozmawiamy. Wypowiadasz się nt czegoś czego nie próbowałes nigdy w życiu.

Typowy Marcin i jego chłopski rozum co pokazywał w innych tematach. Nie rozumiem czegoś, nie lubię tego, więc jest bez sensu. Ręce opadają.

To o czym my w ogóle rozmawiamy. Wypowiadasz się nt czegoś czego nie próbowałes nigdy w życiu.

Trochę jak wyznawca religii X. Ja widziałem mojego boga Xsa. Wy poganie nie chcecie mi wierzyć. A idźcie w h...

0xmarcin napisał(a):

To o czym my w ogóle rozmawiamy. Wypowiadasz się nt czegoś czego nie próbowałes nigdy w życiu.

Trochę jak wyznawca religii X. Ja widziałem mojego boga Xsa. Wy poganie nie chcecie mi wierzyć. A idźcie w h...

A broni Ci ktoś spróbować PP?

Poza tym to nie chodzi o wyznania albo preferencje - ważne jest co działa. I PP działa bardzo dobrze. Gdyby nie działało to bym je porzucił i szukałbym czegoś innego. Jeśli znajdę coś co działa lepiej niż PP to je porzucę , i zacznę stosować to coś co lepiej działa - ale na razie nic takiego nie znalazłem. I pracowanie w pojedynkę "bo wygodniej" nie działa lepiej po prostu.

Riddle napisał(a):

0xmarcin napisał(a):

pair programming to dobra technika do rozwiązywania bugów (debugowania) czy dzielenia się wiedzą ale pod następującym warunkiem:

• Osoba która chce się parować robi to dobrowolnie, oraz osoba proszona o sparowanie robi to dobrowolnie.
• Osoba prosząca może wybrać z kim się sparuje.
• Szanujemy wzajemnie swój czas, a sama praktyka jest ograniczona czasowo (dla mnie do max 2h na dzień).

Zgadzam się, aczkolwiek nie tylko. Do standardowego developmentu też jest bardzo dobre.

0xmarcin napisał(a):

Natomiast wszelkie wymuszanie tego typu pracy traktuje jako poważną ingerencje w prywatność oraz samodzielność pracownika.

Takie opinie słyszę tylko od ludzi którzy nigdy nie stosowali PP. Jak ktoś tak popracuje przez kilka tygodni, to zaczyna to preferować (w większości).

0xmarcin napisał(a):

Na koniec wy wszyscy apologeci technik XP pomyślcie sobie że jest upalny sierpniowy poniedziałek a wy musicie siedzieć sparowani z tym tłuściochem który przyjechał rano na rowerze lecz nie wziął prysznica, a na dodatek z japy jedzie mu czosnkiem...

I rozwiązaniem na to jest odsunięcie się od niego? Czy może lepszym rozwiązaniem byłoby poprosić go o prysznic w pracy. Poza tym, nie musisz parować z kimś z kim nie chcesz - bylebyś parował z kimkolwiek.

Ale odklejka. Większość ludzi na pewno tego nie polubi bo nie da się opierniczać. Ja chcę sobie zrobić przerwę na obiad kiedy mam ochotę. Chcę zrobić pranie i iść do sklepu jeśli mam potrzebę. Chcę sobie obejrzeć coś na YT i posłuchać muzyki. I to wszystko w trakcie pracy. W PP to nie możliwe

anonimowy napisał(a):

Większość ludzi na pewno tego nie polubi bo nie da się opierniczać. Ja chcę sobie zrobić przerwę na obiad kiedy mam ochotę. Chcę zrobić pranie i iść do sklepu jeśli mam potrzebę. Chcę sobie obejrzeć coś na YT i posłuchać muzyki. I to wszystko w trakcie pracy. W PP to nie możliwe

Oczywiście że możliwe - mówisz "robię przerwę" bez pytania kogokolwiek i wychodzisz.

Firma w której spędziłem prawie rok da się podpiąć pod kategorię fang. Zatrudniają 15k ludzia, oddziały rozsiane po świecie, rekrutacja kilkustejdżowa skupiona na algorytmach, live codingu, etc.

Swego czasu spółka dyrektory wysyłały sporo projektów do Indii. Tam wszystko się rozjeżdżało więc delegowali swoich aby nadzorowali towarzystwo. Jak przyszedł covid podróże były ograniczone to ktoś odświeżył pomysł pseudo-pair-programmingu.

Miej więcej polegało to na tym, że jakiś senior z Europy czy z Jueseja otwierał rano calla z kilkoma ziomkami z Indii aby ci pisali pod jego okiem kod aplikacji, deploymenty, skrypty, etc. Call trwał od śniadania do drugiego śniadania, od drugiego śniadania do obiadu, od obiadu do końca roboty.

Pomysł podobno zdał egzamin więc generalnie odświeżano tematy extreme programming. Panowie w białych kołnierzykach doszli do wniosku, że nowe ficzery szybciej powstaną w efekcie pair programmingu.

Kolega z Włoch z którym pracowałem nie miał ochoty na otwieranie calla, a ja nie miałem ochoty uczestniczyć w tej szopcej. Natomiast zdzwanialiśmy się dość często w ciągu dnia aby działo się. Taki maraton utrzymywaliśmy przez dwa tygodnie, trzy tygodnie. Potem pojawiło się elementarne wyczerpanie.

Riddle napisał(a):

anonimowy napisał(a):

Większość ludzi na pewno tego nie polubi bo nie da się opierniczać. Ja chcę sobie zrobić przerwę na obiad kiedy mam ochotę. Chcę zrobić pranie i iść do sklepu jeśli mam potrzebę. Chcę sobie obejrzeć coś na YT i posłuchać muzyki. I to wszystko w trakcie pracy. W PP to nie możliwe

Oczywiście że możliwe - mówisz "robię przerwę" bez pytania kogokolwiek i wychodzisz.

I da się tak pracować 30 minut dziennie a 7 godzin mieć przerwę?

anonimowy napisał(a):

I da się tak pracować 30 minut dziennie a 7 godzin mieć przerwę?

Co do Pair Programming, to jest takie badanie, które przygląda się innym badaniom odnośnie PP -> https://www.researchgate.net/publication/222408325_The_effectiveness_of_pair_programming_A_meta-analysis

Dla niecierpliwych: "Our meta-analysis suggests that pair programming is not uni-formly beneficial or effective, that inter-study variance is high, and that perhaps publication bias is an issue. ", jest też o zastępowaniu seniora, juniorami bez jakiejś utraty poprawności rozwiązania ;-) Nie broniłbym tezy, że PP jest lepsze/gorsze, tylko jak każde narzędzie, czasem się przydaje, ale nie zawsze i nie wszystkim.

anonimowy napisał(a):

I da się tak pracować 30 minut dziennie a 7 godzin mieć przerwę?

Ja tak pracowałem i pomijając upierdliwości, że każdy z pary chce w innym czasie 1 i 2'kę (i może i dobrze jednak, że nie razem), to pair programming jest w uuuuuuj wyczerpujący. Na dłuższą metę, może 4 godziny dziennie byłbym w stanie tak pracować. Reszta to jakieś przerwy inne zadania.

piotrpo napisał(a):

Ja tak pracowałem i pomijając upierdliwości, że każdy z pary chce w innym czasie 1 i 2'kę (i może i dobrze jednak, że nie razem), to pair programming jest w uuuuuuj wyczerpujący. Na dłuższą metę, może 4 godziny dziennie byłbym w stanie tak pracować. Reszta to jakieś przerwy inne zadania.

Powiem więcej - kilka dni po 4 godziny to max. Potem tydzień przerwy od PP.

Ja tak pracowałem i pomijając upierdliwości, że każdy z pary chce w innym czasie 1 i 2'kę (i może i dobrze jednak, że nie razem), to pair programming jest w uuuuuuj wyczerpujący. Na dłuższą metę, może 4 godziny dziennie byłbym w stanie tak pracować. Reszta to jakieś przerwy inne zadania.

@piotrpo U nas wyglądało to tak że pair-programing odbywał się spontanicznie, przy review, lub przy trudnym bugu lub gdy nie wiadomo jak zabrać się za problem. Wtedy jednej osobie się chciało bo to był jej problem, a druga nie miała wyboru :P

Ja piszę o PP proponowanym przez @Riddle (który nie odniesie się do badań przeczących jego tezie)

Nikt wam PP stosować nie każde. Jak to mówią, "Bee's don't waste their time explaining to flies that honey is better than sh**.".