Jakie nawyki profesjonalnych programistów powodują, że rozwijają się szybciej? Z jednej strony, kariera niektórych przypomina wystrzał z procy, podczas gdy inni walczą o przetrwanie na stanowisku, na którym zostali zatrudnieni. Pamiętam jak 8 lat temu, bliżej było mi do tej drugiej grupy. Do dziś nie zapomnę, niekompilującego się kodu zacommitowanego ¹ do repozytorium, sabotującego prezentację mojego project managera przed klientem. Innym razem, mój ówczesny team lider, spytał jaką szkołę kończyłem. To pytanie bynajmniej nie miało doprecyzować czy było to MIT, czy Princeton. Miało tylko i wyłącznie zaspokoić jego ciekawość – jaka uczelnia wypuszcza takie miernoty.
Do samych porażek i błędów, obiecuję jeszcze kiedyś wrócić w osobnym wpisie, tymczasem skupmy się na głównym wątku tego artykułu. Czy wszystko zależy od tego jak dobry kod piszemy? W dużej mierze tak, ale ten oraz pozostałe artykuły z tej serii skupią się na nieco innych aspektach. Opiszę subiektywną listę nawyków, które znacząco pomogły mi w początkach mojej kariery, dzięki radom jakie uzyskałem od moich ówczesnych mentorów. Znajdą się też tutaj uwagi, które przekazałbym sobie sprzed 8 lat, gdybym tylko był jakiś sposób…
Ten wpis jest częścią serii „Nawyki Dzięki Którym Przyspieszysz Swoją Karierę Junior Java Developera„ Początkowo miał to być jeden wpis z listą wszystkich nawyków. Z racji na dużą ilość treści jaką chciałem w nim zawrzeć, zdecydowałem się na architekturę mikro wpisową 🙂 O reszcie nawyków przyspieszających karierę będzie można przeczytać w kolejnych wpisach, które podlinkuję również do tego artykułu.
O wszystkich nawykach przeczytasz tutaj:
1. Bądź odpowiedzialny
2. Komunikuj się efektywnie
Bądż odpowiedzialny
Bycie odpowiedzialnym oraz zrozumienie i zaakceptowanie roli jaką odgrywają nasze wybory w tym co się dzieje, są kluczowymi oznakami dojrzałości emocjonalnej i moralnej. Dlatego odpowiedzialność jest jednym z głównych filarów dobrego charakteru. Ok, ale co to ma wspólnego z programowaniem?
Odpowiedzialność jako miara zaufania
Im szybciej przejdziesz z trybu stricte wykonawczego, do roli wychodzącej poza sztywne ramy, skorzystają na tym wszyscy. Idea ta została szerzej opisana we fragmencie książki Debugging Teams
Autor opisuje między innymi jak wygląda idealna sytuacja z perspektywy pracodawcy (oryginał „The ideal employee experience”) Znajdziemy tam również fragment mówiący o braniu dodatkowej odpowiedzialności. Dobrze to obrazuje przytoczona metafora leśnika juniora, który został wysłany do lasu celem wycięcia kilku chorych drzew. Ograniczając to zadanie tylko i wyłącznie do tego co zostało mu zlecone, ściąłby wspomniane drzewa i powrócił triumfalnie oczekując na kolejne zlecenie.
To co nasz bohater mógłby zrobić oprócz wspomnianej czynności, to spojrzeć na swoje zadanie z szerszej perspektywy. Na przykład, mógłby oznaczyć inne chore drzewa na mapie, które mijał podczas swojej drogi.
Tak przygotowany raport, przekazałby dalej, a to dałoby sygnał, że być może wycinka powinna zostać rozszerzona względem pierwotnego planu.
Takie działania budują zaufanie, dzięki któremu możesz pozyskać ciekawsze i z puntku widzenia projektu, ważniejsze zadania. Wystarczy żebyś robił więcej niż od Ciebie oczekują. Z czasem zobaczysz, że takie podejście procentuje większą renomą budowaną w okół swojej osoby.
Kilka przykładów:
- dostałeś zlecenie rozbudowania pewnej funkcjonalności i poza rozbudową dopisałeś kilka testów jednostkowych, których brakowało w tej części systemu,
- przed naprawą błędu napisałeś test jednostkowy, który będzie weryfikował, że błąd ten nie wróci za jakiś czas podczas kolejnego refactoringu,
- usunąłeś kilka nieużywanych bibliotek podczas konfiguracji skryptu mavenowego generującego raport.
Idealny kod to nie taki w którym nic nie da się już dodać ale taki z którego nic już nie można usunąć.
Wracając jeszcze na chwilę do samego źródła. Książka jest niezła, porusza ciekawe aspekty pracy zespołowej. Na pewno bardziej przydatna na kolejnych stopniach twojej kariery. Kierowana jest głównie do liderów ale myślę, że i osoby z mniejszym doświadczeniem wyciągnęłyby coś dla siebie.
Odpowiedzialność za porażki i mierzenie się z konsekwencjami
Na odpowiedzialność można spojrzeć też z nieco innej strony. Mianowicie, bycie odpowiedzialnym za swoje działania i mierzenie się z ich konsekwencjami. To drugie wydaje mi się, trudniejsze. O ile w pierwszym przytoczonym przykładzie brania większej odpowiedzialności pomaga ambicja, w drugim musimy wykazać się większą pokorą.
Polecam książkę Extreme Ownership, która w niesztampowy sposób porusza ten temat w pierwszym rozdziale. W skrócie, chodzi o to aby brać odpowiedzialność za całość swoich działań. My ludzie, często mamy tendencje do szukania wymówek, usprawiedliwień jeżeli tylko jest jakaś ku temu okazja. Jocko Willink udowadnia, że można inaczej i mimo iż jest to z reguły trudniejsza droga, buduje podwaliny pod nasz profesjonalizm.
Cała książka jest rewelacyjna i z pewnością jeszcze kiedyś zostanie przytoczona na łamach tego bloga. Sama forma również może przypaść ci do gustu. Każdy rozdział zabiera nas w wir wojny. Rzuca w samo centrum pola bitwy, gdzie na bieżąco musimy mierzyć się z niezwykle trudnymi decyzjami. Autor przytoczonymi historiami daje nam lekcje, które my cywile, możemy zaaplikować w spokojniejszych, mniej ekstremalnych niż wojna, realiach. Takie przykłady znajdziesz w drugich częściach każdego z rozdziałów.
Polecam ci również audiobooka, który jest profesjonalnie zrealizowany, czytany przez samych autorów.
https://www.audible.com/pd/Extreme-Ownership-Audiobook/B015TVHUA2
Na rozgrzewkę wrzucam krótki TEDx w którym Jocko Willink streszcza przytoczony termin Extreme Ownership.
Odpowiedzialność miarą profesjonalizmu
Na sam koniec wspomnę o jeszcze jednym aspekcie, który nie sposób pominąć w kontekście odpowiedzialności. Jako profesjonalista i wyznawca manifestu rzemiosła programistycznego, powinniśmy pamiętać, że to my jesteśmy odpowiedzialni za jakość dostarczanego oprogramowania. Myślę, że warto przytoczyć tutaj cały manifest w ramach tego wpisu:
Jako ambitni twórcy oprogramowania podnosimy poprzeczkę profesjonalizmu w naszym zawodzie przez praktykę i pomaganie innym w uczeniu się rzemiosła. W naszej pracy zaczęliśmy doceniać:
– Nie tylko oprogramowanie działające, ale również dobrze wykonane
– Nie tylko reagowanie na zmiany, ale również ciągłe dodawanie wartości
– Nie tylko ludzi i interakcje, ale również społeczność profesjonalistów
– Nie tylko współpracę z klientami, ale również efektywne partnerstwo
Zdaża się, że programiści ulegają naciskom ze strony biznesu, w efekcie ucinają zakres testów czy godzą się na odrealnione estymaty. Jeżeli nie chesz być tylko narzędziem w rękach innych powinieneś podchodzić do pracy jak profesjonalista. Czy słyszałeś aby licytowano się z chirurgiem pod względem czasu ile będzie trwała operacja? Tak, wiem od kulawego CRUD’a jeszcze nikt nie zginął, ale czy na pewno? Pamiętajmy jak to mawiał Marc Andreessen, że
Oprogramowanie zjada świat
źródło
Software zyskuje na co raz to krytyczniejszych aspektach naszego życia. To po naszej stronie leży odpowiedzialność zadbania o to aby auto autonomiczne nie zrobiło nikomu krzywdy,
a błąd oprogramowania w samolocie nie spowodował katastrofy w przestworzach.
To nie do końca błąd oprogramowania lub jest to tylko niewielka składowa. Warto jednak abyś zapoznał się z materiałem, ponieważ w ciekawy sposób podsumowuje ostatnie wydarzenia związane z samolotami Boeinga. Zobaczysz jak problemy, które kiedyś rozwiązywał hardware, dziś w całości mogą zostać obsłużone przez kod.
Podsumowanie
W tym wpisie przybliżyłem Ci pierwszy z nawyków profesjonalnego programisty, dzięki któremu, możesz przyspieszyć rozwój swojej kariery. Przedstawiłem odpowiedzialność w trzech różnych aspektach
- ambicja – bierz większą odpowiedzialność, pokaż, że można Ci zaufać
- konsekwencje – bierz odpowiedzialność za porażki i zmierz się z konsekwencjami jak przykre by one nie były
- profesjonalizm – bierz odpowiedzialność, za kod który piszesz, oraz konsekwencje wynikające z niego
W kolejnych wpisach poruszymy kolejne nawyki nadające rozpędu twojej karierze programisty, do usłyszenia!
¹ commit – dziś, większość osób powiedziałaby, co to za problem, przecież commit nie wdraża rzeczy. Lata 2011 to nadal czasy, gdy w Polsce króluje svn, gdzie commit, jest równoznaczny z wdrożeniem zmian. Jak dobrze, że te czasy mamy już za sobą i dziś możemy cieszyć się benefitami jakimi raczy nas git. Wiem, wiem nieco idealizuje. Svn ma się dobrze w wielu projektach i jeszcze minie trochę lat zanim zostanie wypleniony z niektórych firm. A może to właśnie Ty podejmiesz się tego zadania? 🙂