Kilka dni temu nasz kierownik IT zapytał mnie, jak tam u nas na froncie widzimy cechy juniora, mida i seniora. To z pozoru proste pytanie sprawiło, że musiałem się porządnie zastanowić i przegadać temat z kolegami z zespołu, bo okazuje się, że ciężko o jakieś jednoznaczne definicje lub rozgraniczenia – Ty jesteś juniorem bo coś tam, a Ty seniorem bo pracujesz już 10 lat w firmie…
Przekopałem też na szybko pierwsze kilka wyników w Google i generalnie okazuje się, że co osoba to inne przemyślenia. Wszystkie jednak sprowadzają się do tego, że określenia te nie można wprost przełożyć na staż w firmie. Owszem, można z grubsza założyć jakieś widełki wynikające z czasu pracy czy lat doświadczenia, ale dużo też zależy od cech indywidualnych danej osoby.
O ile przejście z etapu juniora na mida (lub inaczej regulara) wydaje się dość proste do opisania, o tyle awans na seniora jest nieco bardziej metafizyczny i dużo trudniejszy do zdefiniowania. A wszystko dlatego, że nie chodzi tu tylko o umiejętności w programowaniu, od seniora wymaga się znacznie więcej umiejętności miękkich, zdolności interpersonalnych, czasem też managerskich. Ale do tego za chwilę dojdziemy…
Kim jest Junior Developer?
Junior, Świeżak, Nowy, Młokos, Żółtodziób – w IT terminy te nie odnoszą się do wieku osoby, a do jej doświadczenia. W kontekście przyjęcia do pracy w zespole pod tymi pojęciami rozumiemy najczęściej osobę, która posiada podstawowy zakres wiedzy z danej dziedziny, np. ukończyła jakiś kurs, bootcamp, szkolenie itp.
Uwaga – Junior to wcale nie laik – ten wie co najwyżej jak włączyć komputer i pasjansa – to zwykły użytkownik komputera.
Junior ma ogarnięte takie rzeczy jak:
- zna w stopniu zadowalającym podstawowe technologie (HTML, CSS, JS)
- zna i potrafi coś napisać w najpopularniejszych frameworkach (React, Vue, Angular)
- wie co to REST-API, potrafi odpalić ajaxa, pobrać i przetworzyć jakieś dane
- realizuje pojedyncze zadania wg dokładnych wytycznych
- poznaje projekty/systemy/rozwiązania stosowane w danej firmie
- uczy się szacować czasochłonność i pracochłonność powierzonych mu zadań
- uczy się uwzględniać kontekst zadań nad jakimi pracuje
Kilka słów wyjaśnienia: ktoś może się przyczepić, że junior powinien znać i Bootstrapa i Sassa i jQuery i … i jeszcze … itd. A ja uważam, że tu nie ma sztywnej listy. Jeśli szukam juniora do zespołu, to wezmę taką osobę, która choćby z grubsza zna narzędzia jakich my używamy (bo w nich będzie pracować) lub pokaże zadaniem domowym, że jest w stanie szybko je poznać. Oczywiście na poziomie podstawowym. A im więcej umie, tym lepiej dla niej – szybciej awansuje na mida…
Junior z zasady jest osobą, którą chcemy wyszkolić – w kontekście naszych projektów, narzędzi, tego co i jak robimy. Jeśli świadomie bierzemy juniora, to znaczy że akceptujemy to, że może czegoś nie wiedzieć, nie umieć, że musimy poświęcić swój czas i zasoby by taka osoba po kilku miesiącach mogła samodzielnie i wydajnie pracować.
Dołączenie juniora do zespołu trzeba traktować jak inwestycję długoterminową. Na początek przydzielimy mu proste zadanka – takie żeby go nie przytłoczyć, a jednocześnie dać możliwość zrealizować jakąś funkcjonalność, poznać kod, projekty. Trzeba być gotowym na pytania, poświęcenie czasu by czasem coś pokazać, doradzić.
Tak jak 9 kobiet nie urodzi dziecka w miesiąc, tak dorzucenie kilku juniorów do zespołu nie przyspieszy rozwoju projektu – wręcz przeciwnie – w pierwszych kilku miesiącach go spowolni, bo obsługa juniorów wysysa czas reszty zespołu. Dlatego zatrudnienie juniora traktuję jak inwestycję – jeśli zespół jest fajny, projekty ciekawe, a kasa przyzwoita – junior za jakiś czas zostanie cennym, samodzielnym członkiem zespołu.
Mid/Regular Developer – czyli samotny jeździec…
W przypadku Mida samodzielność to moim zdaniem słowo-klucz.
Jest to osoba, która:
- samodzielnie realizuje powierzone mu zadania
- rozumie kontekst zadań, złożoność systemów
- potrafi poprawnie oszacować ilość czasu/pracy potrzebnych do realizacji zadania
- zna narzędzia, frameworki, potrafi je dobrać odpowiednio do potrzeb
- jest samodzielny, odpowiedzialny, kontaktowy, potrafi zorganizować wszystko co potrzebne do realizacji
Dla mnie Mid to taka osoba, której zlecam zadanie, a ona je wykonuje. Tylko tyle i aż tyle.
Co zatem odróżnia Mida od Juniora?
Junior potrzebuje pomocy by zrozumieć co ma zrobić, skąd wziąć potrzebne informacje, czego użyć. Mid widząc zadanie potrafi sam wywnioskować czy ma komplet informacji potrzebnych do realizacji, jeśli widzi czego brakuje, potrafi sam dopytać kogo trzeba o potrzebne dane. Zna projekty, zna ludzi w firmie, zna środowisko i kontekst w jakim realizuje zadanie.
Mid potrafi w miarę poprawnie oszacować czasochłonność zadania, bo takie już robił lub wie co jest do zrobienia – z doświadczenia wie też gdzie mogą być pułapki i gdzie coś może pójść nie tak lub się opóźnić – i uwzględnia to w oszacowaniu.
A w końcu – Mid po prostu dowozi. Jest pewnym i stabilnym trybikiem w wielkiej machinie.
Wielu developerów zatrzymuje się na tym poziomie. I chwała im za to – są to osoby które lubią przede wszystkim programować, wykonują swoją pracę uczciwie i rzetelnie. Niektórzy są zamknięci w sobie, niektórzy przedkładają kod nad ludzi, inni po prostu wykonują swoją pracę, a po godzinach mają inne hobby. Każdy zespół potrzebuje takich samodzielnych developerów, bez nich ciężko byłoby zrealizować jakikolwiek projekt.
Niektórzy jednak idą krok dalej…
Senior Developer – czy wciąż tylko programista?
„Bycie Seniorem to jak bycie zakochanym. Nikt ci nie powie: jesteś zakochany. Sam to wiesz…” – powiedziała Wyrocznia do Neo. Lub jakoś tak… Cytuję z pamięci, a i szklaneczka whisky też coś opustoszała…
Napisałem wcześniej, że bycie Seniorem to coś bardziej metafizycznego 🙂 Generalnie chodzi mi o to, że bycie seniorem nie wynika z wieku, stażu pracy, czy jak świetnym programistą jestem… Bycie seniorem to w dużym uproszczeniu szersze spojrzenie na to co tworzymy. To znajomość dziedziny, firmy, ludzi, narzędzi, to umiejętność analizy, wyciągania wniosków, przewodzenia zespołowi.
Wg mnie Senior Developer to osoba, która:
- potrafi przeprowadzić analizę wymagań, zaplanować i poprowadzić projekt
- jest świadoma ograniczeń wybranych technologii/narzędzi w kontekście danego rozwiązania
- potrafi przekazywać wiedzę innym, być nauczycielem dla juniorów
- potrafi podzielić pracę pomiędzy zespół tak by jak najlepiej wykorzystać dostępne talenty i zasoby
- potrafi dogadać procesy pomiędzy działami, umie rozmawiać z ludźmi z innych działów, rozwiązywać problemy komunikacyjne
- jest osobą do której inni chętnie przychodzą po pomoc
- poszerza swoją wiedzę o inne obszary, nie tylko swoją wybraną dziedzinę (security, backend, dev ops itp.)
- posiada praktyczną wiedzę wynikającą z różnych doświadczeń związanych z wdrażanymi projektami, potrafi robić z niej użytek w codziennej pracy
- potrafi jasno przedstawić swój punkt widzenia i bronić go merytorycznymi argumentami
- jest otwarta na zdanie i opinię innych, uwzględnia krytykę i wyciąga wnioski
Na tej liście nie ma punktu w stylu: wymiata w pisaniu kodu, jest najlepszym programistą w zespole, pozjadał wszystkie rozumy.
Dobrym wyznacznikiem bycia seniorem jest fakt, czy inni przychodzą do nas po pomoc. Jeśli tak to świadczy to o naszej wiedzy, podejściu do innych, chęci pomocy, rozwijaniu się.
Jeśli Senior przewodzi zespołowi (często staje się Team Leaderem), to naturalnie stara się optymalnie wykorzystywać dostępne talenty i zasoby zespołu. Każdy ma jakieś upodobania, specjalizację – jeden lepiej czuje się w zadaniach dotyczących HTMLa, CSSa, wyglądu i działania interfejsu, inny zaś jest specjalistą od spraw dziwnych i nieodgadnionych (czemu na telefonie X strona Y zachowuje się nie tak jak trzeba…). Nie każde zadanie jest ekscytujące, nie każde jest nawet ciekawe – ale jeśli dobrze rozdzielimy zadania w zespole, wyważymy je, żeby nikogo nadmiernie nie dociążać, lub dajemy czas na regenerację przy czymś lajtowym – to ludzie w takim zespole lubią to co robią i pracują wydajnie.
Bycie Seniorem nie jest pochodną wieku, ale jest pochodną doświadczenia. Takie doświadczenie w firmie można uzyskać szybko lub wolno – to zależy od specyfiki firmy i danej osoby. Jednemu droga od Juniora do Seniora zajmie 3 lata, a innemu i 15 lat braknie…
Wydaje mi się, że w byciu Seniorem ważne jest też bycie świadomym swoich ograniczeń. Na pewnym etapie człowiek zyskuje świadomość, że nigdy nie jest tak, że się umie wszystko, wie wszystko z danej dziedziny. Zawsze może pojawić się ktoś młodszy, bardziej zdolny czy inteligentny. Dobry Senior powinien umieć taką osobę zauważyć, dać jej możliwości rozwoju, służyć radą i doświadczeniem, poprowadzić, a nie traktować jako zagrożenie czy konkurencję.
„Wiem, że nic nie wiem…” – to słynne zdanie przypisywane Sokratesowi. Mądrością Sokratesa była świadomość własnej niewiedzy i pokora. Podobnie Senior – im więcej wie tym bardziej widzi jakie obszary są jeszcze do zbadania. Dlatego cechą dobrego Seniora jest poszerzanie swoich horyzontów, rozwijanie swojej wiedzy o zagadnienia poboczne – pozornie nie związane bezpośrednio z jego specjalizacją.
„Znaj drogę swojego kodu na produkcję…” – to słowa które utkwiły mi w pamięci. Przepraszam autora, nie pamiętam gdzie je słyszałem. Słowa te są ważne, bo o ile można wyjść z założenia, że ja po prostu commituję kod i wciskam przycisk Deploy, a potem dzieje się jakaś magia i strona działa, o tyle znajomość tych wszystkich technologii użytych by opublikować nasz kod na produkcji bardzo mocno poszerza nasze horyzonty. To jest właśnie ten kontekst, o którym dość enigmatycznie piszę w całym artykule.
Kontekst jest oczywiście szerszy – nasza aplikacja powstaje by zapewne zrealizować jakiś cel biznesowy, są też uwarunkowania prawne, ekonomiczne, są cele marketingowe – całe spektrum zagadnień, na których nie musimy się w szczegółach znać, ale których świadomość pozwala na bardziej wnikliwą analizę tematu.
No i w końcu, Senior to też osoba, która nie boi się zarówno krytykować złe rozwiązania, ale też krytyki pod własnym adresem. To pewna dojrzałość by bez zbędnych emocji móc merytorycznie rozmawiać o projekcie, zespole czy własnej pracy.
Dobra merytoryczna krytyka jest cennym feedbackiem – pozwala na usprawnienie procesów lub lepsze zarządzanie pracą czy zespołem. Nikt nie jest doskonały, każdy popełnia błędy – ważne by umieć z tych informacji czy wydarzeń wyciągnąć wnioski i wprowadzić zmiany.
Junior, Mid, Senior – a co dalej?
Jeśli nie pracujemy w sztywnym korpo ze ściśle ustaloną ścieżką kariery zawodowej, to i tak możliwości jest co najmniej kilka.
Guru, Architekt, Ewangelista, Solution Manager…
To osoba, która ma szeroką i wnikliwą wiedzę o używanych w firmie technologiach. Potrafi przeanalizować koncept, dobrać odpowiednie narzędzia, wie czego i jak użyć, a co się w tym zastosowaniu nie sprawdzi. To taka wyrocznia, do której zwracają się Seniorzy. Czasem jest to ten siwy koleś w firmie, który jest współtwórcą jakiegoś języka programowania. A czasem to ten gość, do którego jakimś cudem wszyscy chodzą po poradę.
Project Manager, Kierownik, Dyrektor
To alternatywna ścieżka kariery. Na pewnym etapie każdy musi odpowiedzieć sobie na jedno, zajebiście ważne pytanie: co chcę w życiu robić? A potem trzeba zacząć to robić…
Czasem okazuje się, że na programowaniu świat się nie kończy, człowiek odkrywa w sobie predyspozycje do bycia managerem, do kierowania zespołem, do kreowania nowych produktów itp. Długi staż w firmie, dogłębna znajomość zagadnienia, projektów, ludzi… To wszystko sprawia, że dana osoba staje się dość naturalnie kandydatem do obsadzenia w roli kierownika działu, dyrektora departamentu czy jak to tam się zwie…
Minusem takiego rozwiązania jest fakt, że z czasem piszemy coraz mniej kodu, a jednocześnie zaprzyjaźniamy się z Excelem, Jirą lub innym narzędziem do przetwarzania zadań, cyferek i statystyk. Brakuje czasu na aktywne programowanie, wypadamy z obiegu na rzecz managmentu. Nie jest to droga dla każdego…
Podsumowanie
W rozmowie z kolegami z zespołu padły propozycje kolejnych szczebli kariery programisty: weteran, wiarus, apostoł itp. Jak już wspomniałem, trudno jest ustanowić jakieś sztywne ramy czy reguły – kto kiedy jest juniorem, midem czy seniorem. Myślę, że w każdej firmie może to wyglądać trochę inaczej. Dlatego nie skupiam się na stricte technicznej stronie znajomości technik programowania itp., wolę raczej odwołać się do pewnej dojrzałości programisty, do rzeczowej oceny własnego zaangażowania i podejścia do wykonywanej pracy.
Zapewne wiele aspektów pominąłem, ale to jest pole do uzupełnienia tego artykułu o Wasze przemyślenia – do czego gorąco zachęcam w komentarzach.