Junior, Middle, Senior. Co ich różni?

13 marca
Junior, Middle, Senior. Co ich różni?

Cześć! Nazywam się Alexander Demura i pracuję w IT od 2004 roku. Obecnie kieruję centrum rozwoju oprogramowania DataArt w Odessie (pochodzę z Petersburga, ale to zupełnie inna historia). Moje główne obowiązki to podejmowanie współpracy i pomoc w rozwoju naszych specjalistów, więc rozmowy na temat poziomu kwalifikacji oraz cech, które są potrzebne w konkretnych rolach są dla mnie czymś typowym i istotnym. Dla formalności pozwolę sobie na wyjaśnienie: artykuł ten bazuje na moich osobistych poglądach (na szczęście w DataArt to codzienność, nikt nie próbuje narzucać tu określonego sposobu myślenia). Tekst, który napisałem nie zawiera w sobie prawdy ostatecznej i nie będzie też zaskoczeniem, dla tych, którzy od dawna „siedzą” w temacie. Ale powinien być przydatny dla zaczynających swoją przygodę z IT i tych, którzy zastanawiają się, w którym kierunku poprowadzić swoją karierę, czują się niedoceniani albo – po prostu – chcą poszerzyć swoje horyzonty.

Na początku funkcjonowania, DataArt nie miało formalnej gradacji kwalifikacji. Zatrudnialiśmy ludzi do zespołu ze wszystkimi ich zaletami i wadami, a nie „kupowaliśmy” z rynku pracy kogoś o konkretnych funkcjonalnościach. Kiedy o tym myślimy dłużej, „junior”, „middle” i „senior” to tylko metki. Ale takie metki powinny być używane, by ujednolicić system oceny kwalifikacji i zwiększyć efektywność komunikacji – to wspólny grunt pod dyskusję z kolegami i klientami.

Pozwala to w wygodny sposób przeanalizować zestaw oczekiwań odpowiadający konkretnej roli. Ludzie rzadko idealnie mieszczą się w konkretnie zarysowaną ramę, a wydajność każdego specjalisty zależy od zróżnicowanych czynników. W związku z tym, prawie niemożliwe jest opracowanie narzędzi pomiaru jakości dla abstrakcyjnych wartości.

Na przykład – ktoś może świetnie radzić sobie w jakimś projekcie, ale nie być wybitny w drugim. Czego można spodziewać się od niego w trzecim projekcie? Niektórzy specjaliści potrafią idealnie odpowiedzieć na najbardziej złożone pytania techniczne, a potem wygenerować nieobsługiwalny kod. Z drugiej strony – specjalista może mieć trudności z rozwiązywaniem zadań na poziomie junior, ale mieć w swoim portfolio kilka tuzinów projektów zakończonych sukcesem. Zagłębianie się w takie niuanse, pomaganie ludziom w wykorzystywaniu ich mocnych stron i umiejętne traktowanie słabszych jest jednym z zadań managerów. Tu nie ma jednego dobrego rozwiązania, co sprawia, że praca managera jest interesująca, ale czasami trudna.

Stażysta

W DataArt mamy program stażowy, w którym mogą wziąć udział nawet ci, którzy nie posiadają doświadczenia. Mają 3 miesiące, by osiągnąć poziom juniora pod opieką doświadczonego mentora. Dla stażystów mamy 2 wymagania:

  1. Dobry angielski.
  2. Znajomość wybranych narzędzi i umiejętność ich użycia.

Znajomość angielskiego jest właściwie wymaganiem dla wszystkich. DataArt to firma międzynarodowa, większość naszych klientów pochodzi z USA i Europy Zachodniej i nawet komunikacja wewnętrzna coraz częściej jest prowadzona w języku angielskim. Jeśli ktoś jest wykwalifikowanym specjalistą technicznym, pomożemy mu w nauce języka. Właśnie do tego służą wewnętrzne kursy angielskiego i inne dodatkowe aktywności. Jeśli ktoś nie posiada doświadczenia technicznego (jest stażystą) i do tego nie zna dobrze angielskiego, powinien posiadać unikalne umiejętności, które zrekompensują wymienione braki.

Uważam, że kwestia narzędzi jest jasna – jeśli chcesz zostać programistą, twoim narzędziem jest język programowania i związane z nim narzędzia do rozwoju oprogramowania. Jeśli potencjalny stażysta chce się rozwijać w .NET, ale nie potrafi wyjaśnić, co to jest CLR, jak „Equals” różni się od „===” albo nie potrafi zaimplementować najprostszego algorytmu, nie będzie miał szansy rozpocząć stażu. Przychodzenie z zerową wiedzą i nadzieją, że nauczysz się od zera absolutnie wszystkiego, będąc jednocześnie wynagradzanym, nie działa – konkurencja jest za duża. Wielu kandydatów ukończyło po kilka profesjonalnych szkoleń, potrafi odpowiedzieć na wszystkie teoretyczne pytania i nawet posiadają prywatne doświadczenie w programowaniu. Oczywiście tacy ludzie mają pierwszeństwo.

Junior

Po odbyciu programu stażowego, stażysta staje się juniorem. Głównym wymaganiem na tym etapie jest umiejętność samodzielnego rozwiązywania zadań technologicznych. Jeśli w projekcie mamy do czynienia z daną architekturą, junior powinien być w stanie zaimplementować kolejną część przykładowej logiki aplikacji bez zastanowienia. Z drugiej strony - specjalista na poziomie junior ma prawo od czasu do czasu popełniać błędy, nie rozumieć wszystkich niuansów, dyskutować o planach związanych z implementacją i sprawdzać ukończony kod z team leadem.

Najważniejszymi cechami w przypadku juniorów są:

  1. Chęć rozwoju i nauki (szczególnie na błędach).
  2. Energia i poświęcenie.
  3. Umiejętność spokojnego przyjmowania krytyki.

Powinno się rozumieć, że zadania, które przez seniora rozwiązywane są w 10 minut, juniorowi mogą zająć godzinę lub dłużej, a kod może wymagać kompletnego przepisana, co wiąże się oczywiście z dużą ilością dodatkowej energii. Ważne, by się tego nie bać i znaleźć balans. Musisz wiedzieć, kiedy próbować i rozwiązywać zadanie samodzielnie, a kiedy przestać uderzać głową w mur (poświęcając na to czas w projekcie) i poprosić o pomoc. Próby usprawiedliwiania się argumentami: „przecież ciągle jestem juniorem” to nie jest dobry pomysł.

Middle

Głównym wymaganiem dla developerów na poziomie middle jest zdolność rozwiązywania zadań samodzielnie. Podobnie pisałem w poprzednim akapicie, prawda? Ale jest tu jeden istotny niuans, nie ma słowa „technicznych”. To znaczy, że na tym poziomie powinno się rozumieć także wymagania biznesowe i potrafić przełożyć je na rozwiązania technologiczne.

Zatem:

  1. Middle developer dokładnie rozumie funkcjonowanie aplikacji. Pozwala to na głębsze zrozumienie zadania, bardziej wnikliwą ocenę i efektywną implementację. Jeśli wymagania nie do końca pokrywają pewien scenariusz, developer na tym poziomie zwróci na to uwagę na etapie planowania. A nie wtedy, kiedy aplikacja zatrzyma się w wyniku niestandardowego działania użytkownika.
  2. Developer na poziomie middle zna standardowe wzorce i rozwiązania tworząc aplikację, rozumie do czego są potrzebne i wie, jak je aplikować. Standaryzacja rozwiązań jest istotna we wspólnym rozwijaniu kodu, ponieważ pozwala nowej osobie szybko zrozumieć, co jest czym i minimalizuje ilość błędów. Rozumienie struktury typowej aplikacji powoduje, że budowanie jej od zera jest raczej łatwe i pozawala na przedyskutowanie zasad poprawnej implementacji odróżnianie dobrej jakości kodu od kodu złej jakości.
  3. Specjalista na poziomie middle rozumie, że jeden żołnierz nie jest w stanie sam wygrać wojny. Wie, w jaki sposób komunikować się z członkami teamu – na przykład – przedyskutować trudną kwestię z designerem, wyjaśnić niekompletne wymagania z analitykiem biznesowym albo porozmawiać o ważnym rozwiązaniu technologicznym z architektem (jeśli jest on w teamie) oraz potrafi używać odpowiednich narzędzi do pracy zespołowej.

Senior

Doświadczony developer na poziomie senior, to ktoś, kto pracował z dużą ilością kodu, zrobił wiele błędów i był w stanie wyciągnąć z nich właściwe wnioski. Głównym zadaniem seniora jest podejmowanie właściwych decyzji technologicznych w projekcie. „Właściwe decyzje” to te, które przynoszą maksimum korzyści biznesowych i pozwalają minimalizować koszty. Prawdziwy senior nie tylko rozumie, jakie rozwiązania opracowuje zespół, ale także jakie kwestie powinna rozwiązywać aplikacja, która powstanie. Tworząc, na przykład, portal aukcyjny senior zapyta o szczytowe obciążenie i przewidzi ilość zapytań w bazie danych. Z wyprzedzeniem myśli o trudnościach w funkcjonowaniu systemów, skalowaniu, pamięta o problemach, które może spowodować nieprawidłowe użycie narzędzi.

Taki ekspert robi niesamowitą rzecz – rozwiązuje problemy zanim jeszcze się pojawią. Z zewnątrz przypomina to dar jasnowidzenia. Ale jeśli twój projekt żyje od problemu do problemu i ciągle trzeba wyrzucać i przepisywać fragmenty kodu, to symptomy tego, że projekt nie otrzymuje wystarczającej ilości uwagi seniora.

Po przemyśleniu, możemy sformułować kilka cech, które powinien posiadać senior developer:

  1. Umiejętność rozwiązywania kilku złożonych zadań oraz ukończenia ich szybciej i lepiej niż przeciętny specjalista nie ma nic wspólnego z poziomem senior. W naszej kwalifikacji taka osoba oceniana jest jako „Strong Middle”.
  2. Kwalifikacja na poziomie senior nie może być osiągnięta szybko. Ważne, by mieć szerokie doświadczenie i rozumieć, co odróżnia dobrze zrobiony projekt od „topornego”, jak manifestuje się dług techniczny, jakie są koszty refaktoringu, jakie wzorce są naprawdę potrzebne i czy niezbędne są nieskończone poziomy abstrakcji. Senior powinien podejmować decyzje samodzielnie i dać im czas potrzebny na sprawdzenie ich słuszności.
  3. Poziom seniora wiąże się także z wysoce rozwiniętymi umiejętnościami komunikacyjnymi, ponieważ trzeba nie tylko podejmować właściwe decyzje, ale także przekonywać do nich klienta i zespół. Jeśli nie jesteś w stanie obronić właściwej decyzji i zamiast tego została zaakceptowana ta niekorzystna, powinieneś winić o to siebie. Opcja „a nie mówiłem” nie działa na tym etapie. Podobnie wygląda kwestia pracy w zespole – nie wystarczy po prostu wiedzieć, jak coś powinno być zrobione, trzeba również potrafić zrozumiale to wyjaśnić. Wtedy zespół rozwija się szybko i zbiera doświadczenie z uniknięciem bolesnych błędów. Autorytatywne podejście („rób jak mówię”) często prowadzi do konfliktów wewnętrznych i kompletnego braku poprawy sytuacji w projekcie, więc powinno się go unikać.
  4. Senior nie poradzi sobie bez znajomości struktury bibliotek i frameworków. Jeśli podchodzisz do narzędzia do rozwoju oprogramowania patrząc na nie od zewnątrz (podejście „black box”) i składasz aplikację ze skończonych części bez wiedzy na temat tego, jak funkcjonuje każdy z nich, produkt zawsze będzie niestabilny i nieprzewidywalny.

Manager, który angażuje do projektu seniora zazwyczaj ma nadzieję na minimalizację ryzyka technicznego albo pełniejsze jego zrozumienie. Rzadko zdarzają się systemy, w których nie ma problemów – technologiczny perfekcjonizm często jest nieopłacalny z biznesowego punktu widzenia. Ale senior powinien potrafić wyłapać moment, w którym podstępne błędy powodują, że system przestaje gładko funkcjonować i zatrzymać ten proces zanim będzie za późno.