Jak wznieść się na większy poziom programowania

Gdy programujemy samotnie, tworząc swoje programy albo strony internetowe "do szuflady", w pewnym momencie zaczyna nam się wydawać, że jesteśmy w tym całkiem nieźli. Podobnie jest, gdy siedzimy kilka miesięcy w jednym projekcie i znamy w nim naszą działkę od A do Z.

Potem trafiamy do innego projektu i nagle wychodzą nasze braki w wielu dziedzinach programowania. Zastanawiamy się - WTF, przecież wcześniej szło nam tak dobrze...

Znam programistów którzy po kilkudziesięciu latach przesiedzianych w jednym projekcie, nie mogą odnaleźć się na rynku pracy, bo już dawno wypadli z obiegu. Nie wiedzą, jakie są aktualne trendy na rynku pracy, ani nie mają predyspozycji do nauki nowych rzeczy. 

Przeciwieństwem takiej sytuacji, jest trafienie do bardzo wymagającego projektu, w którym od razu będziesz miał styczność z kilkoma nowymi technologiami. Możesz piąć się w górę swoich umiejętności także wtedy, gdy w zespole będziesz miał bardzo wymagające review, w których ktoś "bezczelnie" wypomni Ci Twoje błędy w kodzie. Trafienie na taką osobę w teamie, może być dla Ciebie błogosławieństwem. 

1* Miałem w życiu taką sytuację trzy razy. Po raz pierwszy, gdy zaczynałem naukę programowania i jeszcze nie pracowałem zawodowo. Kolega poprosił mnie o napisanie małej stronki w HTML i CSS. Gdy podesłałem mu pierwsze zmiany przez maila, napisał do mnie, że mam 2 godziny na naukę Gita, inaczej nie będzie nawet patrzył w kod. Nauczyłem się wtedy Gita.

2* Po raz drugi natknąłem się na podobnego gościa na pierwszym dużym komercyjnym projekcie. Jeden z członków teamu miał fioła na punkcie clean code i był ogólnie bardzo wymagający. Gdy dowiedziałem się że będę z nim pracował bezpośrednio, wiedziałem że niedługo zabawię w projekcie. Różnica poziomów między nami była zbyt duża, jednak to czego dowiedziałem się w tym czasie, zostało ze mną na zawsze.

3* Byłem przez rok w projekcie utrzymaniowym w Angularze, z którego się zwolniłem z powodu braku rozwoju. Najlepsza decyzja dotycząca kariery jaką podjąłem. Następnie trafiłem do bardzo wymagającego projektu, w którym duży nacisk kładzie się na jakość kodu i podwójne code review robionego przez doświadczone osoby. Wyszły przy okazji moje braki w RXJS, o których bym się w inny sposób chyba nigdy nie dowiedział. Zobaczyłem też wtedy, jak wiele błędów robią inne osoby z którymi pracuję i nauczyłem się je wychwytywać.

Wydaje mi się, że tylko takie najbardziej wymagające projekty podczas których rozwijamy kod, są w stanie przenieść nas na wyższy poziom doświadczenia, dokładności i umiejętności. Łatwo jest znaleźć ciepłą posadkę i posiedzieć na niej kilka lat. Trudniej jest przekonać się, że mamy jeszcze mnóstwo rzeczy do nauki i coś z tym zrobić. Dostosuj się, albo giń. 
Znam osoby, które wyleciały z projektu po kilku dniach, ponieważ nie chciały się przyznać do swojej niewiedzy, uważały że jeśli robią wszystko po swojemu, to jest to ok. 

Zbieraj na bieżąco feedback od innych członków teamu. Znam przykład gościa, który przez cały sprint robił prosty formularz, nie zadając nikomu nawet jednego pytania. Po oddaniu funkcjonalności okazało się, że brakuje w niej połowy rzeczy (np walidacji) i kolega szybko zakończył karierę w tej firmie. Stało się nie dlatego, że pomylił się gdzieś w kodzie, a raczej z powodu złego podejścia do pracy. Jeśli czegoś nie jesteś pewny, pytaj. Często będziesz miał feedbacku aż za dużo - czytaj - kto to tak spierdolił ....

Taki wymagający projekt będzie dla nas stresujący, zwłaszcza, jeśli nie będzie szło nam najlepiej. Osoby doświadczone często są poirytowane błędami robionymi przez mniej doświadczonych kolegów, a nasila się to szczególnie, jeśli zauważą u nas brak postępów. Warto jednak posiedzieć przy kodzie trochę dłużej, poczytać o najlepszych praktykach w różnych technologiach i sprawdzać to co napisaliśmy po kilka razy, dzięki czemu, każdego dnia będzie nam nieco łatwiej.

Podsumowując - podziękuj osobom, które wywierają na Tobie presję w projekcie, o ile widzisz że przekłada się ona na rozwój Twoich umiejętności. 

Nie wolno też żałować czasu na naukę - wg Jordana Petersona, najlepsi specjaliści pracują nawet 70 godzin miesięcznie.