Efektywność programisty

Nie możesz być efektywny, jeśli jesteś chory, niewyspany ani naburmuszony; nie będziesz dobrze pracowała, jeśli będziesz zbyt wrażliwa na krytykę, niepewna swoich umiejętności czy kłótliwa.

Praca prorgamisty nad efektywnością to w zasadzie praca człowieka nad sobą: to praca o bardzo szerokim zasięgu - zaczynasz od małych nawyków, ale procent składany robi robotę i w pewnym momencie zauważasz, że rosną Ci skrzydła (czego Tobie - i sobie - życzę).

Efektywność obejmuje wiele płaszczyzn:

• fizyczną (twoje zdrowie, kondycję ciała, związaną z nią kondycję mózgu)
• intelektualną (umiejętności, doświadczenie, horyzont poznawczy, wiedza i świaadomość jej granic)
• psychiczną (działanie pomimo lęku, podejmowanie odpowiedzialności tam, gdzie nikt jej nie podejmuje, regulacja emocji)

Nie dotyczy więc jedynie strefy programowania, ale w zasadzie całego życia. Zaniedbanie obszarów związanych z twoją fizycznością z pewnością nie poprawi sprawności intelektualnej, dlatego zawsze myśl o sobie jako o całości: jestem prorgamist(k)ą, liderką/liderem, matką/ojcem, kobietą/mężczyzną, człowiekiem na raz.

Działaj mądrze.

Jak być bardziej efektywnym

Rozwój odpowiedniego nastawienia mentalnego

Istnieją cechy tzw. “soft-skillowe”, których kultywowanie pozwala na dużą poprawę efektwności w życiu zawodowym: proaktywność, nieustępliwość, komunikatywność, pokora.

Wyobrażam sobie, że jestem wysoce efektywnym programistą… Jak myślę, aby kultywować powyższe cechy?

proaktywność

• wychodzę z inicjatywą, aby poprawić zastaną sytuację
• działam tam, gdzie coś ode mnie zależy
• myślę, co mogę zrobić sama
• sprawdzam, kogo spytać o najlepszy kierunek działania
• jeśli coś ode mnie nie zależy - weryfikuję to założenie: przyjmuję założenie, że się mylę i właściwie to ode mnie jednak zależy
• porażka to moja stara, dobra kumpela; lubię się od niej uczyć

nieustępliwość

• nie ustaję na drodze do rozwiązania problemu
• próbuję różnych opcji
• pytam innych o zdanie, podpowiedzi, sugestie
• trzymam się zasady: jeśli przez godzinę nic nie mogę wymyślić i tkwię w miejscu, proszę innych, aby mnie “popchnęli” - podpowiedzieli, co mogę zrobić w tej sytuacji

komunikatywność

• nigdy nie obawiam się pytania innych o zdanie/wskazówki/priorytety
• nie martwię się, że zostanę uznana za osobę mało kompetentną - tylko słabi, kiepscy menadżerowie będą na to krzywo patrzeć
  • robię więc to, co powinnam robić: pcham sprawy naprzód, rozwijam kontakty/umiejętności, próbuję rozwiązać problem,
  • nie unikam trudnych tematów
  • nie udaję, że problem nie istnieje
  • nie udaję, że wiem, co robić, kedy nie wiem

pokora

• w stosunku do innych, bardziej kompetentnych osób
  • uznaję to, że są na innym etapie niż ja
  • wykorzystuję ich wiedzę, uczę się
  • przedstawiam im swoje opinie i słucham ich argumentów
  • masz prawo się nie zgadzać
  • ale nie upieram się przy swoich pomysłach “co do zasady”
• w stosunku do własnych umiejętności:
  • dopuszczam do siebie myśl, że może nie są one tak wysokie, jak mi się wydaje (efekt Dunninga-Krugera)
  • zadaję sobie pytanie: a co, jeśli się mylę? a co, jeśli druga osoba ma rację?
  • zakładam z góry, że popełnię błąd i buduję fortecę ochronną:
    • weryfikuję dane wejściowe
    • piszę kod testowy
    • projektuję API tak, aby jego użycie było proste i zawsze poprawne (niezależnie od kolejności wywołań)
    • dyskutuję mój projekt - najlepiej z osobą, którą uważam za mądrzejszą od siebie

Rozwój w dziedzinie programowania

Dbaj zarówno o poszerzanie swoich horyzontów jak i zgłębianie zagadnień, które szczególnie cię interesują.

Oto kilka porad:

Poszerzanie horyzontów

• znasz programowanie obiektowe - dowiedz się, czym jest programowanie funkcyjne, poczytaj o rachunku lambda (hmm…), pobaw się Lispem - polecam Clojure;
• przejrzyj tematy backend developer roadmap lub inne roadmapy
• myśl zanim zakodujesz
  • użyj kartki i ołówka jako podstawowych narzędzi projektowania
  • rysuj diagramy, myśl wizualnie
• poznaj różne języki programowania
  • co roku naucz się jednego nowego języka programowania
  • przejrzyj bibliotekę standardową języka, napisz mały program
• buduj pet projekty (nauka języka, POC)
  • zrób mały “projekt na boczku” aby nauczyć się nowego API, poznać możliwości biblioteki czy dać się wywołać jakiemuś frameworkowi
• dołącz do projektu open source
  • jeśli używasz jakiegoś otwartego (w znaczeniu open source) projektu, języka, biblioteki lub pluginu, istnieje spora szansa na to, że masz dostęp do repozytorium
  • zapoznaj się ze źródłami, spróbuj ten projekt zbudować oraz zastanów się, jak możesz pomóc w jego rozwoju
• poznaj i używaj skrótów klawiszowych
  • staraj się nie używać myszki, poznaj skróty klawiaturowe w swoim IDE
  • wytrzymaj początkowe zniechęcenie i wytrwale ucz się tych skrótów, choć na początku z pewnością będziesz pracować wolniej
  • ROI jest tego warte
• szybkie pisanie na klawiaturze
  • jeśli masz czas, możesz trenować swoją szybkość pisania kodu na klawiaturze;
  • szybkie pisanie przydaje się nie tylko podczas kodowania; na pewno przyda się podczas pisania dokumentacji, wpisów na bloga czy newsletterów

Dbanie o własne zasoby

• Praca 8-16:
  • napij się wody; nie czekaj aż będzie ci się chciało pić (chcesz pić wtedy, kiedy jesteś odwodniony tak bardzo, że ciało zaczyna wysyłać Ci sygnały alarmowe: suche gardło, skóra, pieczenie oczu)
  • co godzinę rób 5 min (lub co 2 godziny rób 10 min) przerwy
    • wyjdź na słońce jeśli możliwe
    • rób ćwiczenia oddechowe
    • porozciągaj się
    • dbaj o oczy: popatrz w dal, zakryj oczy dłońmi
    • i nie myśl o pracy! - poczytaj, zagraj w grę, obejrzyj filmik; odwróć uwagę od pracy
  • ergonomia:
    • proste plecy, dobre oświetlenie, wygodny fotel, klawiatura, mysz, podkładka
    • eksperymentuj ze sprzętem
• Po pracy
  • dbaj o swoją dietę
  • rozważ regularne posty, intermittent fasting, dietę keto, detox
  • zaplanuj czas na czytanie książek
  • zaplanuj czas na spacer (lub idź na spacer zaraz po pracy)
  • zapewnij sobie odpowiednią ilość snu
  • kontroluj używki (kawa…)
  • raz w roku zrób badania moczu, krwi, lipidogram, badania wątrobowe , pomiar ciśnienia, badanie składu ciała; rób teżbadania specyficzne dla płci (cytologia, mammografia dla pań, usg jąder, badanie prostaty u panów)
  • jeśli jesteś po 40 roku życia, znajdź czas na ćwiczenia oporowe

Dbanie o kod:

• naucz się radzić sobie z krytyką podczas code review - bądź mniej defensywny, nie broń rozwiązań, które są niespójne z resztą kodu, ale używają Twoich ulubionych (a może nawet obiektywnie lepszych) konstrukcji językowych bądź wzorców
  • odnajdź dokument opisujący konwencje kodu; jeśli takiego nie ma, zaproponuj jego wprowadzenie
  • wyrób sobie zwyczaj przeglądania zmian przed git commit oraz puszczania testów przed git push
  • poświęć czas na zapoznanie się z bazą kodu

Dodatki

Jak zapoznać się z nową bazą kodu

• patrz na pliki dotfiles - pozwolą szybko zorientować się z jakich narzędzi kod korzysta
• przejrzyj plik z konfiguracją narzędzia do budowania kodu (Maven: pom.xml , Gradle: build.gradle, Cargo: cargo.toml itd.)
• zapoznaj się z plikiem README
• popatrz na ogólną strukturę katalogów:
  • czy jest to projekt jedno- czy wielomodułowy?
  • czy używane są moduły javy?
  • gdzie mieszkają testy jednostkowe, a gdzie testy integracyjne?
• używaj narzędzi takich jak grep czy ripgrep, aby zidentyfikować “punkty wejścia”
  • w klasycznych aplikacjach poszukaj funkcji main()
  • w aplikacjach webowych: implementacje interfejsu Servlet lub klasy dziedziczące to HttpServlet
  • przejrzyj inne możliwe punkty wejścia w Springu: adnotacje @RestController @Controller, @Listener)
• otwórz projekt w IDE i spróbuj go zbudować; może się to nie udać z wielu powodów
  • nie możesz się zautoryzować w zdalnym repozytorium pakietów
  • używasz niewłaściwej gałęzi kodu
  • nie masz zainstalowanych narzędzi (maven/gradle, git)

Jak wprowadzić code conventions

Poniższe zasady były pisane z myślą o pisaniu kodu w Javie, jednak ich charakter jest dość ogólny i można je zaadaptować do innych języków

Jeśli musisz, to zrób to tak..

Być może nic nie trzeba wprowadzać. Odpowiedz na początku na kilka pytań:

• czy wprowadzanie czegokolwiek jest konieczne?
  • może już teraz kod jest skanowany narzędziami typu SonarQube, który używa zbioru reguł, których nie jesteś świadomy?
• czy taki dokument istnieje w bazie wiedzy zespołu/firmy?
• czy jest dostępna konfiguracja IDE której można użyć?
• czy istnieją spisane inne zasady…
  • dotyczące architektury, podziału na pakiety, upubliczniania klas, użycia interfejsjów etc?
  • dotyczące utrzymania plików pom.xml (patrz zbiór reguł dla maven-enforcer-plugin pomagający w tym zadaniu) ( zwykle podstawowy # Oracle’s Java Code Conventions lub Google’s Java Style Guide coding convention?) Jeśli tak, należy poświęcić trochę czasu na sprawdzenie, czy istniejące dokumenty są aktualne, zweryfikować (z liderem technicznym) ich jakość, określić, czy potrzebne są w nich jakieś zmiany.

…aby nikt nie musiał nic robić

Najlepiej wprowadzić wymagania dotyczące konwencji w taki sposób, aby nikt nie musiał nic (albo prawie nic) robić.

• automatycznie weryfikuj bazową jakość kodu:
  • w czasie rzeczywistym (wymaga wsparcia ze strony środowiska IDE)
  • podczas budowania (pluginy w systemie budownaia)
  • podczas komitu kodu (git hooks, autowamtyczne akcje w IDE)
  • jako część procesu CI/CD
• ustal zasady przeprowadzania code review
• udokumentuj ustalenia na stronie projektu / wiki
• zaplanuj kwartalne spotkanie związane z omówieniem problemów wokół utrzymania jakości kodu
• na końcu poinformuj zespół i, jeśli to konieczne, przekaż (minimalną) listę zadań do wykonania:
  • podaj link do wiki
  • pokaż, jak podpiąć plik z regułami do IDE

Warte przeczytania: Coding Standard and Programming Best Practices for Java.

Podsumowanie

To ostatnia część serii Minikurs Efektywności. Dziękuję, że dobrnęłaś/dobrnąłeś aż tutaj.

Pamiętaj, że bycie efektywnym programistą nie polega na osiągnięciu pewnego stanu docelowego, ale na ciągłym doskonaleniu swoich umiejętności, poprawianiu istniejących procesów, kwestionowaniu założeń projektowych (oraz swoich własnych przekonań) oraz pokonywaniu swoich słabości.

Wszyscy jesteśmy ludźmi. Niektórzy są technicznie dużo lepsi niż inni. Niektórzy są dużo bardziej rozmowni i ogarniają biurokrację (uważam, że szczególnie im powinniśmy być wdzięczni - bo czy chcielibyśmy się z nimi zamienić?). A jacy jesteśmy my? A jakimi chcemy się stać?

Dzielimy często ludzi na introwertyków i ekstrawertyków, a do tego bardzo chętnie sami chowamy się za jedną z tych etykietek. A może warto wyjąć się za uszy z tych szufladek i zapytać się samego/samej siebie:

• jak mogę stać się osobą, która - kiedy coś mówi - mówi tak, aby dawać innym siłę i inicjuje ich sprawczość?
• jak mogę stać się osobą, która - kiedy działa - zmienia świat tak, aby stawał się lepszym miejscem?

Życzę Ci spokojnej determinacji w ulepszaniu świata i mądrej wyrozumiałości dla wad innych ludzi.

Pozdrawiam Cię serdecznie,

Kamila

Ten wpis jest częścią serii Minikurs Efektywności.