Wpis z mikrobloga

mireczki z #webdev mam takie przemyślenia na temat etapów rozwoju kariery programisty. Jako, że ja bardziej jestem na #backend (zarówno #php jak i #javascript - #nodejs) będą pisał bardziej o tej sferze, może na froncie czy w innych gałęziach programowania będzie podobnie?

Junior developer - Przekozak, pokodował trochę w domu lub 3 miesiące w firmie i nie ma dla niego zadania, którego by się nie podjął czy go nie wykonał w 1-2 dni. Ten typ przypomina mi trochę moją półtoraroczną córkę - leci do przodu bez względu na niepowodzenia i konsekwencje. Nawet jak coś skopie to sobie często nie zdaje z tego sprawy i wszystko jest w porządku. Gdy mu jednak powiesz, że jednak to nie powinno być tak to też się nie przejmuje - "no trudno" i leci dalej. Codziennie przynosi do pracy nowe super frameworki, które koniecznie musimy zastosować, bo na forum pisali że teraz ten jest najlepszy w benchmarkach. Miło wspominam ten stan umysłu - człowiek mało widział to też i się mało przejmuje :)

Mid/regular developer - Ten to już zdaje sobie sprawę z tego, że są jakieś wzorce projektowe. Nauczył się przeważnie jednego / dwóch frameworków, obczaił dobrze jakąś bazę danych (przeważnie jest to MySQL) i wszystkie problemy najchętniej rozwiązywałby tymi frameworkami z mysqlem. Gość czuje, że jest dobry w jakimś obszarze, jest to jego strefa komfortu i najchętniej by się nie wychylał, bo po tym, jak był juniorem w końcu czuje się gdzieś pewnie. W późniejszej fazie mida zaczyna już w tych frameworkach grzebać, szukać bugów i je naprawiać. Zaczyna też powoli się interesować produkcją - podpytuje jak to jest wdrożone, czasem chciałby poprzeglądać jakieś logi.

Senior - Wie, że do każdego problemu rozwiązaniem jest odpowiednie narzędzie (nie zawsze MySQL i Symfony 2/3 ;)). W sumie frameworki coraz częściej go ograniczają. Wolałby spokojnie popisac z własnym pakietem bibliotek, wtedy ma pełną kontrolę nad kodem i nie ma niepotrzebnych zależności. Jest świadomy problemów produkcyjnych, potrafi budować aplikację tak, aby miała możliwie wartościowe logi i z nich korzystać, wszak przy problemach klientów logi to często jedyna nadzieja na to, aby dowiedzieć się, w jaki sposób doszło do babola. Potrafi zrobić też deployment tego co napisał, czuje się odpowiedzialny za swój projekt / produkt. Wie też dobrze, do czego służy produkt pod kątem biznesowym i w tym obszarze też potrafi rozwiązywać problemy.

I tu dochodzimy do sedna - według mnie bycie seniorem to nie tyle umiejętności techniczne (za którymi w dzisiejszym IT cały czas musimy gonić) tylko swego rodzaju stan umysłu. Najlepszy wymiatacz techniczny nie będzie seniorem dopóki nie będzie miał świadomości dlaczego robi dany produkt, do czego on służy. W swojej karierze spotkałem zarówno ludzi, którzy nie nadawali się na juniora a na papierze mieli 3 lata doświadczenia a także takich z 2 letnim doświadczeniem, którzy spokojnie sobie radzili jako mid. Jak to wygląda z Waszej perspektywy?
  • 7
Taka anegdotka z pracy:

Trzeba było oszacować czas pracy nad planowanym projektem.
Wszystko było rozpisane na etapy, zrobiony ładny arkusik Excela. Do uzupełnienia tylko kolumna z zakładanym czasem pracy nad każdym etapem.

Robił to kolega junior (notabene - technicznie wymiatacz niesamowity). Powpisywał do poszczególnych kawałków czas rzędu 2-3-4 godzin.

Tabelka trafiła do mnie (powiedzmy - starszego juniora). Pomnożyłem wszystkie liczby razy 2 i przekazałem kierownikowi.

Kierownik zaakceptował te wartości, które ja wpisałem,
@kefas_safek: trochę #!$%@?. Niestety chcemy czy nie nasza robota zależy od biznesu i dowiezienie projektu w opłacalnym czasie jest celem nadrzędnym - bez tego nie jesteśmy opłacalni dla firmy i generujemy większe straty niż zyski ( ͡° ͜ʖ ͡°). Stąd czasami juniorskie "opierdzielenie na szybko" trafia się niezależnie od poziomu. Jedyna różnica to to, że mid/senior widzi swoje kwiatki i robi je umyślnie mając świadomość trade-offów. W
@xDrope: w sumie chyba jedną z gorszych rzeczy z punktu widzenia zarobków jest wpadnięcie w pęd ku perfekcji i zwracanie uwagi tylko na jakość kodu, bez rozpatrywania biznesowego kontekstu.

Oczywiście na pewno są też przypadki które potem zrobią drugiego bitcoina czy coś tego typu i zostaną miliarderami, ale jakoś częściej trafia się chyba wypalenie zawodowe i ostatecznie frustracja (czasem po wielu latach) że ludzie, co mają mniej doświadczenia i gorszego technicznego
@xDrope: @xetrov: A ja myślę, że oboje macie po trochę racji. Kiedyś cisnąłem na efekt - klient się złości, przełożony #!$%@?, termin goni, trzeba skończyć i już. Zmądrzałem jak musiałem potem rozbudowywać te projekty. Być może (kolego @kefas_safek) junior kończy się w tym miejscu. Piszesz kod tak, żeby dało się go rozbudować bez reorganizacji tego co już masz.
@xDrope: zgadzam się, nasza robota zależy od biznesu. Jednak różnicę są w sposobie rozwiązywania problemów i typowych ASAPÓW. W firmie "janusz biznesu" zaakceptują każdy kod byle szybko. Działa to działa i jedziemy dalej. Taki też kod napisze byle junior. Problem zaczyna się przy rozbudowie - w pewnym momencie albo junior mówi, że już się nie da albo "musimy przepisać" albo że będzie za 2 tygodnie.
Zakładam jednak, że pracujemy w poważnej
@xetrov: I to właśnie napisałem - to jest według mnie różnica mida od seniora - senior ma świadomość biznesu nad którym pracuje a mid nie, dlatego też senior jest w stanie dobry kod inaczej wyprodukować - po prostu bardziej wie gdzie można popuścić a gdzie kod musi być idealny. Przez to też jest w stanie wziąć odpowiedzialność za swoje decyzje.