Jak osiągnąć i utrzymać przepływ podczas programowania w parach?

17

Flow to koncepcja wprowadzona przez Mihaly Csikszentmihalyi; w skrócie oznacza wejście w „strefę”. Czujesz się zanurzony w swoim zadaniu, skoncentrowany; zadanie może być trudne, ale jednocześnie trudne. Kiedy ludzie osiągają przepływ, ich produktywność wzrasta. Programowanie wymaga dużej koncentracji umysłowej, ponieważ często musimy żonglować kilkoma rzeczami w naszych umysłach. Wielu lubi pracować w cichym otoczeniu, w którym mogą skupić całą swoją uwagę na zadaniu. Jeśli zostaną przerwane, powrót do przepływu może potrwać kilka minut lub nawet godzin.

Rozumiem, że w zwinnym programowaniu i ekstremalnym programowaniu jest praktyka zwana programowaniem par. Oznacza to, że umieścisz cały zespół programistów w jednym pokoju, aby komunikacja była płynna. Piszesz kod ze swoją parą, ponieważ w ten sposób otrzymujesz natychmiastowe recenzje kodu i mniej błędów.

Zawsze miałem problemy z osiągnięciem przepływu podczas programowania par z powodu ciągłych zakłóceń. Zastanawiam się głęboko nad problemem, a potem nagle ktoś zadaje mi pytanie od innej pary. Mój tok myślenia został utracony.

Jak osiągnąć i utrzymać przepływ podczas programowania w parach?

siamii
źródło
4
Nie zgadzam się, że inne pary mogą po prostu przeszkodzić w dowolnym momencie.
JeffO
3
Alternatywą dla Flow jest identyfikacja i utrzymanie pozycji na szczycie Ballmer . Osiągnięcie tego może zająć sporo czasu, eksperymentów i szkockiej.
Hovercraft Full Of Eels
Rozprasza mnie czytanie tego pytania, kiedy powinienem pisać kod. Gdybym programował z kimś w parach, nie otworzyłbym tego pytania, aby je przeczytać, i prawdopodobnie wykonałbym więcej.
TehShrike,

Odpowiedzi:

15

Edycja: Oświadczenie - w ten sposób definiuję „strefę”: A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

Staram się unikać tego stanu, ponieważ chociaż mogę tworzyć poprawny kod w strefie, ja i inni programiści będą mieli trudności z jego zrozumieniem. Krótko mówiąc: odczytanie kodu, który został napisany w strefie, może często wymagać od czytelnika przebywania w strefie. To ograniczenie jest moim problemem.

Jest piękny rozdział na temat Czystego kodera, w którym wujek Bob przekonująco wyjaśnia, dlaczego „wejście w strefę” jest złym pomysłem.

Oto prawdopodobnie lepsza alternatywa niż „wejście w strefę”: pomyśl prosto i rozważ spokojnie i profesjonalnie, co robisz. Porozumieć się. Podziel się przemyśleniami ze swoim partnerem (partnerami). Zidentyfikuj prawdziwe problemy. Omów możliwe rozwiązania. Możesz nie czuć się nadmiernie skoncentrowany, ale prawdopodobnie podejmujesz dobre decyzje i przystępne projekty.

Jeśli ty i twój partner możecie porozmawiać o tym problemie bez obawy, że jesteście bardzo skoncentrowani, istnieje prawdopodobieństwo, że problem został sprowadzony do jego prostszej natury. To sugeruje, że będziesz w stanie to zrozumieć, kiedy tylko zajdzie taka potrzeba.

Z drugiej strony ... Jeśli potrzebujesz tylko trochę czasu, aby wyprostować głowę (wszyscy czasem to robimy), po prostu weź to. Zbierz myśli. Najpierw rozwiąż problem.

Chodzi o to, że jeśli to zrobisz - nie marnuj tego czasu na pisanie kodu produkcyjnego. Zamiast tego baw się z przykładowym kodem i prototypami. Spróbuj zrozumieć problem, nie zastanawiając się jeszcze nad rozwiązaniami. Kiedy wszystko zrozumiesz i spisasz, przedyskutuj to ze swoim zespołem i partnerem, a nawet gumową kaczką na biurku. Jeśli nadal nie możesz go wypowiedzieć lub nie potrafią tego zrozumieć, dopracuj swoje pomysły. Kiedy już to wszystko przybędziesz - zintegruj cały ten myśl i przykładowy kod w prawdziwe, działające rozwiązanie.

Yam Marcovic
źródło
2
Głosowałbym milion razy, gdybym mógł, profesjonaliści uczą się pracy, niezależnie od tego, czy są „w strefie”, czy nie. Specjaliści mogą pracować z ludźmi przeszkadzającymi im w zadawaniu pytań, z hałasem wokół nich, a także z innymi osobami rozmawiającymi o tym, jak wykonać to samo zadanie, nad którym wspólnie pracują. Nie jestem zainteresowany pracą z prima donnas, którzy muszą mieć specjalne warunki pracy, aby się skoncentrować.
HLGEM,
7
@HLGEM - Nie sądzę, że dostęp do dość miejsca pracy, gdy jest to potrzebne, to zbyt wiele.
JeffO
2
@HLGEM: Oczywiście profesjonalista powinien mieć średnią wydajność w przeciętnych warunkach pracy. Ale z drugiej strony w interesie pracodawcy leży pozwolenie, aby ten sam profesjonalny pracownik pracował w bardzo skoncentrowany sposób, ponieważ może to ogromnie zwiększyć wydajność i jakość.
Giorgio
2
„Wydaje mi się, że ludzie traktują„ strefę ”tak, jakby to była jakaś magiczna szybka poprawka do dobrego rozwiązywania problemów, jak myślący kapelusz.”: Nie, bardziej banalnie, strefa jest stanem koncentracji, w którym jesteś bardziej produktywny ponieważ koncentrujesz się na swoim zadaniu bez rozpraszania uwagi. Strefa nie czyni cię wszechmocnym, a jedynie zwiększa produktywność.
Giorgio
2
@Yam Marcovic: Nie miałem na myśli tego rodzaju produktywności (produkowanie większej liczby kodów o niższej jakości): jeśli ktoś używa izolacji jako pretekstu do robienia tego, czego chce, nie jest bardziej produktywny. Dla mnie przepływ nie oznacza bałaganu, a następnie spisywania dużej ilości kodu, ale raczej systematyczną pracę nad konkretnym zadaniem bez przeszkadzania innym, niezwiązanym z nim zadaniom.
Giorgio
5

Programowanie w parach wymaga czasami okresów izolacji od partnera.

Przykład

Pracujesz razem nad konkretną klasą i zdajesz sobie sprawę, że musisz napisać metodę, która wymaga głębokiej refleksji nad złożoną logiką, ale w przeciwnym razie zwraca przyziemny wynik. Pracujesz razem nad tworzeniem testów jednostkowych dla tej metody i odkładasz zapisywanie tej metody na okres czasu, kiedy pracujesz w izolacji. Po zakończeniu metody wrócisz do siebie jako para i ocenisz wyniki.

Robert Harvey
źródło
Dlaczego implementacja nie powinna odbywać się w programowaniu parowym?
try-catch-wreszcie
5

Odkryłem, że istnieje niewielka klasa problemów, w przypadku których działa programowanie w parach. Na przykład, jeśli pracujesz nad produktem wieloplatformowym, a facet z Winders zaimplementował funkcję wymagającą kodu specyficznego dla systemu operacyjnego, może pomóc facetowi Mac zaimplementować tę samą funkcję w kodzie Maca, podczas gdy facet jeździ.

Jednak z mojego doświadczenia wynika, że ​​programowanie par powoduje nieoczekiwanie spadek wydajności netto. Tak często wydaje się, że płacimy dwóm programistom za wykonanie jednego.

Tak, zmniejsza to przerażającą możliwość, że deweloper może zrobić przerwę wymiany stosu w ciągu dnia roboczego.

IMHO byłoby taniej dla tych firm, które chcą pilnować swoich deweloperów, aby połączyli każdego dewelopera z prywatnym ochroniarzem, aby stanął za deweloperem i uderzył dewelopera pałką, jeśli kiedykolwiek zwolni lub spróbuje osiągnąć szczyt na nieistotnym Strona internetowa.

Jim In Texas
źródło
1
Punkt programowania pary nie powstrzymuje się od zwalniania; to nawet nie byłoby skuteczne. Chodzi o przegląd kodu w czasie rzeczywistym.
Lev
3
@Lev: Sprawdzanie kodu przed zatwierdzeniem jest znacznie wydajniejsze: przegląd zajmuje od kilku minut do pół godziny, zamiast całego dnia roboczego.
Giorgio,
@Giorgio Niezupełnie. Na przykład może się zdarzyć, że popełnisz błąd, a następnie zmarnujesz czas na łapanie go, a dopiero potem przejrzysz kod i zatwierdzisz. Gdybyś zaprogramował parę, twój partner zauważyłby błąd i oszczędził czas debugowania.
Lev
1
@Lev: „Gdybyś zaprogramował parę, twój partner zauważyłby błąd i zaoszczędził czas debugowania.”: Nie ma gwarancji, że błąd zostanie zauważony albo przy programowaniu par, albo przy przeglądach kodu. Na przykład po sześciu godzinach programowania par można być tak zmęczonym, że łatwo przeoczyć błędy.
Giorgio
Oczywiście nie ma gwarancji, ale może pomóc.
Lev
3

Jako programista próbujący dostać się do strefy, będziesz starał się jak najlepiej izolować siebie, aby uzyskać komfort i oczyścić umysł. Dlaczego programowanie parami powinno być inne?

Ty i twój partner powinniście znaleźć środowisko indukujące strefę, które działa dla was obojga. Być może będzie to wymagało kompromisu w niektórych sprawach, ale moim głównym punktem jest to, że środowisko pary powinno być podobne do solo. Wyłącz świat zewnętrzny. Para programuje razem; inne pary (ogólnie inni współpracownicy) nie powinny przeszkadzać (z wyjątkiem krytycznych problemów, polegających na upuszczaniu).

Sarumont
źródło
0

Flow jest świetnym stanem, w którym znasz dokładne kroki w celu rozwiązania problemu. tj. kilka nieznanych niewiadomych. Siedzisz w cichym kącie i odkurzasz rozwiązanie. Jednak większość problemów / historii / funkcji nie jest bardzo jasna, gdy zaczynasz je programować. Zawsze będzie „luka” między oczekiwanym stanem końcowym a tym, jak mózg go „zaplanował”. Nauczysz się wielu rzeczy, kiedy faktycznie to robisz. Twój mózg żongluje

  • Projektowanie kodu

  • Pisanie na maszynie

  • Ucz się nowych rzeczy na temat domeny i kodu

Kiedy programuję sam, próbuję zrównoważyć te rzeczy. Mam skłonność do wchodzenia w „królicze dziury”, gdzie mój błąd utopionych kosztów uniemożliwia mi cofnięcie się o krok i spojrzenie na duże zdjęcie oraz zmianę projektu. Trudno mi też rozmawiać z wyimaginowaną gumową kaczką lub prawdziwą. W końcu jestem w „przepływie”.

Kiedy produktywnie paruję programowanie, dostaję naprzemienne okresy pisania, a następnie okresy myślenia i refleksji. To tutaj ujawnia się wiele ukrytych rzeczy i może pojawić się inny projekt. Jeśli idę do króliczej nory, mój partner z parowania może mnie z tego wyciągnąć. Mówienie / wyjaśnianie czegoś prawdziwemu człowiekowi ma ten cudowny efekt, że w jakiś sposób rozjaśnia twoje myśli. Czasami brakuje mi bycia w „nurcie”, ale myślę, że wnoszę dużo więcej do mojego zespołu, kiedy łączę program, niż kiedy gram solo. Po całym programowaniu! = Pisanie. Programowanie odbywa się w mózgu, a lepsze programowanie dzieje się, gdy dwa mózgi współpracują i krytykują się nawzajem.

uttamkini
źródło