Informacje o nowych artykułach oraz akcjach edukacyjnych prosto na Twojej skrzynce e-mail!

Junior, mid, senior. Na pewno?

Poziom doświadczenia, a raczej wiedzy danego developera określamy w trzystopniowej skali. Niby wszystko jasne i klarowne, ale kim tak naprawdę jest junior, mid lub senior developer? Jakie umiejętności, doświadczenie zawodowe, trzeba posiadać, aby „dorobić” się takiego tytułu? Czy każdy mid to mid, a każdy senior to senior? A kiedy junior staje się midem? Pytania się mnożą, a odpowiedzi brak. Spróbujmy to rozgryźć! 

Zanim jednak przejdziemy dalej zastanówmy się czemu w ogóle dzielimy developerów według ich wiedzy/doświadczenia lub też jakiegoś innego kryterium? Czy ma to znaczenie w przy tworzeniu zespołu zajmującego się rozwojem oprogramowania? To pytanie jest właśnie kluczowe, a wiąże się z nim dość ciekawy problem „zbyt dobrego wykształcenia”. Pewnie zastanawiasz się co ja tutaj za głupoty piszę? Jak można być „zbyt dobrze wykształconym”?  Ale to nie jest takie głupie jak na pierwszy rzut oka się wydaje. 

Swego czasu, będąc studentem jednej z krakowskich uczelni dość często uczestniczyłem w różnego rodzaju konferencjach czy też innych spotkaniach organizowanych przez firmy takie jak Google, Facebook, Microsoft… Pierwsza liga i marzenie wielu osób chcących rozwijać swoją karierę w IT. Wszystkie te wydarzenia miały oczywiście na celu jedną podstawową rzecz – w zamian za „darmową pizzę”, zostawiało się rekruterom swoje CV – oczywiście nie był to przymus, jak ktoś nie chciał to nikt do tego na siłę nie zmuszał, a przyjść i posłuchać zawsze było można. Z tych setek, jeśli nie tysiące dokumentów, wybieranych było kilkunastu najlepszych kandydatów, którzy potem zostawali zapraszani do dalszych etapów rekrutacji. Selekcja jak widać dość spora, ale też zainteresowanie było duże, więc owe firmy mogły sobie na to pozwolić. Jak nietrudno się więc domyślić, do pracy w tak zwanej „wielkiej czwórce” (Facebook, Google, Amazon, Apple) zatrudniani są więc sami wybitni specjaliści. Marzenie każdego managera? Tylko tutaj pojawia się jeden problem – przecież nie chcemy mieć w zespole samych „seniorów”. Jeśli więc rekrutujemy najlepszych z najlepszych to w jaki sposób ustalić kto jest kim w pracowniczej hierarchii? Można to oczywiście zrobić licząc doświadczenie poszczególnych osób, umiejętności czy też wynik jaki dany kandydat uzyskał podczas rozmowy kwalifikacyjnej. To jest pewien problem, który właśnie powoduje dość „sztuczne” myślenie o programistach w kontekście ich podziału na tych zaawansowanych i mniej zaawansowanych.

Dobrze dobrany zespół charakteryzuje się tym, że w jego skład wchodzą zarówno developerzy początkujący, Ci trochę bardziej doświadczeni oraz tak zwani seniorzy. Na potrzeby przedstawionych tutaj rozważań, pomijam takie role jak architekt, konsultant techniczny, scrum master czy product owner. Interesuje nas same „mięso”, czyli „developerka”. 

Wracając do meritum, kim jest osoba określana jako „młodszy programista”? W wolnym tłumaczeniu tego terminu, można by napisać, że to ktoś z podstawową wiedzą o danej technologii, znajomości zasad programowania obiektowego czy też znajomości wzorców architektonicznych. Od osób kandydujących na takie stanowisko, zazwyczaj nie wymaga się komercyjnego doświadczenia, ale samodzielnych projektów, ukończonych studiów informatycznych lub też statusu studenta. Wszystko tutaj uzależnione jest od konkretnych wymagań konkretnej firmy. Zazwyczaj zakłada się, że taka osoba jako tako pracować samodzielnie jeszcze nie umie. Trzeba dość uważnie robić jej „review kodu” oraz być przygotowywanym na serię różnych pytań technicznych bądź możliwości rozwiązania danego problemu. Przeważnie młodsi programiści pracują pod bacznym okiem „seniora”, który kieruje ich ścieżką rozwoju. Tyle teoria, a w praktyce często wychodzi to różnie. Tutaj jednak sprawa jest dość prosta. Nie masz doświadczenia, jesteś więc „junior developerem”. Ale kiedy staniesz się midem/seniorem? 

Mid to osoba, która po pierwsze ma już jakieś doświadczenie zawodowe, przestaje się pytać wszystkich o wszystko no i większości review jej kodu, przechodzi bez większych zmian. Taki programista wykonuje samodzielnie powierzone zadania i potrafi sprawnie posługiwać się narzędziami których używa do pracy. 

Jak widzisz, wszystko to opiera się o dość „luźne kryteria”. Kiedy junior staje się midem? A no wtedy, kiedy bez zbędnej pomocy innych, dowozi zlecone zadania. Cały problem polega na tym, że jak już wiemy projekt, projektowi nie równy. Tak samo jak task, taskowi nie równy. W jednej firmie lub projekcie możesz być traktowany jako mid, a w innej sytuacji już midem byś nie był. Często też na pozycję „mida” awansuje się po prostu poprzez rekrutację do nowej firmy. Rekruterzy chcąc zwiększyć atrakcyjność swojej oferty często proponuję „wyższe” stanowiska – w większości przypadków, tylko na papierze. Ale to temat na osobny materiał.

Senior to programista, który na task nie patrzy jak na kod, który trzeba napisać. Każde zadanie to tylko część całego ekosystemu, który razem musi współgrać i realizować założone cele. Jest to też osoba, która, poza tym, że charakteryzuje się dużą wiedza techniczną to równocześnie dba o to, aby ją przekazywać mniej doświadczonym kolegom czy koleżankom. Dostrzega też problemy klienta i potrafi zasugerować ich rozwiązanie. Na tym stanowisku powoli pisze się coraz mniej kodu, a bardziej zastanawia się nad rozwiązaniem problemów z którymi mierzy się cały zespół.  

Kiedy więc stajesz się seniorem? Najczęściej ma to miejsce właśnie podczas zmiany pracodawcy lub też projektu. To dość sztuczny podział, ale taka jest praktyka. Można by też napisać, że w sumie, jeśli pomagasz innym mniej doświadczonym, samodzielnie potrafisz dowieść stawiane przez klienta cele i masz odpowiednio dużo wiedzy, aby wszystko co robisz dobrze działo, to właśnie jesteś seniorem. 

Pamiętaj, o jednej ważnej rzeczy. Tytuł, który masz wpisany „w papierach” nie zawsze odzwierciedla rzeczywistość. Pozostaje więc pytanie, jak w takim razie zweryfikować swoją wiedzę aby określić swój poziom zaawansowania? 

Można to oczywiście robić podczas codziennej pracy albo też w nieco bardziej przyjemny sposób. O takim właśnie „programistycznym wyzwaniu” pomyślał portal Pracuj.pl i Gameset. Co powiesz na „Decode IT”? 

Jest to inicjatywa skierowana do developerów o średnim i zaawansowanym poziomie (czyli „mid” i „senior”), a polega ona na rozwiązaniu siedmiu programistycznych problemów. Można to zrobić dla fanu ale też dla ciekawych nagród. Za pierwsze miejsce przewidziany jest stacjonarny komputer gamingowy z monitorem oraz słuchawkami, wicelider też będzie mógł postawić sobie pod biurkiem taki sprzęt, a kolejna osoba w rankingu otrzyma kartę graficzną GeForce RTX. Dla miejsc od 4 do 10 organizator przewidział bony zakupowe do sklepu X-Kom o wartości 500 zł! 

Co ciekawe zadania będzie można rozwiązywać wielokrotnie w wybranej technologii (w przypadku remisu wygrywa osoba z mniejszą ilością prób). Ostatnie decydujące wyzwanie będzie polegało na optymalizacji – dla mnie, brzmi ciekawie. 

Jeśli nawet jesteś juniorem, to również zapraszam do wzięcia udziału w tej inicjatywie. Może to będzie solidny argument do podwyżki i awansu? Na pewno warto się sprawdzić, a to nic nie kosztuje. Kto chętny na dobrą zabawę? 

Spodobało się?

Jeśli tak, to zarejestruj się do newslettera aby otrzymywać informacje nowych artykułach oraz akcjach edukacyjnych. Gwarantuję 100% satysfakcji i żadnego spamowania!

, , , , , , , , , , , , , , ,

Dodaj komentarz

Komentarze (4)

  • bóg pisze:

    Jestem w branży od 6 lat i nadal jestem juniorem :)
    w robocie się obijam, gram nawet na fonie jak nikt przy mnie nie stoi. Jak ja dostaję marne grosze to firma musi dostać marnego pracownika. Podwyżki nigdy w życiu nie widziałem.

    W sumie to mogę pracować tak do 20 lat dopóki nie ogarną jak bardzo bezwartościową cegłę zatrudnili haha.

  • TheStory pisze:

    Często mam odczucie, że niektóre firmy wymagają od juniorów wymagań takich, jak na midów w niektórych firmach :) ale co zrobić

  • Bartosz Kostrowiecki pisze:

    >”Mid to osoba, która po pierwsze ma już jakieś doświadczenie zawodowe, przestaje się pytać wszystkich o wszystko no i większości review jej kodu, przechodzi bez większych zmian.”

    Jest tak dużo problemów z tym twierdzeniem, że nawet nie wiem od czego zacząć.

    Code Review nie jest po to, żeby odfajkować totalne głupoty i fajrant. To taka fajna rzecz, dzięki której można porozmawiać o designie, skonfrontować swoja propozycję rozwiazania z współpracownikami.

    Więc zakładanie, że Midem jesteś, jak się nikt na Code Review nie przyczepi jest co najmniej szkodliwe. Nawet jak się jest Seniorem, to warto konfrontować swój kod z opiniami innych. Ilość feedbacku na Code Review w żadnym wypadku NIE ŚWIADCZY O POZIOMIE DEVELOPERA.

    • Hej Bartek,

      Nigdzie nie napisałem, że code review mida powinno przechodzić bez poprawek. Napisałem – co zresztą sam zacytowałeś – że code review powinno przechodzić bez większych zmian. W całości zgadzam się z Twoją opinią, że code review to nie jest coś, co należy tylko odfajkować – to narzędzie, które daje sporo możliwości, aby stać się jeszcze lepszym programistą, nawet jeśli masz już tytuł seniora. Warto więc dążyć do tego, aby po zrobieniu pull requestu jak najmniej Twoich zmian było do poprawki, nie dlatego, że nikomu nie chce się tego przeglądać tylko dlatego, że są one dobrze napisane. Kiedy będą zdarzały się notoryczne sytuacje, że wszystko jest w porządku to może najwyższa pora, aby zmienić projekt/firmę?

Odpowiedz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Pin It on Pinterest