W 1971 roku można było śledzić losy dwóch misji księżycowych wykonanych przez statek Apollo 14 oraz Apollo 15. Gdy amerykanie latali w kosmos, w Polsce uruchomiono pierwszy kolorowy program telewizyjny.
Wracając do meritum, dokładnie w tym samym roku pojawiła się książka Geralda Weinberga. The Psychology of Computer Programming bo ją mam na myśli, to jedna z pierwszych książek, która zapoczątkowała zorientowane na ludzi podejście do informatyki.
Informatyki gdzie oprócz znajomości sposobu dogadywania się z komputerem za pomocą języka programowania ważne staje się także doświadczenie, umiejętności, czynniki osobowości, problemy społeczne w projektach oraz praca zespołowa.
Egoless Programming
Gerald opisał tytułowe Egoless Programming czyli definicję 10 przykazań programowania bez ego. Przykazań które pomagają oddzielić nasze przywiązanie do kodu oraz wiarę w swoje nadzwyczajne umiejętności tworzenia najlepszego kodu w zespole, firmie czy cholera wie gdzie jeszcze.
Chciałbym przybliżyć Ci zasady, które mają już swoje lata. Ciekaw jestem jak wiele z nich uważać będziesz za nieaktualne? Może wręcz przeciwnie? Może każda z nich dalej jest równie ważna?
1. Zrozum i zaakceptuj, że popełnisz błędy
Tworząc oprogramowanie nietrudno o błędy. W wielu przypadkach nie wpływają one na biznes w sposób krytyczny – szybka poprawka, uśmiech i do przodu. Zaakceptuj, że możesz się pomylić. Zrób jednak wszystko aby błędy zostały wychwycone i naprawione przed wdrożeniem na produkcję.
Oprogramowanie pojawia się praktycznie w każdej dziedzinie naszego życia. Niektóre z branż są bardziej wyczulone na błędy – branża finansowa, medyczna, kosmiczna. W tym przypadku prosty błąd może generować straty finansowe lub co gorsza doprowadzić do śmierci człowieka…
Przyzwyczaj się do tego, że podejmowane przez Ciebie decyzje mogą być błędne, że kod który napiszesz, może być błędogenny. To naturalne, każdy się myli. Ważne jednak aby uczyć się na błędach.
2. Nie jesteś Twoim kodem
Napisałeś kod. Jeśli tylko rozwiązuje problem z którym się zmierzyłeś, mamy pierwszy krok do sukcesu. Idąc dalej – może on być dobry, średni lub w ogóle o kant dupy rozbić. Zweryfikuje ten fakt Code Review.
Nie bierz komentarzy nt. kodu do siebie. One dotyczą kodu, a nie Ciebie i Twojej osobowości.
Fakt, kod może obnażać Twoją niewiedzę, ale to inny temat.
3. Niezależnie od tego, ile wiesz, ktoś inny zawsze będzie wiedział więcej
Nie ważne ile będziesz się uczył, pracował oraz przekazywał swoją wiedzę. Zawsze znajdzie się ktoś od kogo to Ty będziesz mógł nauczyć czegoś nowego. W kontekście wypracowanych metod, doświadczenia czy najzwyczajniej wiedzy w danym temacie. Warto czerpać wiedzę od takich osób, nie zamartwiając się, że ciągle „nie jestem najlepszy”. Nigdy nie będziesz. Jednak zawsze możesz uczyć się od lepszych.
4. Nie przepisuj kodu bez konsultacji
Przeprowadzanie refaktoryzacji na większą skalę (powiedziałbym, że wszystko co dotyczy więcej niż jednej metody) powinno być omówione z członkami zespołu. Nie zawsze nasze pomysły przynosić będą wartość dodaną w projekcie, a nawet jeśli to warto przedstawić swój sposób rozwiązywania problemu. Między innymi w celu wymiany wiedzy.
Dodatkowe korzyści wynikają także z rozdzielania zmian związanych z refaktoryzacją, poprawianiem błędów oraz implementacją nowych funkcjonalności – wspomniałem już o tym przy okazji zasady skautów. Ważne jest aby rozumieć różnicę pomiędzy błędami i implementacją, a refaktoryzacją. Mieszanie takich zmian ze sobą może implikować dodatkowe kłopoty, a dokładniej – błędy.
5. Traktuj osoby z mniejszą wiedzą z szacunkiem, poważaniem i cierpliwością
Młodszy programista, gość z biznesu. Tych ostatnich uwielbiasz najbardziej bo zaginasz ich technicznym sloganem. Nic nie wiedzą, nie znają się i przeszkadzają w pracy. Nawet jeśli pojawiają się takie ewenementy to nie pogarszaj sytuacji. Edukuj, tłumacz, toleruj, trzymaj swoje zdenerwowanie na wodzy. Wiem, jest to ciężkie, samemu zdarza mi się zmieszać z błotem ewidentnie głupie decyzje… Decyzje – nie persony.
Każdego współpracownika traktuj z identycznym szacunkiem. Dla kogoś innego to Ty możesz być tym „słabym gościem od JSa”. Nie zadzieraj nosa w górę i staraj się rozmawiać i traktować każdego w rzetelny sposób.
6. Jedyną stałą na świecie jest zmiana
Ile razy dostałeś białej gorączki bo zmieniły się wymagania funkcjonalności? Przecież wszystko idealnie działało, zostało zaprogramowane zgodnie z wszelkimi dobrymi praktykami, dziesiątki testów jednostkowych, Clean Code… Na nic to jeśli wymagania klienta się zmieniają, kiedy zmienia się jego biznes. To nie miejsce na puszczanie focha. Taka jest natura rozwoju oprogramowania.
Kolejnym elementem jest nasza zmiana, w postaci zmiany języka programowania, wykorzystywanych narzędzi lub metodyk. Nie zawsze raz obrany kierunek, będzie właściwy aby dotrzeć do celu.
7. Jedyny prawdziwy autorytet wynika z wiedzy, a nie ze stanowiska
Zmiana pracy bo staniesz się Technical Leader? Awans na Software Architect? Wpadasz jako Technical Advisor do projektu? Czujesz dumę, nikt Ci nie podskoczy… Czy jednak słusznie? Gówno prawda. Tak jak każdy nowy członek budujesz zaufanie oraz szacunek w swoim nowym otoczeniu. Możesz zarządzać ale jeśli zespół wyczuwa, że nie potrafisz tego robić staniesz się pośmiewiskiem.
Graj w otwarte karty:
- Znam odpowiedź, wiem = wypowiadam się.
- Nie znam tematu = postaram się go zbadać lub przekieruję Cię do odpowiedniej osoby.
Udowadniasz, że jesteś prawdziwy, nie starasz się grać kogoś innego.
Pamiętaj, że swój wizerunek budujesz swoją wiedzą, umiejętnościami, podejściem do pracy oraz doświadczeniem. Nie etykietą czy rolą, którą nadała Ci korporacja. Nie musisz wiedzieć wszystkiego, to normalne. Ważne abyś wiedział jak się zachować, przekierować temat dalej czy po prostu odpowiedzieć na tyle na ile jesteś w stanie. Twoja rola w tym momencie nie gra roli.
8. Walcz o to, w co wierzysz, ale z wdzięcznością przyjmij porażkę
Podejmowanie decyzji projektowych bywa ciężkim orzechem do zgryzienia. Zdarza się, że Twój pomysł, który wydaje się tym najlepszym zostaje odrzucony. Z różnych względów – za długi czas implementacji, mało wydajny, zbyt skomplikowany, brak odpowiednich umiejętności w zespole i długo by wymieniać.
Nawet jeśli pierwotnie wybrane rozwiązanie zaczyna zawodzić i potencjalnie Twój pomysł sprawdziłby się lepiej, unikaj stwierdzenia „a nie mówiłem”. To nie ma sensu. Lepiej skupić się na rozwiązaniu problemu niż bezsensownym marudzeniu.
Dodałbym także, aby nie traktować takich rzeczy w kategorii porażki, raczej – podejmujemy wspólną decyzję, która ma przybliżyć nas do rozwiązania problemu. Pomysł na pewno był dobry, może wykorzystacie go w innym przypadku.
9. Nie bądź „jakimś gościem w pokoju”
Nie bądź tylko „zasobem ludzkim” czy „spalaczem ticketów„. Bądź częścią zespołu, wnosząc do niego wartość. Każdy z nas ma wypracowane pewne standardy komfortowej pracy, znam osoby dla których praca w słuchawkach poprawia wydajność. Ważne jest aby te słuchawki ściągać podczas dnia, rozmawiać i integrować się z resztą zespołu, resztą osób które pracują w tym samym miejscu. Zauważyłem, że alienacja bardzo szybko prowadzi do wykluczenia i najzwyczajniej w świecie – zmiany projektu lub pracodawcy.
Dodam jeszcze, że inspiracja pojawia się wszędzie, czasem na fajce albo w kuchni podczas pogawędki przy kawie.
10. Krytykuj kod, nie ludzi
Proces Code Review dotyczy kodu, o tym dobrze wiemy. Komentarze, które zostawiane są przez programistów w ramach tego procesu także dotyczyć powinny kodu. Gdybym miał opisać ich charakterystykę to na pewno powinny być nastawione na polepszenie kodu oraz wyrażone w sposób pozytywny.
Gdy czegoś nie rozumiemy, dopytujemy dlaczego coś wygląda w taki, a nie inny sposób. Gdy coś jest słabe, daremne, chujowe – zaproponuj zmianę, która usprawni rozwiązanie. Nie wyzywaj osoby, która napisała kod – jest wiele powodów przez które rozwiązanie wygląda nie tak jak tego oczekiwałeś.
Jeśli masz zamiar zwyzywać to zrób to w odniesieniu np. do wykorzystanego języka programowania, komplikującego potencjalnie proste zadanie 😉
EOT
Jak przerabiałem Egoless Programming miałem wrażenie, że czytam artykuł napisany całkiem niedawno. Mocno żałuję, że nie trafiłem na niego 10 lat temu, gdy rozpoczynałem swoją zawodową przygodę. Kilka z podpunktów mogłoby mnie naprowadzić na te „bardziej pożądane” zachowania dużo szybciej niż miało to miejsce. Dlatego poleciłbym szczególnie te 10 rad wszystkim osobą, które zaczynają swoją przygodę w IT, chociaż tym, którzy spędzili już w branży nieco lat też się przyda 🙂
Mówią, że książki w IT szybko się dezaktualizują. Na pewno tak jest z książkami dotyczącymi konkretnych frameworków, języków, które ciągle się rozwijają. Natomiast same koncepty żyją o wiele dłużej, pierwszy przykład z brzegu – programowanie obiektowe. Z Egoless Programming jest podobnie, z samą książką The Psychology of Computer Programming również. Może warto do niej wrócić?
Co o tym sądzisz?
Wykorzystano zdjęcia dostępne na licencji Creative Commons z następujących źródeł: 1, 2, 3, 4, 5.
