Przejście juniora w mida to proces. Jak go usprawnić? Devdebata

Juniorzy często wpadają w pułapkę uczenia się wszystkiego, po to żeby być lepszym. – Bywa to zgubne i nie przynosi efektów, bo w tym zawodzie proces uczenia się jest ciągły. Mid natomiast posiada wiedzę bardziej specyficzną, typową dla danego produktu, pogłębioną w konkretnych dziedzinach – opowiedział o różnicach Paweł Miry, Operative Product Owner w Ericsson.

Jak wygląda proces rozwoju juniora na mida? I jak można ten proces usprawnić? Tego dowiecie się z dzisiejszej devdebaty.

Odpowiedzi na pytania udzielili:

Joanna Lubiatowska, Software Developer w Ericsson. Absolwentka Informatyki na Politechnice Łódzkiej. Swoją karierę zaczęła od praktyk zawodowych na ostatnim roku studiów inżynierskich w firmie Ericsson w 2017 roku. Studia magisterskie ukończyła zaocznie, łącząc je z pracę zawodową. Obecnie członek oraz Scrum Master zespołu testerskiego. Zajmuje się testowaniem oraz rozwijaniem przypadków testowych na potrzeby sieci LTE.

Paweł Miry, Programista języków skryptowych (Python, Perl, Bash) oraz Operative Product Owner w Ericsson w zespole zajmującym się utrzymaniem systemu continuous integration. Pracę w Ericsson rozpoczął od praktyk zawodowych w 2016 r. Magister inżynier fizyki technicznej na Wydziale Fizyki i Informatyki Stosowanej AGH. Szkoleniowiec programowania. Po pracy zajęty rolą męża i opiekuna psiej córeczki.

Sławomir Komorowski, Software Developer w Ericsson. Absolwent Informatyki na Uniwersytecie Łódzkim. W firmie od 2017 roku w zespole pracującym w Continous Integration. Rozpoczynał od integracji narzędzi deweloperskich dla swojego projektu. Obecnie Ambasador marki Ericsson oraz główna osoba odpowiadająca za integrację produktów z zewnętrznych projektów do projektu, w którym pracuje ponad 200 programistów z całego świata. Testuje, poprawia oraz integruje zmiany zewnętrzne w projekcie.

Czym dla Ciebie różni się junior od mida? Kiedy zanika granica między jednym a drugim?

Joanna Lubiatowska, Software Developer w Ericsson:

Junior od mida różni się na pewno wiedzą i doświadczeniem. Nikt nie wymaga od juniora wiedzy o wszystkich narzędziach i procesach. Junior Software Developer to zwykle osoba świeżo po studiach, która ma podstawową wiedzę z zakresu programowania, testowania, tworzenia prostych projektów i pracy w małych grupach. Oczywiste jest jednak, że taki młody programista, świeżo po studiach nie będzie wiedział, w jaki sposób działają projekty komercyjne, które były rozwijane przez lata w zespołach rozrzuconych po całym świecie, jak to jest w przypadku projektów prowadzonych m.in. w naszej firmie.

Przeobrażenie juniora w mida to proces, który każdy przechodzi inaczej. Jedni potrzebują więcej czasu a inni mniej. Jest to raczej naturalna kolej rzeczy. Dzięki ciężkiej pracy, zaangażowaniu i pomocy bardziej doświadczonych kolegów junior staje się coraz bardziej samodzielny w swoich zadaniach. Dzięki czemu, po pewnym czasie zostaje midem, który ma już pewną wiedzę i doświadczenie, rozumie procesy, które go otaczają i jest w stanie dowozić swoje zadania i być za nie odpowiedzialny. Równocześnie nie oznacza to, że mid nie może zadawać pytań. W tym zawodzie bardzo ważna jest praca zespołowa. Niejednokrotnie juniorzy wnoszą do projektu świeże pomysły i rozwiązania, a seniorzy służą radą, która rozwiązuje problemy na pozór nie do rozwiązania.

Paweł Miry, Operative Product Owner w Ericsson:

Tak jak powiedziała Asia, przede wszystkim różnicą jest doświadczenie, ale poświęciłbym więcej uwagi kwestii wiedzy. Junior przychodzi do pracy z pewną dawką wiedzy unikalnej – zdobytej na studiach, podczas własnej nauki, z innych projektów, staży, praktyk, może bardzo dużo wnieść do projektu swoją świeżością. Nie ma jednak prawa wiedzieć, co z tego jest dokładnie potrzebne na danym stanowisku, choćby jego opis w procesie rekrutacyjnym był niezwykle precyzyjny. Może znać kilka języków programowania i technologii, ale raczej nie będzie w stanie ich użyć w projekcie bez pomocy kogoś doświadczonego.

Często wpada w pułapkę pt.: “jak będę umiał wszystko, to na pewno będę lepszy”, co bywa zgubne i nie przynosi efektów, bo w tym zawodzie proces uczenia się jest ciągły. Mid natomiast posiada wiedzę bardziej specyficzną, typową dla danego produktu, pogłębioną w konkretnych dziedzinach. Może znać tylko jeden język programowania lub – tak jak w projekcie, w którym pracuję – nawet konkretne skrypty i ich działanie.

O “midzie” mówimy wtedy, kiedy developer potrafi w skończonym zaplanowanym czasie, doprowadzić zadanie do finału, zdobyć szybko umiejętności, których nie posiada, zadać odpowiednie pytanie osobie doświadczonej lub – co może zabrzmieć przewrotnie, ale oszczędza sporo czasu w pracy zespołu – otwarcie przyznać się, że nigdy z daną technologią nie pracował i nie jest w stanie wykonać taska, którego lepiej będzie powierzyć komuś innemu. Mid zadaje więcej pytań, bo jest bardziej świadomy niewiedzy. Wreszcie mid często może popełniać więcej błędów, bo podejmuje się ambitniejszych zadań, ale w razie wpadki jest w stanie nad pewnymi sprawami lepiej zapanować niż junior. Zatem do wiedzy i doświadczenia dodałbym odpowiedzialność.

Granica nie przypada wtedy, kiedy posiądzie się nieskończoną ilość wiedzy, ale wtedy, kiedy programista ma poczucie, że “wie, gdzie szukać/kto to wie” i z tej wiedzy życiowej potrafi skorzystać sprawniej niż z książkowej. I wtedy jest dobry czas, żeby zacząć dopytywać o awans.

Sławomir Komorowski, Software Developer w Ericsson:

Dla mnie junior od mida zdecydowanie różni się wiedzą i doświadczeniem. Stanowisko juniora w Ericsson było moją pierwszą pracą w naprawdę dużej firmie. Projekt był dość duży i zrozumienie wszystkich zależności siłą rzeczy musiało zająć troszkę czasu. Od juniora nikt nie wymaga zaawansowanej wiedzy na samym początku. Oczywiste jest, że potrzebna jest podstawowa wiedza i umiejętności z branży, ale generalnie junior jest osobą, która w trakcie pracy z zespołem z osobami bardziej doświadczonymi uczy się wszystkich zależności, procesów zachodzących w projekcie i poszerza swoją wiedzę, która procentuje z każdym dniem.

Junior bardzo często jest tzw. “świeżym oddechem” w zespole. Szczególnie to widać po kilku miesiącach pracy, gdy takie osoby poruszają się już sprawnie w projekcie, pozbywają się tej niepewności osób początkujących i potrafią wnieść coś świeżego i nowego do projektu. Pokazują śmiałe rozwiązania, których czasami nie powstydziliby się starsi stażem pracownicy. Bycie juniorem to też czas, w którym odkrywam siebie w większym projekcie – uczymy się zarządzać własnym czasem w pracy oraz godzić różne obszary projektu, spinając je w całość w naszych zadaniach. Jest to też poziom gdzie szukamy drogi dla siebie – czy chcemy być bardziej techniczni, czy może chcemy w przyszłości bardziej zarządzać projektami.

Mid z kolei jest już osobą dużo pewniejszą we własnych działaniach w projekcie – ze swojej perspektywy mówiąc, jest osobą, która zdecydowanie częściej bierze ciężar zadania i odpowiedzialności na swoje barki. Osobą nie bojącą się wyjść przed szereg i powiedzieć w szerszym gronie: “Słuchajcie, mam pomysł, który może być rozwiązaniem naszego problemu“. Przejście między jednym stopniem a drugim, dla każdej nowej osoby jest wyjątkową drogą dostępną tylko dla niej – według mnie nie ma takich samych dróg i każdy idzie troszkę inną ścieżką. Tak jak wspomniała Asia, jedna osoba potrzebuje nieco dłuższej drogi a kolejna nieco krótszej. Pełnym midem stajesz się faktycznie, gdy wiesz gdzie szukać rozwiązania lub już często sam wiesz jak dane rozwiązanie zaprojektować i wcielić życie.

Po jakim czasie od rozpoczęcia pracy na stanowisku juniora zostałeś/aś midem? Opisz jakie zadania w tym czasie realizowałeś/aś.

Joanna Lubiatowska, Software Developer w Ericsson:

Zostałam midem po półtora roku pracy na stanowisku juniora, nie wliczając w to praktyk zawodowych, od których zaczęłam moją przygodę w Ericsson. Od samego początku pracuję w zespole testerskim, w którym zajmuję się zarówno testowaniem oprogramowania nadajników telekomunikacyjnych LTE, jak i automatyzacją przypadków testowych w Javie. W czasie, w którym zostałam midem zajmowałam się przygotowaniem przypadku testowanego, który miał za zadanie symulować zakłócenia, a następnie analizował i wyłapywał błędy powstające podczas nieoczekiwanych przerwań połączeń pomiędzy urządzeniami w sieci LTE. W tym samym czasie zastępowałam również Scrum Mastera przez kilka miesięcy podczas jego delegacji, a po pewnym czasie sama zaczęłam pełnić tę funkcję na stałe.

Paweł Miry, Operative Product Owner w Ericsson:

Podobnie jak Asia, półtora roku, często to u nas tak wygląda. Młodzi programiści mają dużo czasu, nie muszą się spieszyć. Ale jeśli programista przez czas do dwóch lat nie jest w stanie wejść w doroślejsze buty mida, to może jednak nie jest to dla niego odpowiedni zawód i koniec tego okresu, jest tego wyraźnym sygnałem.

Po rozpoczęciu pracy w obecnym dziale dostawałem oczywiście najprostsze taski – poprawić działanie skryptów, dodać jakąś drobną funkcjonalność, uprościć kod, pozbyć się warningów, itp. Oczywiście wszystko pod pilnym nadzorem osób doświadczonych. Specyfika naszego systemu continuous integration polega na tym, że pracujemy na “żywym organizmie”. Możemy przetestować większość standardowych przypadków, a niespodziewanie pojawić się może niestandardowe działanie już na serwerach produkcyjnych. Oczywiście nie chodzi tu o niesławne “testowanie na produkcji”, tylko niespodziewana sytuacja spowodowana ogromną liczbą połączeń w skryptach i narzędziach. I tutaj przydaje się szybka reakcja osób doświadczonych. Junior może nawet nie być świadomy, że jego świetnie napisany i przetestowany kod coś zepsuł w dalszych etapach.

Z czasem coraz więcej rzeczy byłem w stanie wykonywać samodzielnie, zajmować uwagę osobom doświadczonym głównie w przypadkach, kiedy naprawdę nie wiedziałem jak zacząć, a w końcu – co jest dość specyficzne dla naszego systemu pracy, przypominającego Kanban – samodzielnie wybierać taski, które jestem w stanie zrobić. Zarówno wtedy, kiedy wiedziałem dokładnie, jak coś wykonać, jak i w przypadkach, gdy chciałem się nauczyć nowych rzeczy na konkretnych przykładach. I to był taki rozmyty w czasie moment, kiedy poczułem, że mogę już przestać być juniorem. A to akurat zbiegło się mniej więcej z momentem, kiedy przyszedł standardowy czas zmiany stanowiska.

Sławomir Komorowski, Software Developer w Ericsson:

Moje przejście z juniora na mida miało miejsce po roku czasu pracy w Ericsson. Od samego początku pracowałem w zespole Integrującym pracując w continous integration. Pracowałem nad integrowaniem trzech narzędzi developerskich dla programistów, pracujących w naszym projekcie (ponad 200 programistów z całego świata). Dokonywałem również zmian w naszych skryptach, które optymalizowały i automatyzowały nasze testy i przyspieszały proces integracji.

Następnie dostałem pod opiekę narzędzie, przy pomocy którego integrowałem produkty z zewnętrznych projektów, używane w naszym projekcie, jednocześnie cały czas opiekując się i integrując narzędzie developerskie. Pod koniec pracy juniora wszedłem również do pracy przy ścisłej integracji naszego głównego produktu, który jest dostarczany do wyższych projektów, a koniec końców trafia do klientów z zewnątrz firmy.

Co miało większy wpływ na awans: liczba przepracowanych miesięcy na stanowisku juniora czy poziom trudności projektu, zadań?

Joanna Lubiatowska, Software Developer w Ericsson:

Myślę, że w moim przypadku decydujący był poziom trudności zarówno projektu, jak i zadań. Przy większości projektów IT wykorzystywane są zwinne metody zarządzania projektami takie jak Scrum, w którym ja osobiście pracuję. Dzięki temu członkowie zespołu nie mają ściśle z góry narzuconych zadań. Oczywiście są takie, które mają wysoki priorytet i należy je wykonać, ale członkowie zespołu mogą sami zdecydować, kto chce się zająć konkretną pracą, równocześnie oceniając, ile czasu zajmie im jej wykonanie. Możliwość wzięcia na siebie nowych wyzwań pozwala się wykazać oraz zdobyć wiedzę i doświadczenie, które wpływają na awans.

Paweł Miry, Operative Product Owner w Ericsson:

Jak już powiedziałem wyżej, w moim przypadku rekomendacją była m.in. liczba przepracowanych miesięcy, która dała sygnał: “hej, od dzisiaj będziesz miał większą odpowiedzialność”. Poziom trudności nie powinien być, moim zdaniem, żadnym wyznacznikiem – sam do dzisiaj czasami biorę proste zadania. Zarówno wtedy, kiedy trzeba coś szybko naprawić i system nie może czekać, aż junior sobie z tym poradzi, jak i kiedy po ludzku mam słabszy dzień i potrzebuję się dowartościować jakimkolwiek skończonym taskiem. Poza tym poziom trudności zależy od doświadczenia – zadanie, które osoba doświadczona robi analogicznie po raz kolejny zawsze jest “proste”, a dla juniora może stanowić wyzwanie nie do przejścia.

Sławomir Komorowski, Software Developer w Ericsson:

W moim przypadku zdecydowanie był to poziom trudności projektu oraz zadań. Co za tym idzie, otrzymując coraz trudniejsze zadania rosła moja wiedza oraz moje doświadczenie. Stawałem się bardziej widoczny w projekcie i zauważalny. Rozwiązywałem cięższe przypadki, opierając się już na wcześniejszych doświadczeniach, jednocześnie zadając pytania tylko wtedy, gdy naprawdę utknąłem. Wykazywanie się w cięższych przypadkach problemów procentowało nie tylko większym doświadczeniem, ale jednocześnie przybliżało mnie do wskoczenia na wyższy poziom jakości pracy i awansu.

Oferty pracy z

Co mogło przyspieszyć awans z juniora na mida, a co mogło go przedłużyć?

Joanna Lubiatowska, Software Developer w Ericsson:

Tak jak wspomniałam wcześniej, to od nas zależy, jak szybko się uczymy i zdobywamy doświadczenie. Myślę, że bardzo ważne jest czerpanie przyjemności z wykonywanej pracy, ponieważ wtedy sami czujemy potrzebę rozwoju i nauki. Jeśli dodatkowo mamy obok starszych współpracowników, którzy służą swoją pomocą, to na pewno przejście z juniora na mida nie będzie problemem.

Paweł Miry, Operative Product Owner w Ericsson:

Wspominałem już o “uczeniu się dla uczenia” – czasami młodzi programiści mają tendencję do przedłużania okresu wdrażania, uczenia się pewnych technologii na zapas, zapisywania się na wszystkie możliwe szkolenia. Trochę generalizuję, ale sam też miałem takie tendencje. Zdobycie pewnych podstaw teoretycznych przed zabraniem się za zadania nie jest złe i ja tak często robię, ale trzeba wiedzieć, kiedy od teorii przejść już do wykonywania zadań i w ich trakcie doszukiwać się dodatkowych zakamarków dokumentacji. To jest trochę zgodne z częstą poradą dla niedoświadczonych na forach “wymyśl sobie projekt i ucz się przez praktykę” – a w naszym przypadku: “bierz kolejne taski i w trakcie dowiesz się, czego jeszcze nie wiesz”.

Sławomir Komorowski, Software Developer w Ericsson:

Zdecydowanie, aby ten proces przebiegał szybko, niezbędne jest zaangażowanie ponad to, co jest przed nami stawiane. Aby było zaangażowanie musisz również lubić to, co robisz. Jeśli praca, którą wykonujesz, sprawia Ci przyjemność, to będziesz wykazywał się również zaangażowaniem w zadaniach. Człowiek będzie dociekał rozwiązań, szukał kontaktów, nowych ścieżek rozwiązywania postawionych przed nim zadań. W całym procesie ważne jest również, aby nie bać się błędów, które zawsze wystąpią – najważniejsze jest wyciągnąć z nich odpowiednie wnioski na przyszłość tak, aby ich uniknąć.

Ważne też, aby wyjść poza swoją strefę komfortu i spróbować zmierzyć się z czymś nowszym, co sięga trochę dalej niż nasz własny projekt, a jednocześnie jest z naszą pracą powiązane. Wiele zależy od podejścia do pracy. Co może przedłużyć proces rozwoju? Zdecydowanie brak zaangażowania, brak chęci, aby wyjść przed szereg, by spróbować trochę się rozwinąć i zaznaczyć nieco bardziej swoją obecność w projekcie. Myślę również, że pozostanie w bezpiecznych zadaniach, które już poznaliśmy na dłuższą metę, może spowolnić nasz rozwój.

Co zmieniło się po zostaniu midem?

Joanna Lubiatowska, Software Developer w Ericsson:

Co się zmieniło dla mnie to na pewno samodzielność i poczucie odpowiedzialności za wykonaną pracę oraz za jej jakość. Dodatkowo jako mid mam wiedzę, którą w razie potrzeby mogę przekazywać kolegom z mniejszym stażem. Jednak zostanie midem to nie tylko dodatkowe obowiązki i odpowiedzialność, ale też idące za nimi zarobki, które wynagradzają wysiłek włożony w pracę.

Paweł Miry, Operative Product Owner w Ericsson:

Mniej więcej w tym czasie kierownik zaczął mnie tytułować “team leaderem”. Z rzeczy nienamacalnych też na pewno wspomniana już odpowiedzialność – jeśli jesteś juniorem, to w razie błędu zawsze możesz bronić się niewiedzą, znajomością systemu, niewystarczającą pomocą seniorów. Midowi już nie wypada, zdarzało się czasem porzucić aktualne zadania albo zostać po godzinach, żeby naprawić skutki swoich wpadek. Ale żeby nikogo nie przerażać, wrócę do tego, że mid pewnie popełnia więcej błędów niż junior, bo nie popełnia ich tylko ten, który nic nie robi albo boi się cokolwiek zepsuć. Jeśli zaś chodzi o zmiany materialne, nie jest chyba tajemnicą, że mid może sobie pozwolić na zakup większej liczby zabawek.

Sławomir Komorowski, Software Developer w Ericsson:

Większa przestrzeń zadań w projekcie, za które osobiście odpowiadam. Większa samodzielność w działaniu, ale co za tym idzie również większa odpowiedzialność za popełniane błędy. Zdarzało się naprawiać nieco “po cichu” konsekwencję swoich nie do końca sprawdzonych działań wieczorem, tak aby rano flow było w pełni sprawne. W międzyczasie udało mi się wyszkolić dwóch świeżych juniorów oraz zostać jednym z liderów zespołu, w którym pracuję od początku mojej pracy w firmie.

Nadal zadajesz pytania starszym kolegom, czy jesteś w pełni samodzielny/a?

Joanna Lubiatowska, Software Developer w Ericsson:

Zadaje pytania, ale też na nie odpowiadam. Jak to mówią „Kto pyta, nie błądzi”. Zawsze warto zadawać pytania, nawet jeśli ktoś jest seniorem. Między innymi dlatego pracujemy w zespołach, aby móc wzajemnie sobie pomagać, bo w końcu wszyscy mamy wspólny cel, którym jest dostarczeniem produktu do klienta. Niejednokrotnie świeże spojrzenie na problem pomaga w jego rozwiązaniu.

Paweł Miry, Operative Product Owner w Ericsson:

Zadaję jeszcze więcej pytań niż w pierwszych latach pracy, bo wiem kogo i o co zapytać. Kiedy zostaje się midem czy seniorem, należy przestać się wstydzić, że się czegoś nie wie. Niektóre technologie są tak specyficzne dla naszego projektu, że ciężko znaleźć odpowiedź w pewnej znanej wyszukiwarce. Nieraz jedynym sposobem jest dopytać twórcy danego skryptu, co akurat miał na myśli 10 lat temu, pisząc konkretną linijkę. Poza tym w dyskusjach z większą liczbą osób sprawdza się metoda gumowej kaczuszki. Nieraz zadając powoli konkretne pytanie, sam sobie udzielasz odpowiedzi, zanim skończysz je zadawać. Warto pytać, zawsze, w najgorszym razie nie dostanie się odpowiedzi i zostanie w tym samym punkcie, a często samo zadanie pytania posunie sprawę do przodu.

Sławomir Komorowski, Software Developer w Ericsson:

Nie ma opcji, by nie pytać. Z każdym wyższym poziomem rozwoju pojawiają się pytania. Zmienia się ich złożoność i poziom techniczny. Jak wspomnieli już moi koledzy “kto pyta nie błądzi”. Jeśli nie pytasz, to znaczy, że się nieco zatrzymałeś. Pytasz po to, by się dowiedzieć czegoś nowego, uzupełnić wiedzę – rozwinąć się bardziej. Będąc czy mid-em, czy seniorem, zawsze są pytania i to jest naturalny proces, którego nie ma co się wstydzić. W swoich zadaniach jestem samodzielny i często to ja udzielam odpowiedzi, dzieląc się wiedzą i doświadczeniem, które wypracowałem przez ostatnie trzy lata spędzone w Ericssonie.

Jak wspierać juniorów w rozwoju, by szybciej zostali midami?

Joanna Lubiatowska, Software Developer w Ericsson:

Myślę, że należy pamiętać jak to było, gdy sami byliśmy juniorami i potrzebowaliśmy wsparcia. Trzeba być wyrozumiałym, cierpliwym i pomocnym w razie potrzeby, ale należy też dawać możliwość wykazania się i zaangażowania w trudniejsze zadania. Nie zawsze coś, co jest zrobione szybciej przez nas oznacza, że jest to zrobione lepiej. Każdy musi się nauczyć wykonywać swoje obowiązki, nawet na własnych błędach. To rozwija kreatywność i samodzielność, co prowadzi do awansu na mida, o którym dzisiaj rozmawiamy.

Paweł Miry, Operative Product Owner w Ericsson:

Zlecać dużo zadań i wspierać w ich kończeniu. Pamiętać o tym, że w okresie bycia juniorem największą frustrację może wywołać otrzymanie odpowiedzi “doczytaj sobie w dokumentacji” czy “wymyśl jak to zrobić”. Zwiększać odpowiedzialność. Jako senior odpowiedzialny obecnie za wdrażanie kilku osób, mogę też dopowiedzieć w praktyce: dzielić się swoimi zadaniami albo dzielić swoje zadania, tak żeby ich część mogła być wykonana przez inne osoby. Wtedy wszyscy korzystają.

Sławomir Komorowski, Software Developer w Ericsson:

Z mojej perspektywy dzielić się doświadczeniem, które samemu się już posiada. Wskazywać ścieżki rozwiązywania problemów, ale jednocześnie dawać się wykazać w działaniach naszym młodszym współpracownikom, czyli nie podawać rozwiązania na tacy, ale dać możliwość samodzielnej pracy. Delikatnie podpowiadać, jeśli trzeba jednocześnie należy zostawić pole do samodzielnego działania. Należy okazywać zaufanie dając nowe zadania nowym juniorom i samemu z pozycji mid-a/seniora pamiętać, jak to było jak sami zaczynaliśmy, mieć cierpliwości i wyrozumiałość do popełnianych błędów, bo takowe z pewnością się zdarzają każdemu.

---

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z