„Senior to stan umysłu”. Odrobinę przewrotny tytuł, bo oczywiście nie chodzi mi o seniora w standardowo rozumianym znaczeniu tego słowa, a o tzw. „senior software engineer”, czyli kogoś, kim staram się być. Staram, ponieważ dopiero stosunkowo niedawno zrozumiałem, że najczęściej używane do definicji tego stanowiska kryteria – lata doświadczenia, znajomość wielu technologii, realizacja projektów od A do Z itp., nie do końca pokrywają się z życiem.
Co oczywiście nie znaczy, że kryteria są błędne, a moje obserwacje nie. W tym wpisie chciałym zawrzeć krótkie rozważania na temat „kim jest senior software engineer i dlaczego nie zawsze jest on najlepiej piszącą kod osobą w zespole”. Takie podejście od razu nasuwa podejrzliwemu czytelnikowi uwagę: „oho, kolejny nieumiejący kodować chce się usprawiedliwić”, ale jestem gotów podjąć takie ryzyko 🙂
Przed napisaniem tego artykułu, chciałem się dowiedzieć jak na definicję „seniora” zapatrują się inni ludzie. Przeczytałem kilka dyskusji na forach internetowych i widzę, że w większości wypadków sprawa schodzi zazwyczaj na umiejętności kodowania. Najczęściej na tychże umiejętnościach się też kończy. I tu jest właśnie kot pogrzebany, bo im dłużej pracuję w tym zawodzie, tym bardziej uważam, że „dobry” senior jest na pewno dobrym programistą, ale niekoniecznie musi być najlepszy w zespole.
Powiem więcej – jest niemożliwe, aby był on najlepszym koderem w dobrym zespole.
Powód jest prosty – tworzenie nowoczesnych systemów o co najmniej średnim rozmiarze wiąże się z koniecznością wykorzystania bardzo wielu technologii i podejść do programowania. Weźmy najprostszy podział – na część „front” oraz „backendową”. O ile można specjalizować się w jednej z nich i opanować ją do perfekcji, o tyle obie kryją w sobie zbyt wiele zagadnień, by być w nich naraz mistrzem.
Tak więc może zdarzyć się sytuacja, gdy „junior” czy „normal” wie o pewnych zagadnieniach więcej niż ten mityczny „najlepszy z najlepszych”, czyli senior. I tak naprawdę nic to nie zmienia, bo samo programowanie nie jest w IT najważniejsze.
Skoro nie programowanie, to co jest?
Przychodzi mi na myśl długa lista, ale skracając ją maksymalnie zostają dwa ogólne tematy – umiejętności „miękkie” oraz proaktywność.
W obu tych pojęciach drzemie sekret różnicy pomiędzy „starszym inżynierem oprogramowania”, a „dobrym klepaczem kodu”. Pierwszy będzie osobą szanowaną w każdej firmie. Drugi stosunkowo łatwo wymienialnym zasobem. Kimś z kim bez żalu można się rozstać mając pewność, że za odpowiednią cenę znajdziemy drugiego, prawdopodobnie jeszcze lepszego.
I mógłbym tak produkować się godzinami, ale nie o to mi chodzi. Ten artykuł ma stanowić wstęp do czegoś większego. Przez długi czas zastanawiałem się, czym jest ten blog i jak widzę jego przyszłość. Co mogłoby być tak ważne, żebym starał się zabrać chwilę Twojego cennego czasu? Bo przecież nie moje rozważania o książkach, odchudzaniu czy „filozofii” – te można przeczytać w dowolnym miejscu w sieci.
Taką rzeczą, która pomoże Tobie w stawaniu się lepszym programistą, a mi w pracy z lepszymi ludźmi, może być właśnie wiedza dotycząca pracy programisty. Zauważ, że świadomie nie napisałem: „wiedza związana z programowaniem”, bo chodzi mi własnie o to wszystko, co jest poza kodowaniem, co sprawia, że człowiek jest kimś niezastąpionym nie dlatego, że napisał dany moduł w sposób zrozumiały tylko dla niego, a dlatego że jest cenionym kolegą, przełożonym czy podwładnym.
Cel, jaki sobie w tej chwili stawiam – czyli pisanie o tym wszystkim – jest niezwykle trudny i wymagający. W końcu dlaczego akurat ja miałbym wiedzieć coś więcej od Ciebie? Proszę Cię zatem, jeżeli zauważysz w moich postach sprawy, które pominąłem, potraktowałem zbyt ogólnikowo lub w których się pomyliłem, daj mi znać. Napisz o tym w komentarzu lub bezpośrednio do mnie. A jeżeli uznasz moje wpisy za pomocne – podziel się nimi z kolegami.
* Jeszcze raz podkreślam, że nie uważam, że programowanie w zawodzie programisty jest czymś nieważnym. Wręcz przeciwnie. Ale jednocześnie uważam, że po osiągnięciu pewnego pułapu warto przystanąć i zastanowić się. Czy aby poznanie kolejnej biblioteki da nam więcej, niż rozwój w innym kierunku, niekoniecznie postrzeganym jako ściśle związany z IT?
