Słaby kod na GitHubie jest mocną stroną Twojego CV

zycienakodach.pl 3 lat temu

Twarz Kevina, użyta na grafice powyżej, została wycięta ze sceny z filmu „Home Alone”.

Z życia na kodach

CV, które nadesłał kolejny kandydat do zespołu, wyglądało wspaniale! Przez chwilę nadeszła nowa nadzieja, iż w końcu znajdziemy kogoś odpowiedniego. W tych czasach niezmiernie ciężko znaleźć dobrego programistę. Jak na developera przystało, zamieścił też link do GitHuba. Niestety… co my tu mamy? Same stare projekty — ale no cóż… otwieram pierwszy z brzegu, jakiś sprzed niecałego roku. Wchodzę w katalog „tests” a tutaj… pustka, nicość, po prostu jeden wielki .gitignore i nic więcej. Moje przerażenie, iż mógłbym z kimś takim pracować, jest większe niż Kevina schwytanego przez mokrych bandytów! Być może znowu byśmy przyjęli developera, który nie umie pisać testów, gdyby nie ja — ten wścibski dzieciak. Czuję się właśnie, jakbym zdemaskował kolejnego potwora, niczym ekipa z serii Scooby-Doo. No to dla formalności, żeby odmówić zatrudnienia, została jeszcze konstruktywna krytyka zadania rekrutacyjnego. No to ten sam schemat, pierwsze co zerkam na katalog „tests”, i chwila zawahania się — czy to na pewno ta sama osoba!? Jeszcze chwila spędzona nad kodem i piszę do pani z HRu: “Wiesz co, jednak umówmy się z nim, zanim znajdzie coś innego. jeżeli tak gwałtownie uczy się i rozwija swoje umiejętności, to ja chcę z nim pracować”.

Zdemaskowanie potwora. Scena z serialu Scooby Doo.

Czego się dowiesz

Jak znaleźć osoby, z którymi warto pracować w zespole?
Jak programista powinien postrzegać i pokazać swój rozwój?
Na czym polega heurystyka zmierzenia tempa rozwoju?
Po jakie narzędzia sięgnąć, by planować i mierzyć postępy w nauce i karierze?

A long time ago in a…

Dawno, dawno temu w odległej galaktyce (a w zasadzie na pierwszym roku studiów) mój GitHub roił się od kodu uczelnianych projektów. W przydługawych linijkach na pewno znalazłyby się wszystkie gatunki najbardziej plugawych grzechów programisty. Boskie klasy, niska kohezja, kod spaghetti, a co najgorsze… Puste katalogi z testami! Co pojawiło się w Internecie, zostaje w nim na zawsze. Jak się z tym rozprawić? A może nie warto?

Niech płonie!

Jest kilka metod, by uporać się ze złym kodem, który zaśmieca nasz profil. Pierwsza to wynająć wiedźadmina z dwiema klawiaturami – w błyskawicznym tempie usunie całe zło. A gdyby zamiast tego zdecydować się na trochę prywatności? Od pewnego czasu GitHub umożliwia każdemu utworzenie prywatnych repozytoriów. Nikt nie pozna więc Twojego dawnego programistycznego życia. Co stało się w kodzie, zostanie w kodzie. Ale może lepiej przyznać się od razu, zamiast budować dom z piasku, który runie przy pierwszym spotkaniu z potencjalnym pracodawcą?

Słynna scena z serialu It Crowd.

Dobry kod nie jest wieczny

Gdy zaczynamy się uczyć, wszyscy jesteśmy tacy sami. Wiemy, iż nic nie wiemy. Harry Potter nie od razu umiał wspaniale czarować. Anakin Skywalker, choć od początku skrywał w sobie wielkie pokłady Mocy, to musiał nauczyć się nad nią panować. Tak samo nie każdy Padawan programowania był od razu mistrzem we władaniu kodem. Umiejętności przychodzą z czasem.

Znasz to uczucie satysfakcji, gdy spoglądasz na swój kod sprzed kilku lat (albo i kilku miesięcy)? Wtedy nadchodzi TA chwila! Z dumą możesz skasować stare repozytoria z GitHuba, a na ich miejsce wrzucić swój nowy piękny program. Przecież przez ten czas nauczyłeś się wielu nowych wzorców oraz zastosowałeś wszystko, o czym mówili na ostatniej konferencji. I jeszcze przy okazji zmieniłeś klawiaturę, bo z tamtej wychodziły jakieś nieładne „zapachy kodu”.

Taka chwila nadchodzi szczególnie wtedy, gdy mamy już gotowe CV i czekamy tylko na to brakujące ogniwo, za pomocą którego każda firma przyjmie nas z otwartymi ramionami – reprezentatywny projekt w portfolio. Ale za jakiś czas ta sytuacja się powtarza. Nasz (jeszcze pół roku temu) piękny kod nie jest już taki, jaki nam się wcześniej wydawał. Mijają kolejne miesiące i znowu to samo. I znowu, i znowu, i znowu… Jak żyć?!

Stary kod – schować czy pokazać

Kiedyś robiłem dokładnie tak samo. Na szczęście udało mi się uciec z tej niekończącej się pętli. Pomogło w tym doświadczenie z selekcji kandydatów na programistów. Dzięki temu spojrzałem na ten temat z zupełnie innej perspektywy. Historia wygląda mniej więcej tak:

Pewnego dnia przeprowadzałem proces rekrutacyjny programistki. Znalazłem jej GitHuba, zanim jeszcze zdążyła podesłać go „oficjalną drogą”. Był tam bardzo słaby kawałek kodu, który dokładnie przejrzałem. Kiedy kandydatka podała nam swoje repozytorium poprzez rekruterkę, okazało się, iż to, które widziałem, było już skasowane. Wywnioskowałem więc, iż jej umiejętności programistyczne są niewielkie. Jak się później okazało, moje wnioski były całkowicie błędne…

Jednak choćby bez usuwania jakichkolwiek repozytoriów możemy przygotować nasz profil na GitHubie tak, aby słaby kod z przeszłości zaczął procentować przy najbliższej okazji.

Nazwij swój strach

Psychologowie mówią, iż pierwszym etapem do opanowania strachu jest uświadomienie sobie, czego tak naprawdę się boimy. Możemy to osiągnąć poprzez jasne nazwanie swojego lęku. Kiedy patrzysz na swój okropny kod sprzed kilkunastu miesięcy, a Twoja ręka wisi nad przyciskiem DELETE, to co czujesz? Boisz się, iż ktoś zobaczy, iż nie pisałeś testów? Albo, iż cały program mieścił się w jednej klasie o kilku tysiącach linii? A może po prostu Twoim największym problemem jest to, iż ktoś się zorientuje, jak słabym byłeś programistą? No właśnie… byłeś! I to jest Twój as w rękawie. Nie chowaj go i jak najszybciej zagraj w otwarte karty!

Warto pokazywać swoje niedoskonałości. Nie oszukuj! To wyjdzie w ciągu pierwszych dni nowej pracy, a może choćby już na rozmowie rekrutacyjnej. Warto, żeby pracodawca, a najlepiej koledzy z przyszłego zespołu, którzy najczęściej biorą udział w rekrutowaniu, wiedzieli, czego się po Tobie spodziewać. Jakie umiejętności będziesz mógł zdobyć w nowej pracy, a z jakimi pytaniami oni będą mogli się zwrócić do Ciebie.

W programowaniu partnerstwo to najlepszy rodzaj współpracy. Jak uważa Robert C. Martin (znany głównie ze swojej książki „Czysty Kod”), przy programowaniu w parach forma Mid-Mid jest lepsza niż np. Senior-Junior. Relacja mistrz-uczeń nie jest najważniejsza. O wiele bardziej liczy się wzajemne motywowanie do ciągłego rozwoju po obu stronach. Właśnie tego powinieneś szukać, decydując się na pracę w danym zespole. W tej branży nikt nie może przestać się rozwijać.

Kod mówi więcej niż tysiąc słów

Jako rekruter techniczny chcę zobaczyć kod kandydata, zanim podejmę decyzję o jego przyjęciu. To dla mnie jedna z najważniejszych rzeczy w rekrutacji. kilka firm pomija zadanie rekrutacyjne przy zatrudnianiu nowych pracowników. Jest to szczególnie przydatne, gdy profil na GitHubie jest od dawna nieaktualizowany. jeżeli kandydat ma aktualne repozytorium, zadanie jest często niepotrzebne.

Wyobraź sobie, iż jako rekruter zobaczę w zadaniu wiele błędów w podejściu do testowania. Gdy zajrzę do starszych projektów na GitHubie, być może natknę się na kompletny brak testów. Za to w CV przeczytam, iż kandydat aktualnie opanowuje metodykę TDD. To dla mnie oczywiste, iż taka osoba się rozwija i nie poprzestanie na w tej chwili prezentowanych umiejętnościach.

Dlatego pamiętaj, iż szczególnie ważne w twoim CV są plany na rozwój i to, jak pracujesz, aby je zrealizować. O ile certyfikaty z Udemy nie mają dużej wartości, to fakt, iż bierzesz udział w kursach i szukasz wiedzy, bardzo dobrze o Tobie świadczy. Szczególnie jeżeli jesteś na początku swojej kariery. Dlaczego ktoś miałby zatrudnić Junior Developera? Przecież pracodawca musi sfinansować jego wdrożenie, czas wykonywania zadań z pewnością przekroczy zaplanowane estymacje, a to dodatkowo zakłóci pracę innych członków zespołu i przyniesie straty finansowe.

Odpowiedź brzmi: w programowaniu nie jest ważne to, co umiesz, ale to, co będziesz umiał.

Umiejętności ważniejsze niż wykształcenie i lata doświadczenia

Często mamy do czynienia z Senior Developerami, których można nazwać seniorem jedynie z uwagi na staż pracy. Tak naprawdę przez całą karierę prawie się nie rozwijali i ciągle powtarzali to samo. W gruncie rzeczy ich doświadczenie to nie np. 12 lat, ale rok powtórzony dwanaście razy. (Napisano o tym już wiele, ale ja szczególnie polecam: Software Craftsman, The: Professionalism, Pragmatism, Pride) Dlatego warto zaryzykować i dać szansę osobie, która już od początku pokazuje, jak dba o własny rozwój. Najprawdopodobniej niedługo przełoży się to na wartości biznesowe dla pracodawcy.

We always believe that young people are better at developing the future because they are our future. ~ Jack Ma

W większości profesji im dłużej pracujesz w danym zawodzie, tym bardziej jesteś ceniony. Z pewnością chciałbyś, aby Twoją operację przeprowadzał doświadczony lekarz, a nie stażysta.

Jednakże-branża IT rozwija się w zastraszającym tempie i tutaj reguły gry są trochę inne. Mówi się, iż w wytwarzaniu systemu zmiana jest tak częsta, iż większość technologii, które opanujesz w ciągu 5 pierwszych lat swojej kariery, będzie aktualna jeszcze przez około następne pięć lat. Pojawiają się nowe języki programowania i dobre praktyki zastępują coś, co kiedyś było standardem. Młodzi programiści są w stanie szybciej załapać nowości, ponieważ nie mają bagaża niekoniecznie dobrych i wyuczonych przez lata przyzwyczajeń. Aby nie zostać w tyle, dla programistów z wieloletnim doświadczeniem najważniejsze okazują się tutaj słowa Mistrza Yody: „You must unlearn what you have learned”.

Nie jest ważne, co umiesz dzisiaj, ale co będziesz umiał jutro

Z oceną kandydatów bardzo mijają się ci, którzy podczas rozmów o pracę skupiają się na jednej technologii. Na przykład Java Developer jest pytany tylko o kwestie związane z tym językiem. Dodatkowo rekruterzy często bombardują kandydata podchwytliwymi pytaniami, w których każdy może pomylić się i które nie mają żadnego przełożenia na codzienną pracę. Do rozwiązania takich problemów zwykle wystarczy brak dysgoglii – bardzo groźnej choroby, która może zdyskwalifikować Cię jako przyszłego programistę. Tak na serio – wystarczy 5 minut, żeby znaleźć odpowiedź na te pytania w Internecie. Ważniejsze jest to, co się osiąga długą, ciągłą pracą nad sobą. Czyli możliwy do zaobserwowania wzrost między umiejętnościami z przeszłości a obecnymi.

W trakcie przeprowadzania rozmów rekrutacyjnych staram się stosować heurystykę zmierzenia tempa rozwoju. Za punkt odniesienia przyjmuję np. własny rozwój lub innych członków zespołu. Dobrym przykładem będzie job-interview, w którego trakcie zatrudnialiśmy Full-Stack Developera. Z uwagi na to, iż miałem małe doświadczenie we front-endzie, postanowiłem jedynie przysłuchiwać się tej części. Jakie było moje zdziwienie, kiedy okazało się, iż kandydat, który przez ostatni rok programował komercyjne projekty we frameworku React, nie znał podstawowych konstrukcji tej biblioteki. Nie potrafił też wskazać różnic w JavaScript między operatorami == i ===, które ja opanowałem po przerobieniu podstawowego kursu. To właśnie wolny wzrost umiejętności zadecydował o tym, iż nie złożyliśmy tej osobie propozycji współpracy.

Tempo rozwoju jest w pracy programisty bardzo ważne. W każdym projekcie zdarzy się coś, czego jeszcze nie robiłeś. Technologia, architektura, metodyka, o której nie masz pojęcia. Jeśli gwałtownie się uczysz, pracodawca będzie wiedział, iż równie gwałtownie odnajdziesz się w niemal każdej sytuacji i nie będziesz problemem dla reszty zespołu. Jak więc pokazać to w kodzie?

Pokaż swój rozwój na GitHubie

Jak zaprezentować swój rozwój na GitHubowym profilu? Pierwszym problemem, jaki napotyka profesjonalny developer, jest to, iż nie może pochwalić się publicznie kodem utworzonym w ramach pracy. Umowa zobowiązuje go do utrzymania kodu w tajemnicy. Nie przejmuj się. Twój profil uatrakcyjnią też projekty, które robisz poza pracą. Zadbaj o nie zwłaszcza na początku kariery. Co zrobisz z tymi projektami po 2–3 latach?

Jeśli masz już na swoim koncie projekty pozazawodowe, od których minęło już trochę czasu, to możliwe, iż aż ci wstyd jak to wygląda. I bardzo dobrze! To jedyna słuszna rzecz przy takim kodzie – oznacza, iż przez ten cały czas nie przestałeś się rozwijać. Zadbaj jedynie o to, aby Twój profil na GitHubie pokazywał tę dobrą zmianę, jaka zachodzi w czasie twojego rozwoju. Aby jak najbardziej ją uwidocznić, poświęć trochę czasu i opatrz repozytoria adekwatnym README.md – zaprezentuj aplikację, a na samym wstępie wspomnij o popełnionych błędach, kiedy nad nią pracowałeś i podlinkuj swoje nowe repozytoria, jeżeli takie masz. Napisz, co było celem projektu – poznanie jakiejś technologi, dostarczenie komuś wartościowego narzędzia itp. Nie chowaj swoich wad, ale też pochwal się tym wszystkim, o czym warto wspomnieć. Jeśli na Twoim profilu jest aplikacja mobilna, która ma 100 000 pobrań, to koniecznie o tym wspomnij.

Co jeżeli chcesz zacząć pracę nad wizerunkiem twojego GitHuba dopiero od dzisiaj i nie masz nic do pokazania? Jak napisał Robert C. Martin w „Mistrzu Czystego Kodu”, każdy programista powinien poza pracą poświęcać dodatkowe 2 godziny dziennie na swój rozwój. Jeśli brakuje Ci pomysłów na własny projekt, to świat projektów open-source stoi przed Tobą otworem. Dobrym pomysłem jest zaangażowanie się w jeden z nich. Branża jest naprawdę otwarta, a ludzie odpowiadający za świat open-source zwykle chętnie przyjmą każdą pomocną dłoń.

Jeśli nie czujesz się jeszcze gotowy lub po prostu chcesz przećwiczyć posługiwanie jakąś technologią, postaraj się właśnie wyeksponować tę kwestię. Jedno nie wyklucza drugiego. Zadbaj wtedy, żeby Twój profil był przeładowany repozytoriami takimi jak „LearningJavaScript”, „LearningEventSourcing”, „SelfImprovement” etc. Sam mam jedno repozytorium przeznaczone właśnie do nauki i eksperymentowania z nowymi rzeczami, które cały czas aktualizuję. Możesz je zobaczyć tutaj: https://github.com/MateuszNaKodach/SelfImprovement. Choć jest to jeden z najsłabszych przykładów moich umiejętności programistycznych, to z chęcią się nim chwalę i uważam za bardzo mocny punkt mojego GitHubowego profilu.

Ciebie też zachęcam do zrobienia czegoś podobnego. Dzięki temu prezentujesz czarno na białym, iż potrafisz zadbać o swój rozwój:

Jeśli jesteś studentem – pokaż, iż studia nie są dla Ciebie wszystkim i wiesz, jak zdobywać potrzebną wiedzę też na własną rękę.
Jeśli już pracujesz – pokaż, iż jesteś prawdziwym profesjonalistą i zdajesz sobie sprawę, jak istotny jest ciągły rozwój.

Jak ogarnąć repozytorium do nauki

Wspomniałem wcześniej o repozytorium „SelfImprovement” – jest w nim nie tylko kod, ale także masa przeróżnych materiałów w formie GitHub Issues. Są to linki do ciekawych artykułów, kursów, blogów, przykładowych projektów i wszelkich zasobów, które wykorzystuję do własnego rozwoju. Każde ze zgłoszeń ma przydzielone etykiety (np. Domain-Driven Design, Spring Cloud, Event Sourcing, Kotlin), tak aby potem łatwo się odnaleźć, gdy będę chciał wrócić do jakiegoś tematu. Dodatkowo po przerobieniu danego materiału oznaczam go jako ukończony i oceniam, czy coś było warte uwagi, czy też nie. Służą mi do tego etykiety Good oraz Bad, aby zasugerować innym, z czym warto się zapoznać. Spójrz też na issues oznaczone etykietą MINDCHANGER - to są rzeczy, po których nie będziesz już taki sam jako programista.

Do planowania i wyznaczania sobie celów używam Projects Board – funkcji GitHuba w stylu Kanban oraz uproszczonej wersji EventStormingu. EventStorming to metoda zwykle używana do odkrywania i modelowania działania systemu. Ale nie tylko, jest to metoda uniwersalna, i z powodzeniem możesz jej użyć, aby określić sobie cele i jak je osiągnąć.

EventStorming ma też zastosowanie w codziennych sprawach. Jednemu ze znajomych bardzo dużo czasu zabierały poranne czynności i zwykle zawoził córkę do szkoły już po rozpoczęciu lekcji. Dzięki EventStormingowi zamodelował co dzieje się każdego poranka, znalazł czynności, jakie można zrównoleglić, a z niektórych zrezygnował całkowicie. Od tej pory w szkole byli już zawsze na czas! Niektórzy wykorzystują tę metodę choćby do planowania swojego wesela! Dziwne jest to życie na kodach, no nie :) ?

Jeśli chcesz dowiedzieć się więcej o planowaniu własnego rozwoju, polecam Ci świetną prezentację z ostatniego spotkania Wrocław ITCorner. Tymczasem zobaczmy w praktyce, jak można zastosować tę metodę.

Załóżmy, iż Twoim celem jest opanowanie EventStormingu. Na początku określamy, co musi się wydarzyć wcześniej, abyśmy małymi kroczkami zbliżyli się do tego upragnionego celu. Opisujemy to w formie zdarzeń. Zdarzeniem jest np. „Obejrzano kurs online o EventStormingu”. Oczywiście nie musi to być od razu kompletny proces. Możesz z czasem dodawać więcej kroków. zwykle im więcej wiesz, tym bardziej jesteś świadomy, ile jeszcze możesz się nauczyć. Więc jest to jak najbardziej naturalne. Aż w końcu, gdy te wszystkie kwestie się wydarzą, możesz powiedzieć, iż osiągnąłeś cel „Opanowano EventStorming”. Oto krótki plan nauki, który kiedyś przygotowałem dla siebie:

Zamodelowany proces uczenia się EventStormingu wykonany... metodą EventStormingu :)

Gdy masz już repozytorium do nauki i chcesz śledzić swój postęp albo pokazać innym, jak pracujesz nad osiągnięciem celów, stwórz w nim nowy Kanban Board. Dzięki temu możesz zobaczyć, co już zrobiłeś, dodawać notatki jako komentarze i wiedzieć, ile jeszcze przed Tobą. A co ważniejsze, nie zginie to, jak karteczki przyklejone na ścianę. Zazwyczaj właśnie w podobny sposób, organizuję współpracę, w ramach prowadzonego przeze mnie mentoringu (więcej możesz poczytać TUTAJ).

Tablice Kanban są dostępne dla wszystkich repo na GitHubie.

Bądź inspiracją dla innych

Dokumentuj swoją drogę do mistrzostwa i pokaż, iż nie od razu Netflixa napisano! jeżeli jesteś już dobry w tym, co robisz, a inni mogą się od ciebie uczyć, to niech widzą, iż nie zawsze tak było. Że są na początku drogi i niedługo prawdopodobnie będą jak ty (albo jeszcze lepsi). Dzięki temu staniesz się inspiracją dla przyszłych adeptów programowania.

Jeśli to ty podziwiasz kod innych osób i sądzisz, iż nigdy nie będziesz jak oni, to weź sobie do serca te słowa: „Wiesz, jaka jest różnica między mistrzem a uczniem? Mistrz pomylił się więcej razy, niż uczeń podjął prób”. Każda z tych prób pozwoli Ci być coraz bliżej celu.

Pisanie czystego kodu jest bardzo, bardzo ważne. Ale w pracy programisty (szczególnie na stanowiskach seniorskich) coraz bardziej liczą się umiejętności miękkie, takie jak wyjaśnianie proponowanych rozwiązań czy kontakty z klientem. Same umiejętności programistyczne też wychodzą poza samo kodowanie. Na przykład bardzo dużo traci ten, kto traktuje Domain-Driven Design jako jedynie wzorce mające zastosowanie w kodzie, a pomija całą część strategiczną.

Kluczem różnych praktyk i metodyk wytwarzania systemu jest to, by zrozumieć domenę biznesową i nieustannie przystosowywać kod do przyszłych zmian. Mówi się, iż to właśnie zmiana jest jedyną stałą w projektach IT. Dlatego gdy określasz cele swojego rozwoju, nie ograniczaj się tylko do języków, frameworków czy bibliotek. Rozszerz plan o kwestie związane z analizą biznesową, zarządzaniem projektem czy organizacją zespołu. To wszystko pomoże Ci przetrwać w świecie IT, w którym żyją nie tylko osoby kompilujące kod zero-jedynkowy dzięki jednego spojrzenia.

Wiem, iż nic nie wiem

Witaj w klubie Krugera-Dunninga!

Jeśli wciąż starasz się rozwijać, to bez wątpienia wstąpiłeś na odpowiednią ścieżkę. Tak trzymaj! Być może czujesz w tej chwili, iż jedyne co wiesz, to iż nic nie wiesz. Ale głowa do góry! Twoja wiedza właśnie zaczęła się utrwalać na długie lata, a Ty jesteś na bardzo dobrej drodze do opanowania jej jeszcze lepiej, zgodnie z efektem Krugera-Dunninga.

PS. Na koniec posłuchaj jeszcze bardzo pouczającego wystąpienia na ten temat z konferencji 4Developers 2019 (pierwszy link poniżej).