29.11.20227 min
Bulldogjob

Bulldogjob

Jak pracuje pragmatyczny programista?

Sprawdź, jak zostać pragmatycznym programistą. Naucz się słuchać jaszczurczego mózgu i wyjść zwycięsko z walki z samym sobą.

Jak pracuje pragmatyczny programista?

Niniejszy artykuł pochodzi z książki pt. „Pragmatyczny programista. Od czeladnika do mistrza. Wydanie II” Davida Thomasa, Andrew Hunta (Helion 2021) - kod z dobrą zniżką dla czytelników Bulldogjob na końcu artykułu.

Słuchaj swojego jaszczurczego mózgu

Tylko ludzie potrafią bezpośrednio na coś spojrzeć, uzyskać wszystkie informacje potrzebne do dokładnego przewidywania, a czasami dokonać dokładnej prognozy, by następnie jej zaprzeczyć. - Gavin de Becker, Dar strachu

Dziełem życia Gavina de Becker jest pomaganie ludziom, aby się zabezpieczali. Swój przekaz zamieścił w książce "Dar strachu. Jak wykorzystywać sygnały o zagrożeniu, które ostrzegają nas przed przemocą i zapewniają przeżycie".

Jednym z kluczowych poruszonych w niej tematów jest myśl, że ludzie, jako rozwinięte istoty, nauczyli się ignorować naszą bardziej zwierzęcą stronę: nasze instynkty oraz nasz jaszczurczy mózg. Gavin de Becker twierdzi, że większość ludzi, którzy są atakowani na ulicy, jeszcze przed atakiem odczuwa dyskomfort lub zdenerwowanie. Ci ludzie mówią sobie wtedy, że ich obawy są po prostu głupie. Za chwilę z ciemności wyłania się postać…

Instynkty są odpowiedzią na wzorce załadowane do tej części naszego mózgu, którą nie sterujemy świadomie. Niektóre są wrodzone, inne wyuczone przez powtarzanie.

W miarę zdobywania doświadczenia programisty, Twój mózg układa warstwy ukrytej wiedzy: technik, które działają, i takich, które nie działają, prawdopodobnych przyczyn błędów różnego typu — wszystkiego, co dostrzegasz podczas swojej pracy. To właśnie ta część Twojego mózgu każe nacisnąć przycisk Zapisz plik, kiedy zaczynasz z kimś rozmawiać, nawet jeśli nie zdajesz sobie sprawy z tego, że to robisz.

Bez względu na źródło, instynkty mają jedną wspólną cechę: nie wymagają słów. Instynkty sprawiają, że czujesz, a nie myślisz. Kiedy zadziała instynkt, nie zobaczysz migającej żarówki z bannerem owiniętym wokół niej. Zamiast tego staniesz się nerwowy, poczujesz mdłości lub będziesz miał wrażenie, że po prostu masz zbyt dużo pracy.

Sztuką jest najpierw zauważyć co się dzieje, a następnie wywnioskować dlaczego. Na początek przyjrzyjmy się kilku typowym sytuacjom, w których ukryty w Tobie jaszczur próbuje Ci coś powiedzieć. Następnie opowiemy, jak pozwolić wyjść temu instynktownie działającemu mózgowi z jego ochronnej skorupy.

Obawa przed czystą kartką

Wszyscy boimy się pustego ekranu, samotnego migającego kursora otoczonego całą masą niczego. Rozpoczynanie nowego projektu (lub nawet nowego modułu w istniejącym projekcie) może być niepokojącym doświadczeniem. Wielu z nas wolałoby odłożyć na później prace początkowe.

Uważamy, że są dwa problemy, które powodują to zjawisko. Oba mają to samo rozwiązanie.


Twój wewnętrzny jaszczur

Jednym z problemów jest to, że Twój jaszczurczy mózg próbuje Ci coś powiedzieć; istnieje jakaś wątpliwość, która czai się tuż pod powierzchnią percepcji. To bardzo ważne.

Jako programista wypróbowałeś wiele rzeczy i wiesz, które się sprawdziły, a które nie. Gromadzisz swoje doświadczenia i wiedzę. Kiedy odczuwasz dokuczliwe wątpliwości lub doświadczasz pewnych oporów w obliczu zadania, może się okazać, że Twoje doświadczenie stara się do Ciebie mówić.

Uważaj na to. Może nie jesteś w stanie jednoznacznie stwierdzić, co dokładnie jest źle, ale daj sobie czas, a Twoje wątpliwości prawdopodobnie skrystalizują się w coś bardziej trwałego, w coś, czemu będziesz w stanie zaradzić. Niech Twoje instynkty mają wpływ na Twoją wydajność.


Nie chcesz popełnić błędu

Inny problem jest nieco bardziej prozaiczny: może po prostu boisz się, że popełnisz pomyłkę.

To rozsądna obawa. My, programiści, wkładamy w nasz kod dużą część naszej osobowości; błędy popełnione podczas kodowania możemy odbierać jako zwierciadło naszych kompetencji. Być może istnieje w nas również element syndromu oszusta; możemy myśleć, że ten projekt wykracza poza nasze możliwości.

Nie potrafimy dostrzec drogi do celu; dotarliśmy bardzo daleko, a następnie zostaliśmy zmuszeni do przyznania się, że się zgubiliśmy.

Walka z samym sobą

Czasami kod po prostu wypływa z naszego umysłu do edytora: pomysły stają się bitami pozornie bez wysiłku.

Innym razem kodowanie odczuwamy jak spacer pod górę w błocie. Wykonanie każdego kolejnego kroku wymaga ogromnego wysiłku, a po każdych trzech krokach w górę, zsuwamy się o dwa w dół.

Ale będąc profesjonalistą, zachowujesz się jak żołnierz — kroczysz po błotnistym szlaku, masz zadanie do wykonania. Niestety, jest to prawdopodobnie dokładne przeciwieństwo tego, co powinieneś robić.

Twój kod próbuje Ci coś powiedzieć. Mówi, że to zadanie jest trudniejsze niż powinno. Być może struktura lub projekt są złe, może rozwiązujesz niewłaściwy problem, a może po prostu tworzysz mrowisko błędów. Niezależnie od powodu, Twój jaszczurczy mózg wykrywa wnioski płynące z kodu i rozpaczliwie próbuje skłonić Cię do słuchania.

Jak rozmawiać z jaszczurem

Dużo się mówi o słuchaniu instynktów, będącego poza naszą świadomością jaszczurczego mózgu. Techniki zawsze są takie same.

Słuchaj jaszczura, który jest wewnątrz Ciebie.


Po pierwsze przestań robić to, co robisz. Daj sobie trochę czasu i miejsca, aby pozwolić Twojemu mózgowi się zorganizować. Przestań myśleć o kodzie i przez jakiś czas zacznij robić coś, co nie wymaga zbyt wiele myślenia, z dala od klawiatury.

Pójdź na spacer, wyjdź na obiad, porozmawiaj z kimś. Być może się prześpij. Pozwól, by pomysły same przeniknęły przez warstwy Twojego mózgu: nie możesz tego wymusić. W końcu, jak bańka z powietrzem, zdołają przedostać się do Twojej świadomości, a Ty przeżyjesz jeden ze słynnych momentów aha!

Jeśli to nie zadziała, spróbuj uzewnętrznić problem. Zacznij bazgrać na kartce o kodzie, który piszesz, albo opowiedz o nim współpracownikowi (najlepiej takiemu, który nie jest programistą), albo po prostu gadaj do swojej gumowej kaczki.

Przedstaw problem, który starasz się rozwiązać, różnym częściom Twojego mózgu i sprawdź, czy któraś z nich ma lepszy sposób na jego rozwiązanie. Niezliczoną liczbę razy zdarzało się nam, że jeden z nas wyjaśniając problem drugiemu, nagle wykrzyknął „No tak! Przecież to oczywiste!”. Po czym rozwiązał problem, który go dręczył.

Ale być może próbowałeś wszystkich tych rzeczy i nadal tkwisz w martwym punkcie. To czas do działania. Musisz powiedzieć swojemu mózgowi, że to, co masz zamiar zrobić, nie ma znaczenia. Robimy to poprzez prototypowanie.

Przedstawienie czas zacząć!

Obaj (Andy i Dave) spędziliśmy wiele godzin gapiąc się na puste bufory edytora. Pisaliśmy jakiś kod, potem gapiliśmy się w sufit, potem braliśmy kolejnego drinka, po czym pisaliśmy trochę więcej kodu.

Następnie zaczynaliśmy czytać zabawną historię o kocie z dwoma ogonami, po czym pisaliśmy jeszcze trochę więcej kodu, by w końcu wykonać operacje "zaznacz wszystko i usuń", a potem zaczynaliśmy od nowa. I tak w kółko.

Na przestrzeni lat udało nam się znaleźć sposób działania, który wydaje się sprawdzać. Powiedz sobie, że musisz wykonać prototyp. Jeśli widzisz przed sobą pusty ekran, poszukaj jakiegoś aspektu projektu, który chcesz przeanalizować.

Być może używasz nowego frameworka i chcesz się dowiedzieć, w jaki sposób jest w nim realizowane wiązanie danych. A może jest to nowy algorytm, a Ty chcesz się dowiedzieć, jak on działa w przypadkach brzegowych. A może chcesz wypróbować kilka różnych stylów interakcji z użytkownikiem.

Jeśli pracujesz na istniejącym kodzie, który Cię ogranicza, odłóż go na bok i stwórz prototyp czegoś podobnego.

Wykonaj następujące działania.

  1. Napisz na karteczce „tworzę prototyp” i przyklej ją z boku Twojego ekranu.
  2. Przypomnij sobie, że prototypy nie muszą w pełni działać. Przypomnij sobie także, że prototypy się wyrzuca, nawet wtedy, gdy działają. Tworzenie prototypów to same korzyści.
  3. W pustym buforze edytora stwórz komentarz opisujący jednym zdaniem, czego chcesz się dowiedzieć lub co zrobić.
  4. Zacznij kodować.


Jeśli zaczynasz mieć wątpliwości, spójrz na karteczkę.

Jeśli podczas kodowania te dręczące Cię wątpliwości nagle skrystalizują się w wyraźny problem, rozwiąż go.

Jeśli dojdziesz do końca eksperymentu i nadal będziesz czuć się nieswojo, zacznij ponownie od spaceru, rozmowy i odpoczynku.

Ale z naszych doświadczeń wynika, że w pewnym momencie podczas tworzenia pierwszego prototypu, zaskoczy Cię fakt, że zaczynasz nucić do muzyki, którą słyszysz, i zaczniesz odczuwać przyjemność z tworzenia kodu. Nerwowość wyparuje, a zastąpi ją poczucie pilnej potrzeby wykonania zadania!

Na tym etapie wiesz już, co robić. Usuń cały kod prototypu, wyrzuć karteczkę i wypełnij pusty bufor edytora jasnym, błyszczącym, nowym kodem.

Nie liczy się tylko Twój kod

Duża część naszej pracy związana jest z korzystaniem z istniejącego kodu, często pisanego przez inne osoby. Ci ludzie mają inne instynkty niż Ty, a zatem podejmują także inne decyzje. Niekoniecznie są one gorsze — po prostu inne.

Możesz czytać ich kod mechanicznie, przegryzać się przez niego i robić notatki dotyczące rzeczy, które wydają się ważne. To uciążliwa praca, ale przynosi efekty.

Możesz także spróbować eksperymentu. Jeśli zauważysz, że coś zostało wykonane w sposób, który wydaje Ci się dziwny, zrób notatki. Rób tak przez jakiś czas i szukaj wzorców. Jeśli odkryjesz, co było powodem takiego pisania kodu, może się okazać, że zadanie zrozumienia go staje się dużo łatwiejsze.

Będziesz mógł świadomie stosować wzorce, które inni programiści stosowali instynktownie. A przy okazji możesz nauczyć się czegoś nowego.

Nie liczy się sam kod

Ważną umiejętnością podczas kodowania jest zdolność słuchania własnego wnętrza. Ale odnosi się to również do szerszej perspektywy.

Czasami nie podoba Ci się projekt albo jakieś wymaganie sprawia, że czujesz się nieswojo. Poświęć chwilę na przeanalizowanie tych odczuć. Jeśli jesteś w otoczeniu współpracowników, wyraź je na głos. Zbadaj je. Być może coś czai się w ciemnej bramie. Słuchaj swoich instynktów i unikaj problemów, zanim na Ciebie spadną.

Wyzwania

Czy jest coś, o czym wiesz, że powinieneś zrobić, ale to odkładasz, ponieważ Cię to przeraża lub uważasz, że jest zbyt trudne?

Zastosuj techniki opisane w tym tekście. Ustaw timer na godzinę, może dwie, i obiecaj sobie, że gdy zadzwoni dzwonek, usuniesz to, co przez ten czas zrobiłeś. Czego się nauczyłeś?


*Artykuł stanowi fragment książki pt. „Pragmatyczny programista. Od czeladnika do mistrza. Wydanie II” Davida Thomasa, Andrew Hunta (Helion 2021).
Zgarnij swój rabat jako czytelnik Bulldogjob.

<p>Loading...</p>