5 lat z kodem: najważniejsze wnioski, które zmieniają sposób myślenia o byciu developerem

Pierwsze lata pracy komercyjnej w IT to intensywny okres nauki, nie tylko technologii, ale przede wszystkim tego, jak funkcjonować w zespole i rozwijać się w branży. W trakcie 5 lat pracy z kodem zdążyłam zrozumieć kilka rzeczy, które realnie zmieniają sposób myślenia o projektach, pisaniu kodu i współpracy w zespole.

Nie jesteś swoim kodem

Wielu (nie tylko) początkujących programistów traktuje feedback związany z kodem jak atak personalny. Najczęściej przyjmują przy tym postawę obronną, zamykając się na potencjalne uwagi, które pomogłyby im ulepszyć kod. Z jednej strony to zrozumiałe – w końcu nie rzadko spędzają godziny nad danym rozwiązaniem, a tu przychodzi ktoś inny i zaczyna wskazywać jego wady. Nie są to jednak wady programisty, a wady samego kodu.

Nie jesteś swoim kodem, kod zawsze można zmienić, poprawić, ulepszyć, to jest wytwór Twojej pracy, nie Twoja osobowość. Dlatego właśnie warto zmienić perspektywę i spojrzeć na code review i feedback z niego płynący nieco inaczej – to jedno z najskuteczniejszych narzędzi rozwoju każdego developera. Ktoś inny poświęca swój czas, by przeanalizować nasz kod, wskazać potencjalne problemy i zaproponować lepsze rozwiązania. To mentoring w czystej postaci, dostępny przy każdym pull requeście, za darmo! Konstruktywna krytyka kodu to nie ocena programisty, tylko możliwość rozwoju i nauki. Dzięki uwagom innych poznajemy różne perspektywy, odkrywamy rozwiązania, o których sami byśmy nie pomyśleli, uczymy się przewidywać problemy, zanim staną się krytyczne. Każdy komentarz to szansa na szybszy rozwój niż gdybyśmy mieli odkrywać wszystko samodzielnie metodą prób i błędów.

Masz prawo popełniać błędy

Naprawdę. Nawet te głupie, a może zwłaszcza te głupie, bo to właśnie one uczą najefektywniej. Strach przed popełnieniem błędu może paraliżować, zwłaszcza na początku kariery. Obawa, że Twój kod wywoła katastrofę na produkcji, że przez nieuwagę wprowadzisz krytyczny bug albo zwyczajnie napiszesz coś, co nie wygląda wystarczająco mądrze, potrafi skutecznie zablokować przed działaniem i eksperymentowaniem.

Rzeczywistość jest taka, że każdy doświadczony programista ma za sobą historię mniej lub bardziej poważnych błędów – od przypadkowego skasowania ważnych danych, przez wdrożenie krytycznego buga na produkcji (a nawet kompletne unieruchomienie serwisu), aż po stworzenie „małego potworka”, który straszy innych programistów (nie tylko w nocy). O przekroczeniu budżetu wynikającym z niedoszacowania złożoności kodu i własnych możliwości nawet nie wspomnę. Pomimo tego Ci ludzie nadal pracują w branży i wielu z nich jest naprawdę dobrymi specjalistami.

Błędy to nie dowód niekompetencji, tylko naturalna część procesu uczenia się. Będą Ci towarzyszyć przez resztę kariery, więc warto nauczyć się podchodzić do nich spokojnie, wyciągać z nich wnioski i traktować je jako element rozwoju, a nie powód do obaw czy wstydu.

Dziel się wiedzą

Kitranie wiedzy dla siebie nie zrobi z Ciebie lepszego developera. Ukrywanie wiedzy prowadzi do powstawania silosów informacyjnych, które obniżają efektywność zespołu i tworzą krytyczne punkty zależności. Kiedy tylko jedna osoba wie, jak działa krytyczna część aplikacji, cały projekt staje się wrażliwy na jej nieobecność. Zespół traci możliwość efektywnej współpracy, a atmosfera staje się mniej otwarta.

Dzielenie się wiedzą wzmacnia cały zespół, tworzy kulturę wzajemnego wsparcia, gdzie wszyscy czują się komfortowo zadając pytania. Co więcej, tłumaczenie czegoś innym zmusza do uporządkowania własnej wiedzy, często dopiero przy próbie wytłumaczenia danego konceptu okazuje się, że nasze zrozumienie jest powierzchowne i sami musimy uzupełnić wiedzę. Uczenie innych sprawia, że tak naprawdę rozwijamy również własne kompetencje.

Im silniejszy zespół, tym przyjemniej się pracuje i tym szybciej każdy może się rozwijać. To gra o sumie dodatniej – pomagając innym rosnąć, zyskujemy lepszych współpracowników i sami uczymy się więcej.

Umiejętności miękkie mogą zadecydować o Twojej karierze

Branża IT jest pełna histori o technicznie świetnych programistach, którzy nie osiągnęli sukcesu ze względu na brak umiejętności interpersonalnych. Znajomość najnowszych frameworków czy doskonała architektura kodu to za mało, jeśli współpraca z daną osobą jest męką dla całego zespołu.

Popularne powiedzenie głosi: „Zatrudnia się za skille twarde, a zwalnia za brak miękkich”. Rzeczywistość potwierza tę zasadę. Arogancja, niechęć do słuchania innych, traktowanie każdej dyskusji jak pola bitwy, brak umiejętności przyjmowania feedbacku – to wszystko może przekreślić nawet najlepsze kompetencje techniczne.

Praca w IT to również praca z ludźmi, nie tylko z kodem. Wymagana jest umiejętność jasnej komunikacji, rozwiązywania konfliktów, konstruktywnego przekazywania i przyjmowania krytyki. Programowanie to w sporej części działalność zespołowa. Kod powstaje wspólnymi siłami wielu developerów, problemy rozwiązywane są zespołowo, decyzje podejmowane w dyskusji. Bez umiejętności współpracy kariera ma ograniczony potencjał, niezależnie od poziomu technicznego.

Paradoks wiedzy – Efekt Dunninga-Krugera

Zjawisko to stanowi błąd poznawczy, w którym osoby o niskiej wiedzy lub kompetencjach w danej dziedzinie mają tendencję do przeceniania swoich umiejętności, podczas gdy prawdziwi eksperci często zaniżają ocenę własnej wiedzy i możliwości.

Efekt Dunnina-Krugera jest szczególnie widoczny w branży IT. Na początku, po opanowaniu podstaw jakiejś technologii, łatwo o wrażenie, że temat jest już opanowany. Prosty projekt działający na lokalnym środowisku może dawać złudne poczucie kompetencji. Dopiero praca nad rzeczywistymi, złożonymi systemami ujawnia prawdziwą głębię dziedziny. Nagle okazuje się, że poza samymi podstawami trzeba jeszcze ogarniać pracę z bazami danych, dbać o wydajność aplikacji, pisać testy, zapewniać dostępność, myśleć o bezpieczeństwie, a do tego jeszcze rozumieć procesy CI/CD – i to wciąż tylko niewielka część tego, z czym spotyka się współczesny web developer. Lista rzeczy do nauczenia się nie kurczy się z czasem, tylko rośnie w zastraszającym tempie.

Im więcej wiemy, tym wyraźniej dostrzegamy granice własnej wiedzy. Po tym zresztą często mozna poznać junior developera – im mniesze doświadczenie, tym większa pewność siebie. Tymczasem doświadczeni programiści są zazwyczaj najbardziej pokorni, mówią „nie wiem, sprawdzę”, przyznają się do błędów, pytają innych o zdanie. To nie jest słabość, tylko znak dojrzałości zawodowej i świadomości własnych ograniczeń.
Prawdziwa pewność siebie to nie udawanie wszechwiedzy, tylko świadomość tego, czego się nie wie, przy jednoczesnym braku strachu przed przyznaniem się do tego. Pokora umożliwia ciągły rozwój, bo tylko osoba świadoma swoich luk może je systematycznie wypełniać.

Syndrom oszusta – cichy towarzysz każdego developera

Uczucie, że jesteśmy na danej pozycji przez przypadek, że nie zasługujemy na swoje osiągnięcia i zaraz ktoś odkryje, że tak naprawdę nic nie umiemy, to tzw. syndrom oszusta. I choć może się wydawać, że to indywidualny problem, w rzeczywistości dotyka większości ludzi w branży, niezależnie od poziomu zaawansowania.

Juniorzy czują się oszustami, bo „tak mało wiedzą”, seniorzy, bo „powinni już wiedzieć więcej”, tech leadzi, bo „nie są wystarczająco dobrzy, by prowadzić zespół”. Ten wzorzec powtarza się na każdym szczeblu kariery.

Syndrom oszusta można w pewnym stopniu ogarnąć, choć prawdopodobnie nigdy nie zniknie całkowicie. Pomocne jest rozmawianie o tym otwarcie – często okazuje się, że inni ludzie w zespole mają podobne odczucia. Prowadzenie listy konkretnych osiągnięć pozwala w momentach zwątpienia przypomnieć sobie rzeczywiste dowody kompetencji. Zrozumienie, że to normalne zjawisko psychologiczne, a nie obiektywny wskaźnik umiejętności, również przynosi ulgę.

Kluczem jest nauczenie się funkcjonowania z tym uczuciem, nie pozwalając mu na blokowanie rozwoju i podejmowania nowych wyzwań.

Komunikacja jako fundament każdego projektu

Najlepiej zaprojektowany system, najbardziej elegancki kod, najsprawniejszy zespół, wszystko to może runąć przez brak odpowiedniej komunikacji. Źle zrozumiane wymagania, przekazywanie niekompletnych informacji (lub nieprzekazywanie ich w ogóle), samodzielne, nieskonsultowane decyzje techniczne, to gotowy scenariusz na projektowe kłopoty.

Projekty nie upadają (tylko) przez złe technologie czy brak umiejętności technicznych. Upadają przez „przebite widły” – sytuacje, gdzie każdy działał w dobrej wierze, ale brak komunikacji sprawił, że wszyscy szli w różnych kierunkach.

Wtedy najczęściej okazuje się, że kilku developerów rozwiązuje ten sam problem, ale każdy na swój sposób, pojawiają się konflikty w kodzie, bo nie ustalono wspólnych standardów działania, część funkcjonalności jest implementowana podwójnie, bo nikt nie zakomunikował, że już nad danym ficzerem pracuje, a architektura zaczyna się rozjeżdżać, bo decyzje techniczne zapadają w izolacji zamiast w zespole.

Efektywna komunikacja w zespole to nie tylko daily, standupy czy spotkania planningowe. To kultura otwartego dzielenia się informacjami, zadawania pytań, sygnalizowania problemów na wczesnym etapie. To dokumentacja decyzji, jasne komentarze w kodzie, szczegółowe opisy w pull requestach. To umiejętność słuchania innych perspektyw i znajdowania kompromisów. To również świadomość, że lepsza komunikacja przekłada się na mniej nieporozumień i bardziej przewidywalny proces tworzenia oprogramowania. W zespole, który dba o klarowną komunikację, łatwiej jest wychwycić potencjalne ryzyka, szybciej można reagować na pojawiające się trudności i unikać sytuacji, w których projekt zaczyna rozwijać się w rozbieżnych kierunkach.