Junior Developer a Regular

Junior Developer a Regular – temat rzeka w wielu firmach.

Załóżmy hipotetycznie, że pracujesz jako Junior Developer. Masz rok doświadczenia. Znasz projekt, w którym pracujesz. Dlaczego jednak wszyscy cały czas mówią, że jesteś Junior Developerem? Dlaczego nie Regular Developerem? No właśnie, w tym tekście zastanowimy się przez chwilę, kiedy Junior Developer staje się Regularem?

Czy jedno kryterium wystarczy?

Odwieczne pytanie początkujących programistów, czy istnieje magiczny switch, który sprawa, że z Juniora przeobrażasz się w Regular Developera.

Przykro mi odpowiedź brzmi: nie.

Jednak nie należy się w tym momencie się załamywać, bo tak naprawdę można wyprowadzić tutaj bardzo łatwe kryterium, do którego spełnienia potrzebnych jest kilka warunków.

Wyprowadźmy więc teraz definicję kryterium bezpiecznego delegowania.

Kryterium bezpiecznego delegowania

W rozmowach z koleżankami i kolegami wielokrotnie zastanawialiśmy się nad tym, co tak naprawdę sprawia, że postrzeganie osób piastujących stanowisko Junior Developer zmienia się i w danej osobie widzimy już Regular Developera, który wnosi większą wartość do projektu.

W mojej opinii Regular Developer to osoba, której mogę powierzyć realizację danej większej funkcjonalności. Dlatego kryterium bezpiecznego delegowania zawiera następujące warunki konieczne dla osoby aspirującej do tej roli:

1. Rozumie ona kontekst realizacji danej funkcjonalności biznesowej.
2. Jest w stanie zrealizować daną funkcjonalność samodzielnie.
3. Mieści się z realizacją w ramach określonego czasu.
4. Dostarcza oczekiwaną jakość.

Przyjrzyjmy się dalej poszczególnym warunkom.

Warunek 1: Kontekst realizacji

W ramach wyjaśnienia odnośnie punktu 1. Na poziomie juniorskim nigdy nie spodziewam się, że adept programowania będzie rozumiał całkowicie kontekst biznesowy danego zagadnienia. Wynika on często z bardzo wielu składowych, dlatego łatwiej i szybciej jest wytłumaczyć, że np. dla danej kategorii klientów chcemy, żeby oferta była o 10% niższa – proste wymaganie, które nie wchodzi w dyskusję o sposobie wyliczania kategorii, przyznawania zniżek, etc.

Na poziomie Regulara spodziewałbym się bardziej pytań od programisty:

• Dlaczego dana oferta ma być niższa?
• Czy dla innych kategorii klientów też mogą być takie zmiany w przyszłości?

Tego typu pytanie wskazuje, że dana osoba zaczyna szerzej patrzeć na aplikację i chce wiedzieć więcej. A to oznacza, że jej kontekst zaczyna być szerszy.

Warunek 2: Samodzielność

Po roku oczekiwania wobec Ciebie rosną. Twoje doświadczenie powinno umożliwić Ci już realizację samodzielnie większych fragmentów funkcjonalności.

Co to oznacza w praktyce?

Po pierwsze dana osoba na podstawie swojego doświadczenia jest w stanie określić samodzielnie, gdzie daną funkcjonalność należy rozszerzyć (nie muszę wskazywać dokładnie linijki w kodzie, gdzie trzeba coś zmienić).

Po drugie w kontekście samodzielności nie spodziewam się już pytań dotyczących składni języka, podstaw danej biblioteki, czy też sposobu uruchomienia i przetestowania danego fragmentu kodu.

Zakładam, że proces kompilacji, testowania, commitowania, przekazywania do code review są rzeczami całkowicie znanymi.

Warunek 3: Wartość w czasie

W IT generalnie przyjęło się, że wszystkie zadania realizujemy w wyznaczonych timebox’ach. Jeśli dane zadeklarowany czas wykonania zadania to 1h, to nie spodziewamy się wyniku w postaci 8h. Jeśli dane zadanie ma zmieścić się w danym sprincie w metodzie Scrum, to też oczekujemy, że na koniec sprintu będzie zrealizowane.

Nie oznacza to sytuacji bycia nieomylnym. To tak nie działa. Zawsze estymacja czasowa jest tylko próbą przybliżenia docelowego wyniku czasowego. Jeśli bardzo się nie zgadza, to należy sprawdzić, gdzie leżała przyczyna i wprowadzić poprawki do procesu estymacji.

Prawda jest też taka, że w przypadku oprogramowania, które dany zespół realizuje od dłuższego czasu, estymacje będą cechowały się dużą dokładnością. A co za tym idzie, w kontekście ryzyka, spodziewane zagrożenia przekroczenia estymat będą mniejsze. Idąc dalej – będzie mniejszy margines błędu uwzględniany w wycenach.

I jeśli w takim zespole Junior Developer będzie cały czas przekraczał znacznie takie parametry, to będzie oznaczało, że nie jest jeszcze Regular Developerem.

Warunek 4: Jakość

A właściwie, co oznacza stwierdzenie, że kod jest dobrej jakości? Jako określić, czy dane wymaganie zostało zaimplementowane jakościowo dobrze?

Podejdźmy do tego bardziej technicznie. Czy wystarczy, że kod jest zgodny z przyjętymi przez zespół konwencjami, a podczas code review wychwycono mniejsze lub większe niedoróbki?

To za mało. Jakość kodu jest tylko jednym z elementów poprawnego rozwiązania. Gdzie zatem doszukiwać się bardziej rzetelnych czynników mówiących o jakości dostarczonego rozwiązania?

Nie trzeba szukać daleko. Miejscem tym są dobrze opisane wymagania biznesowe. A zatem każde wymaganie powinno mieć jasno określone warunki testowe. Jeśli jest to zadanie w ramach UI to powinno mieć określone makiety zmniejszające dystans miedzy tym, co oczekiwane, a tym, co dostarczone.

Różnica, Junior Developer a Regular, będzie tu bardzo wyraźna. Junior Developer będzie zapominał o wykonaniu testów, przejrzeniu makiet, ich dokładności. Od Regular Developera wymagamy, żeby proces obsługi przez niego strony jakościowej wymagania był pełny. Dbanie o jakość powinna być niejako nawykiem.

Podsumowanie

Choć kryteria przejścia z roli Junior Developera do roli Regular Developera są płynne, to mimo wszystko wydaje się, że można wydzielić kilka istotnych cech, które tę transformację oznaczają.

W tym artykule zdefiniowałem kryterium bezpiecznego delegowania, którym posługiwać się można przy ocenie Junior Developerów.

Mam nadzieję, że artykuł okaże się pomocny zarówno dla osób oceniających, jak i dla samych ocenianych. A dla tych drugich będzie drogowskazem rozwoju na tym etapie kariery programistycznej.

W serii Junior Developer ukazały się następujące wpisy:

1. Junior Developer w 2020 roku
2. Top 10 umiejętności Junior Java Developera
3. Junior Developer a Regular
4. Co tak naprawdę sprawdza rozmowa kwalifikacyjna na stanowisko Junior Developer?
5. Junior Developer 2020 – Podsumowanie