Jak stworzyć juniorowi warunki do rozwoju? Devdebata

W jaki sposób firma może przygotować miejsce dla juniora, w którym będzie mógł szybko rozwijać się? To główne pytanie jakie zadaliśmy zaproszonym senior developerom, których poprosiliśmy o to, by odpowiedzieli o swojej ścieżce od juniora do seniora oraz o to, by poradzili, w jaki sposób junior może podnosić swoje umiejętności. Jak odpowiedzieli na pytanie z tytułu artykułu?

– [Warto] promować atmosferę, w której nie boimy się zadawać pytań. Należy postawić na współpracę, często dawać feedback, organizować sesje pair programmingowe, stawiać na jakość tworzonego kodu, robić code review i nie zapomnieć o tej ludzkiej stronie procesu wytwarzania oprogramowania. Jest to nie tylko dobre dla rozwoju juniorów, ale także każdego pracownika w firmie – mówi Michał Załęcki, Senior Software Engineer w Tooploox, jeden z uczestników devdebaty.

Na pytania odpowiedzieli:

Krzysztof Hasiński. Software Engineer z ponad dekadą doświadczenia. Pisał aplikacje webowe, natywne i oprogramowanie dla dużych klastrów obliczeniowych. Posiada komercyjne doświadczenie z kilkunastoma językami programowania, chociaż obecnie głównie zajmuje się wyłącznie Ruby. Uważa, że kod najlepiej oceniać po tym jak łatwo można go wymienić lub pozbyć się całkowicie. Oprócz kodowania lub język angielski (a zwłaszcza fonetykę), japoński (chociaż dopiero zaczyna naukę) i gry, także te retro.

Michał Załęcki. Senior Software Engineer w Tooploox. Zajmuje się tematyką blockchain oraz tworzeniem zdecentralizowanych aplikacji. Michał prowadzi warsztaty BlockchainPro oraz organizuje spotkania grupy ReactJS Wrocław. Jeżeli chcesz poczytać więcej na tematy związane z blockchain zajrzyj na bloga michalzalecki.com.

Sebastian Gruchacz. Programista .Net / C# od 15 lat. Jako członek zespołów wewnętrznych i jako konsultant w ciągu ponad 17 lat pracy zawodowej zajmował się rozmaitymi aspektami wytwarzania oprogramowania (od frontendu po asembler), dev-opsem, lokalizacją i testami automatycznymi, analizą i architekturą, szkoleniami i prowadzeniem zespołów. Aktualnie, przez większość czasu, jako Starszy Programista .Net, wspiera rozwój duńskiej platformy zakupowej Justt, w wolnym czasie rozwija własne projekty i bloguje.

Paweł Wieczorek. Senior Fullstack Developer w Chop-Chopie. Na co dzień programuje web aplikacje głównie w JavaScript, React i Node. Nieobce są mu także TypeScript, Express, PHP, Laravel i SQL. Entuzjasta dobrze zorganizowanego kodu i stała pomoc dla zespołu developerskiego, któremu pomaga rozwijać umiejętności. Po godzinach marnuje czas na granie i czytanie, a mógłby kodzić.

Adam Włodarczyk. Właściciel firmy Hindbrain tworzącej oprogramowanie na urządzenia mobilne oraz systemy CRM w różnych technologiach. Jego ulubionymi językami są Java i Objective-C, chociaż próbuje też sił w językach takich jak Kotlin czy Swift. Zdarza się, że nawet czasem pokoduje w PHP’ie. Żeby dać ujście ekstrawertycznej części swojej osobowości, uczy i jest mentorem kolejnego pokolenia programistów w Coderslab. Po godzinach stara się dbać o kręgosłup pływając i ćwicząc na siłowni.

1. Jak przebiegała Twoja ścieżka kariery, od juniora do seniora?

Odpowiada Krzysztof Hasiński, Senior Software Engineer:

Programować zacząłem jeszcze jako siedmioletni dzieciak. Pierwszą pracę dostałem w małej agencji marketingowej robiąc proste strony w PHP, HTML, CSS. Co ciekawe była to praca zdalna. Podczas studiów znalazłem pracę w firmie produktowej tworzącej oprogramowanie dla edukacji i nauczyłem się pracy w zespole. Następnie wyjechałem na rok do USA, gdzie pracowałem na uniwersytecie.

Dalej co prawda byłem juniorem, ale nauczyłem się profilować aplikacje i optymalizować wydajność. Przez rok pracy miałem styczność z projektami w kilkunastu różnych, często egzotycznych językach i technologiach. Z uwagi na to, że aplikacje uniwersyteckie wymagają potężnych komputerów (tysiące rdzeni, terabajty pamięci) miałem okazję poznać w praktyce zagadnienia związane ze skalowalnością.

Po powrocie do Polski chciałem ponownie zająć się aplikacjami internetowymi i dołączyłem do malutkiego wtedy software house’u. Zaczynałem jako mid-level, ale już po drugim oddanym projekcie dostałem awans na seniora. Z perspektywy czasu stwierdzam, że tytuł ten nie miał żadnego znaczenia.

Software house pozwala zobaczyć wiele tematów w krótkim czasie, ale ogranicza przywiązanie do produktu. Projekty zaczęły mi się zlewać, a praca wydawała się nudna mimo ciekawych wyzwań (pisaliśmy m.in. giełdę przestrzeni reklamowej dla aplikacji mobilnych, repozytorium obrazków z autoskalowaniem przy zachowaniu twarzy na zdjęciach oraz wielki portal z ogłoszeniami pracy reklamowany w fińskiej telewizji).

Zacząłem po godzinach eksperymentować z własnymi pomysłami na startup i założyłem firmę z dziewczyną. Szybko jednak projekt ten sprzedaliśmy i dołączyłem do innego startupu, tym razem jako lead engineer i zdalnie.

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:

Mój pierwszy epizod jeszcze nie z językiem programowania, a z HTML i CSS miał miejsce w gdzieś w 4 lub 5 klasie szkoły podstawowej, gdy rodzice wysłali mnie i młodszego brata na zajęcia dodatkowe z informatyki. Zajęcia miały bardziej charakter zbiorowej gry w Age of Empires II, niemniej wtedy napisałem pierwszą stronę z pięknymi animacjami za pomocą tagu <marquee>. Zajęcia się skończyły i zapomniałem o temacie.

Na początku gimnazjum znowu poszedłem na zajęcia dodatkowe z informatyki – tym razem miało to być programowanie w C# od podstaw. Znalazłem się w grupie starszych dzieciaków, których poziom w mojej ocenie nie był początkujący. Wyobraź sobie, że nie wiesz jak działa pętla for – co tam for, nie wiesz czym jest zmienna, a na pierwszych zajęciach mieliśmy napisać kalkulator! Poległem. Tak mnie to doświadczenie zraziło do C#, że moje drugie, przelotne spotkanie z tym językiem miało miejsce kilka lat później – na drugim roku studiów.

Pod koniec gimnazjum jako aspirant na ucznia Technikum Elektronicznego w Bydgoszczy dostałem możliwość poprowadzenia dla mojej klasy kilku zajęć z HTML i CSS na “szóstkę”. Szansę wykorzystałem i to tak naprawdę wystartowało moją karierę programisty. Naturalnym wtedy krokiem rozwoju polskiego “webmastera” była nauka PHP, MySQL oraz JSa do robienia menu.

W trzeciej klasie technikum trzeba było odbyć miesięczną praktykę. Zahaczyłem się wtedy w agencji interaktywnej SasDesign, pisałem w PHP i Angularze, poznałem trochę rozwiązań e-commercowych, a po praktykach zostałem na dłużej.

Kolejna praca, tym razem w Monterail pozwoliła mi zamknąć rozdział programowania w PHP i pokazała zupełnie nowy świat – świat języka Ruby i frameworka Ruby on Rails. Po Monterail byłem zafascynowany ideą pracy zdalnej i dołączyłem do duńskiego woumedia. W woumedia mieliśmy własny produkt, na którym się skupiliśmy – Contractbook. Niedawno mogliście o nim przeczytać na Spider’s Web. Po dwóch latach w Contractbooku przyszedł czas na zmiany – poszedłem pracować we wrocławskim Tooploox, już jako senior engineer.

Odpowiada Sebastian Gruchacz, Programista .Net / C# od 15 lat:

Mój pierwszy kontakt z komputerem to sesja F1 na bursztynowym monitorze w redakcji Bajtka, gdzieś w okolicy roku 86. Totalne zauroczenie. Widząc moje zainteresowanie rodzice kupili mi “jakąś” książkę o programowaniu. Prolog. Uch. Wymieniliśmy na Logo. A potem jeszcze jedna książka z podstawami Basica dla dzieci. A komputer w domu pojawił się dopiero jakiś czas później, jak byłem w czwartej klasie – Atari 65XE. Miałem dostęp do kilku czasopism o programowaniu, udało mi się dorwać do kserowanej dokumentacji (mapa pamięci, assembler, Basic) i zaczęła się moja pasja. Głównie Basic, ale bawiłem się też Logo, Assemblerem, Action czy Fortranem. Niestety, czas z komputerem miałem bardzo ograniczony, przez co większość kodu pisałem tylko na papierze (ale już wtedy kolorując składnię różnymi długopisami) – i tylko niewielką część tego wprowadzałem do komputera.

Dopiero gdy byłem w liceum pojawiała się w szkołach informatyka i miałem okazję na ponowny kontakt z PC. Ale zero programowania w tamtych czasach – co najwyżej bazy danych, edytory tekstu itp. Swój komputer “nabyłem” dopiero po zaliczeniu matury i się zaczęło na poważnie: Turbo Pascal, HTML, Delphi, C/C++… Najpierw uczyłem się tego sam, potem na uczelni doszły takie rzeczy jak Unix, bazy danych i teoria oraz jeszcze więcej Delphi. A tymczasem w pracy robiłem w charakterze full-stacka: ASP (classic ;-)) – pisane w VBS, SQL Server 2000, JavaScript (jeszcze czasy przed Ajaxem, o jQuery nie wspominając!) i HTML, CSS i PhotoShop. Spotkania z klientami, zbieranie wymagań, projektowanie UI i DB – totalny full-stack. Firma padła, a ja zatrudniłem się gdzie indziej, ale na podobnym stacku. Potem pojawił się .Net i najpierw nieśmiało, jeszcze w Visual-Basicu zacząłem się wciągać. Dopiero potem, gdy dałem się namówić do spróbowania C# odkryłem swoje miejsce na świecie. A jak już pojawiła się wersja 1.1 i typy generyczne w 2.0 byłem przeszczęśliwy.

Potem kolejna firma i praca przy lokalizacji oprogramowania – praca z zasobami, skryptami (bash), programami do lokalizacji, ale potem tworzenie oprogramowania do automatyzacji testów, zarządzania wirtualkami, automatyzacji budowania itd. Potem kolejna firma i mieszanina technologii webowych. Otwarcie działalności, kolejne kontrakty, dłuższe i krótsze. Czasem tylko do gaszenia pożarów, a czasem do ciekawych projektów. Plejada projektów, technologii, ludzi i metodyk. Programowanie, testowanie, projektowanie, analizowanie, rozmowy z klientami jako analityk i sporządzanie dokumentacji. Front-end i backend. SQL i skrypty do budowania. Scrum, Kanban i pseudo-scrum. Epizod z OpenCl i C++. Praca zdalna i wyjazdowa, małe teamy, którym “lekko leadowałem”. Były też rozmowy rekrutacyjne, szkolenia, warsztaty i meetupy. A potem chmura, devops, a później brutalny powrót do rzeczywistości front-endu (Angular). I znowu backend. SQL i micro-serwisy.

Takim człowiekiem orkiestrą jestem – dwa miesiące na zmianę prowadzę zdalny team programistów (jako product-owner, człowiek od code-review i opracowywania szczegółowych wymagań na podstawie jednego zdania instrukcji”z góry”). Zajmuję się programowaniem lokalnej wersji systemu na mikroserwisach, w dokerze (pierwszy kontakt) i do tego robię analizę konfiguracji innego systemu, dla innego zdalnego konsultanta. Później przez dwa tygodnie dziergam skrypty w PowerShellu (jednocześnie uczę się, bo wcześniej nie za wiele w tym robiłem), odpalam je na maszynach w sieci i zbieram rozmaite dane oraz parametry. Potem nagle opieka nad usługą w ASP.Net, konwersja operacji z SQL 2016 do SLQ 2014. Tydzień później pierwszy kontakt z Node.js, rozbudowa jakichś skryptów do raportów, potem ELK stash, konfiguracja i zabawy z aplikacjami satelitami. A w międzyczasie opracowanie wymagań dla innych programistów oraz przygotowywanie warsztatów dla juniorów. Słowem, na nudę nie narzekam ani na zarobki. Gdzieś tam jeszcze po drodze piszę jakieś programy dla siebie i sporadycznie bloguję mniej lub bardziej technicznie.

Odpowiada Paweł Wieczorek, Senior Fullstack Developer w Chop-Chopie:

Dość ciężko. Swoich pierwszych projektów sprzed czterech lat nie wspominam za dobrze, chociaż mam sentyment do siedzenia do późna i wylewania z siebie ostatnich potów, tylko po to by dowieźć projekt na czas. I o ile moje stare projekty wyglądają i funkcjonują do dziś w tej samej formie, to raczej nie jestem zadowolony z jakości ich kodu.

Będąc juniorem, jak to zwykle bywa, podglądałem pracę tych bardziej doświadczonych devów. Dość częstą praktyką w firmie było dołączanie bardziej doświadczonego deva do projektu, który otrzymał do wykonania junior. Zazwyczaj podział obowiązków był taki – junior (w tym wypadku ja) robił markup, a mid/senior podpinał te wypociny pod CMSa (WordPress), a w razie potrzeby wspomagał w robieniu markupu. Taki podział był o tyle dobry, że na bieżąco konsultowałem z kimś swoją robotę oraz mogłem podejrzeć kod tej drugiej osoby i nauczyć się czegoś nowego.

Czas mijał, a ja już byłem w stanie samodzielnie realizować projekty, zupełnie zajmując się markupem i CMSem, okazjonalnie wskakując do juniorskich projektów. Śmielej podchodziłem do PHPa i WordPressa, a gdy to już miałem w miarę opanowane, szło mi to coraz szybciej i sprawniej, to zacząłem dostawać coraz to bardziej zawiłe projekty.

Po godzinach zacząłem ogarniać rzeczy związane ze środowiskiem – Node, Grunt (ble), Gulp, Webpack, Apache, Xdebug itd. i miałem z tego radochę, ponieważ mając wiedzę o każdej z tych rzeczy, byłem w stanie pomagać innym, którzy mieli z ów środowiskiem problem. A gdy to już przychodziło coraz łatwiej, wskoczyłem w świat Reacta, TypeScripta, Eslinta i Laravela.

Odpowiada Adam Włodarczyk, iOS/Android Developer w Hindbrain w Hindbraind:

Swoją karierę zacząłem po kilku latach pracy jako pracownik działu IT w jednej z firm, która obsługiwała placówki medyczne. Swoją przygodę z programowaniem zacząłem od nauki Javy z Android SDK i od tamtej pory jakoś do mobilków mi bardzo blisko. Później nadszedł czas na rozwój we własnym zakresie, otworzyłem swoją działalność gospodarczą i zacząłem poszukiwania klientów. Od 5 lat działam jako freelancer głównie przy mobilkach, ale w związku z częstą potrzebą pisania RESTFul Api, też nie są mi obce frameworki PHPowe czy Spring.

Dodatkowo od dwóch lat jestem wykładowcą oraz mentorem w Coderslab, co pozwala mi rozwijać umiejętności miękkie. W życiu nie nazwałbym się Seniorem, bo według mnie takim człowiekiem może być osoba, która ma bogate doświadczenie poparte wieloletnią praktyką. Bardzo dobrze widać to na przykładzie Zachodu, gdzie czynnie w branży IT pracują ludzie mający 50-60 lat i posiadający 30-40 lat doświadczenia (to jest senior), a u Nas niestety, ale trochę to pojęcie zostało wypaczone przez fakt, że sam rynek jest stosunkowo młody. Niemniej jednak jeszcze wiele przede mną nauki i zgłębiania różnych technologii.

2. Mamy junior developera, który zna HTML, CSS i podstawy JavaScript. Ile powinien zarabiać w pierwszej pracy i dlaczego tyle?

Odpowiada Krzysztof Hasiński, Senior Software Engineer:

Tyle, ile pracodawca mu zaoferuje. Znam ludzi z takim doświadczeniem otrzymujących powyżej 25 000 PLN oraz takich, którzy dostają ledwie 2 000 PLN.

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:

W Tooploox akurat na front-endowego juniora trzeba pochwalić się dobrą znajomością JavaScript, ale stażyści mogą liczyć na 2 320 zł brutto przez pierwsze 3 miesiące. Dlaczego tyle? Z ekonomicznego punktu widzenia to taka osoba może więcej firmę kosztować niż przynosić wartości, bo trafia pod skrzydła seniora, którego czas będzie kosztować firmę więcej niż to co przeważnie jest wstanie dostarczyć stażysta. Nie przywiązywałbym aż takiej uwagi do tego, ile zarabiasz na samym początku, a jakie masz możliwości rozwoju i awansu. Pakiet benefitów w Tooploox jest bogaty i nastawiony na pomóc w rozwoju, m.in. finansowanie konferencji, kursy online, czas w ramach pracy na naukę i samorozwój. Dynamika wzrostu pensji juniora jest też większa niż seniorów.

Odpowiada Sebastian Gruchacz, Programista .Net / C# od 15 lat:

Tyle żeby mógł się spokojnie utrzymać i chciał zdobywać wiedzę na własną rękę także po pracy. Po wstępnej weryfikacji poziomu “ogarnięcia” powinien trafić w tryby szkoleń i warsztatów (wliczam w to zarówno działania wewnętrzne jak i zewnętrzne), które pozwolą mu się rozwinąć przede wszystkim w tych kierunkach, które są zgodne z jego predyspozycjami i potrzebami firmy – i to powinno być odebrane jako najważniejsza część wynagrodzenia. Dobrze “poprowadzony” świeży programista powinien “zacząć się zwracać” dość szybko.

Odpowiada Paweł Wieczorek, Senior Fullstack Developer w Chop-Chopie:

Na tyle na ile się dogada z pracodawcą, biorąc pod uwagę też średnie widełki dla Junior Web Developerów, co można łatwo sprawdzić na justjoin.it. Nie nastawiajmy się na górną granicę zarobków, jeżeli jest to nasza pierwsza praca. Celujmy gdzieś bliżej początku przedziału, a jeżeli uda nam się wynegocjować więcej, to tym lepiej. Należy sobie uświadomić, że na samym początku Junior będzie generował stratę dla firmy, ze względu na brak doświadczenia oraz angażowanie innych devów w pomoc w jego rozwoju.

Odpowiada Adam Włodarczyk, iOS/Android Developer w Hindbrain:

Powinien zarabiać tyle, ile uda mu się wynegocjować, wszystko zależy od jego umiejętności negocjacyjnych, chwili w jakiej wchodzi na rynek oraz miejsca w jakim firma, do której kandyduje, się znajduje (chodzi mi tu o miasto/państwo). Jeśli ktoś będzie w stanie dać za jego pracę (a raczej dalszą naukę) przykładowo 5 000 PLN netto – to proszę. Jeśli 15 000 PLN netto, super, jeśli 3 000PLN netto też fajnie. Tak, już odpowiadając na pytanie konkretnie, to wydaję mi się, że biorąc pod uwagę Warszawę i umiejętności to 2 500PLN netto to mniej więcej dobra kwota na początek dla takiego juniora.

Oferty pracy z

3. Ma znaczenie to, gdzie się uczył: na studiach, w szkole programowania czy jest samoukiem?

Odpowiada Krzysztof Hasiński, Senior Software Engineer:

Nie. Pamiętam, że lead developer pewnej dużej fińskiej firmy przy ich kluczowym dla nich projekcie był samoukiem, który wiedzę swoją zdobywał… w więzieniu. Ludzie po studiach na pewno mają łatwiej z uwagi na to, że są zmuszeni do obejrzenia pewnych bardziej algorytmicznych problemów. Ale nie widzę problemu, żeby ktoś odpowiednio zmotywowany i zainteresowany tematem taką wiedzę nadgonił. Jedyną znaczącą różnicą mogą być znajomości ze studiów, które zdecydowanie trudniej nadrobić.

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:

I tak, i nie. Tak, bo dobre studia zmuszają do nauki. Nie, bo nie ma “automatycznych” punktów za papierek. Osobiście na rozmowie rekrutacyjnej nie biorę pod uwagę tego jak zdobyłeś swoją wiedzę, interesuje mnie to co wiesz i co pokażesz w procesie rekrutacji.

Odpowiada Sebastian Gruchacz, Programista .Net / C# od 15 lat:

I tak, i nie. Raczej niewielkie są szanse, że samouk wpadł na to by się uczyć teorii programowania, algorytmów czy zagadnień związanych z np. liczeniem złożoności czy O. Z drugiej strony – na uczelni też raczej miał niezbyt wiele okazji by rozwijać się w tym co go pasjonuje. Dodatkowo, w praktyce programistycznej zazwyczaj się okazuje, że tej teoretycznej wiedzy wyniesionej z uczelni niemal nigdy nie będzie potrzebował w “prawdziwych” projektach. Mi samemu w mojej niemal 20 letniej karierze przydały się te kwestie najwyżej kilka razy. Oczywiście są takie ścieżki rozwoju gdzie ta wiedza jest wręcz niezbędna – jak AI, ML czy Big Data, ale to i tak tylko podstawy. Osobiście chwalę sobie tę urozmaiconą (choć powierzchowną) wiedzę wyniesioną ze studium, dzięki czemu nie zamykam się tylko w jednym obszarze.

Odpowiada Paweł Wieczorek, Senior Fullstack Developer w Chop-Chopie:

Nie ma to znaczenia. Każda z tych ścieżek pozostawia po sobie pewne umiejętności i „ułomności”, które potem praca w firmie zweryfikuje. Samouk może nie mieć tak obszernej wiedzy, jak osoba po studiach, ale może deklasować ją większym zaangażowaniem w projekt, a osoba po szkole programowania może mieć bardziej aktualną wiedzę na temat praktyk, czy technologii jakie są wykorzystywane. Ważniejsze od pytania „gdzie?”, będzie „czego się uczył i co na ten temat wie?”, bo koniec końców na rozmowie będziecie pytani z wiedzy i umiejętności (oby), a nie w jaki sposób je nabyliście, chociaż to też może być na tyle ciekawe, że wywiąże się z tego jakiś small talk.

Odpowiada Adam Włodarczyk, iOS/Android Developer w Hindbrain:

Oczywiście, że ma. Przyjmując, że mamy 3 tak samo dobrze wykwalifikowanych programistów tyle, że każdy nauczył się tego fachu w inny sposób, jesteśmy w stanie określić jego pobudki i możliwe nawet, że profil psychologiczny. Przykładowo samouk, prawdopodobne że będzie to osoba dociekliwa, lubiąca badać nieznane rejony, wytrwała w swoich postanowieniach, taki typ geeka od urodzenia. Programista po studiach (nomen omen, ciekawie to brzmi, chciałbym zobaczyć takiego studenta, który nauczył się programować dzięki studiowaniu) będzie osobą dobrze przygotowaną technicznie pod różne technologie, będzie potrafił zastosować techniki rozwiązywania problemów, poznane np. na przedmiocie Algorytmy i Struktury Danych, będzie umiał użyć teorii grafów do optymalizacji logiki biznesowej. Ogólnie dobrze przygotowany merytorycznie programista. Jeśli chodzi o programistę po szkole programowania, można założyć, że taki programista jest nastawiony na szybkie pozyskiwanie wiedzy i ma motywację do nauki. Dodatkowo jest dobrze przygotowany merytorycznie z danej technologii lub frameworka i może być dobrym rzemieślnikiem. Najczęściej ludzie chcący coś zmienić w swoim życiu. Podsumowując, sposób i miejsce nauki ma bardzo duże znaczenie.

4. To pytanie zadano już setki razy, ale myślę, że zawsze będzie aktualne. Jak junior powinien przygotować się do pierwszej pracy i ile przeznaczyć czasu na naukę “po pracy”?

Odpowiada Krzysztof Hasiński, Senior Software Engineer:

Junior powinien interesować się programowaniem. Rozwiązywać swoje własne problemy używając kodu. Nie wiesz jak się uczyć? Pomyśl jakiej aplikacji Ci brakuje i napisz chociaż mały jej zaczątek. Nauczysz się kilka razy więcej niż przerabiając kursy i tutoriale.

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:

Wszystko zależy od tego jak szybko chce się tę pracę znaleźć. Był czas, w którym przychodziłem do domu i pisałam kodzik do momentu, w którym nie obudziłem się na klawiaturze. Trzeba było wtedy usunąć wszystkie znaki wprowadzone czołem, umyć zęby, pójść spać i tak w kółko. Tę technikę polecam tylko najbardziej zdeterminowanym. Postawiłbym sobie konkretny cel i dążył do niego w miarę swoich możliwości. Zacznij od freeCodeCamp, wrzuć kod na GitHub, rozwiąż pare zadanek na HackerRank, napisz prostą aplikację, opublikuj ją na Heroku i będziesz lepszy od większości innych kandydatów.

Odpowiada Sebastian Gruchacz, Programista .Net / C# od 15 lat:

To głównie kwestia tego czy “junior” jest juniorem według metryczki czy według stażu. Ja zacząłem naukę dość wcześnie, łączyłem ją ze studiami i pracą. Nie mając na głowie rodziny mogłem poświęcić mojej pasji bardzo dużo czasu, bawiąc się i eksperymentując. Aktualnie wybór jest bardzo ograniczony: albo rozrywka, albo nauka. Albo rodzina, albo kodowanie. Albo obowiązki domowe, albo github. A i organizm regularnie pozbawiony wystarczającej ilości snu już nie daje rady na dłuższą metę jak za czasów młodości. Ponieważ według mnie jedna godzina to zbyt mało by poczynić sensowne postępy – ja sobie przeplatam rozrywki z nauką: Jednego dnia sięgam do Netflixa, a innego koduję. Ciekawym pomysłem jest też nauka programowania dzieci – dzięki temu muszę sobie wszystko samemu sensownie poukładać i postarać się ogarnąć z perspektywy “bardzo juniora”, a i czas z rodziną jest zaliczony.

Odpowiada Paweł Wieczorek, Senior Fullstack Developer w Chop-Chopie:

Warto do tego wszystkiego mieć „dziecięcą ciekawość”, tak by pojawiające się pytania – „co” „dlaczego”, „że co?!” – podczas czytania kodu były motywujące, a nie odpychające, wtedy ten czas spędzony „po pracy” będzie o wiele przyjemniejszy. A ile przeznaczyć na to czasu? Trudno jednoznacznie stwierdzić, ale na pewno tyle ile się chce, ale nie więcej niż trzeba. Dla jednych to będzie zarywanie nocy, aż świadomość nie skaże ich na sen, a dla drugich będzie to szybkie przejrzenie tematycznych postów na Reddicie w trakcie innych czynności.

Przed pierwszą pracą warto ogarnąć sobie jakiś mały projekt (albo duży, o ile macie siły) i go opublikować na GitHubie czy GitLabie – takie projekty nabiją Wam punktów przy przeglądaniu CV przez rekrutera, bo kod powie o Was o wiele więcej, niż długa ścieżka edukacyjna. Nie ważne, czy ten projekt to nieudany pomysł na najlepszą appkę świata, czy zrobiona po Waszemu kopia jakiegoś serwisu. I pamiętajcie, by dużo commitować podczas pracy nad takim projektem – jednocommitowce są podejrzane i nie mówią nic o Waszych postępach.

Odpowiada Adam Włodarczyk, iOS/Android Developer w Hindbrain:

Jeśli naprawdę marzy mu się zmiana pracy, chęć spróbowania sił w nowym środowisku, to myślę że taka osoba powinna poświęcić tyle czasu, ile tylko może i ma żeby cel osiągnąć jak najszybciej (bo chyba o to tu chodzi). Wiadomo, ludzie mają różną sytuację rodzinną i finansową, chodzą do różnych miejsc pracy, mają rodzinę i dzieci (lub też nie), no i te zmienne będą determinowały kto, ile czasu może poświęcić na naukę. Tak naprawdę chodzi o to, żeby zacząć i sukcesywnie się rozwijać, rozumieć, wyciągać wnioski z popełnionych błędów.

5. Co musi zrobić, żeby dostać podwyżkę i jak szybko, opierając się na Waszym doświadczeniu, zazwyczaj junior podnosi swoje umiejętności?

Odpowiada Krzysztof Hasiński, Senior Software Engineer:

Pokazać swoją wartość, zarówno aktualną (przez przydatne umiejętności), jak i potencjalnie przyszłą (przez szybkie przyswajanie nowej wiedzy).

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:

W Tooploox dużo zależy od rekomendacji twojego zespołu po 3 miesięcznym okresie próbnym. Ludzie są różni i do każdego staramy się podejść indywidualnie. Jeżeli okaże się, że jesteś samodzielny to zwykle twoja pensja oscyluje w przedziale 4 000zł do 6 500zł brutto.

Odpowiada Sebastian Gruchacz, Programista .Net / C# od 15 lat:

Brutalna prawda jest taka – zmienić pracę. Zazwyczaj możliwości uzyskania większych podwyżek w ramach aktualnej pracy są minimalne. A w momencie gdy widziałem na rynku oferty pracy dla programistów z 2-letnim doświadczeniem w okolicy 8K nie wyobrażam sobie, by junior w ciągu dwóch lat pierwszej pracy osiągnął taki poziom zarobków startując od pułapu tych 3K.

Widziałem firmy, które nie miały pomysłu na rozwój juniorów i ci ucząc się wyłącznie na własną rękę zrezygnowani odchodzili szukając miejsc gdzie mogą się przydać – i zarobić więcej. Oczywiście widziałem też i takie gdzie jest jak trzeba, i tam będzie jak koledzy nadmienili.

Odpowiada Paweł Wieczorek, Senior Fullstack Developer w Chop-Chopie:

Na szybkość podwyżki możemy wyróżnić dwa czynniki.

Po pierwsze pracownik. Widziałem osoby, który uczyły się szybko i sprawnie rozwiązywały stawiane przed nimi problemy, ale widziałem też takie, którym szło to wolniej i nerwowo reagowali na każdy napotkany problem. Takie postawy, jak nietrudno się domyślić, miały wpływ na szybkość awansów czy podwyżek.

Po drugie firma. Jeżeli coraz sprawniej rozwiązujemy stawiane przed nami zadania, a mimo to firma zdaje się tego nie dostrzegać, to warto w pierwszej kolejności skonfrontować nasze wrażenia z osobą, która jest odpowiedzialna za awanse (zazwyczaj jest to osoba, która była z nami na rozmowie). Jeżeli mamy wrażenie jakbyśmy odbijali się od ściany, to czas poszukać innej firmy.

Odpowiada Adam Włodarczyk, iOS/Android Developer w Hindbrain:

Musi wykazać się tym, że potrafi być samodzielny, umie użyć szarych komórek i nawet nie znając rozwiązania danego problemu jest w stanie takie rozwiązanie wydedukować/znaleźć i w kolejnych iteracjach. Tak naprawdę najlepiej powinien wiedzieć to mentor juniora, czy jest gotowy by wysłać swojego programistycznego podrostka na głębokie wody kodocenau. Jeśli taki junior już nie będzie zabiegał o pomoc, albo będzie to robił sporadycznie, to czas na podwyżkę i stanie się samodzielnym programistą. Tu też nie ma reguły co do czasu, jeden w 3 miesiące będzie kodował jak stary wyjadacz inny natomiast po 4 latach będzie nadal w tym samym miejscu co na początku. Wszystko zależy od jednostki.

6. Jak stworzyć najlepsze warunki dla rozwoju junior developera?

Odpowiada Krzysztof Hasiński, Senior Software Engineer:

Postawić go przed ciekawym problemem i dać mu kontakt do ludzi, którzy pomogą mu w kluczowych momentach. Dać mu czas na naukę i bardzo szybki feedback. Dać mu pairować z innym juniorem lub midem (z seniorem nie ma sensu, będzie im trudniej o wspólny język, a i stres dla niektórych większy).

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:

Promować atmosferę, w której nie boimy się zadawać pytań. Należy postawić na współpracę, często dawać feedback, organizować sesje pair programmingowe, stawiać na jakość tworzonego kodu, robić code review i nie zapomnieć o tej ludzkiej stronie procesu wytwarzania oprogramowania. Jest to nie tylko dobre dla rozwoju juniorów, ale także każdego pracownika w firmie.

Odpowiada Sebastian Gruchacz, Programista .Net / C# od 15 lat:

Tu będę teoretyzował – nigdy do tej pory nie miałem okazji widzieć tego realizowanego w sposób zaplanowany w organizacji – zarówno od strony juniora jak i seniora / team-leadera. Moje doświadczenie jest takie, że junior jest po prostu wrzucany w jakieś banalne zadania i ma się w nich samemu ogarnąć. A seniorzy tak są zarobieni, że nie mają czasu na regularne przeglądy kodu czy pracę w parach. Pamiętam też czasy gdy nikt nie używał repozytoriów kodu, o procesie code-review nawet nie wspominając. A jako leader współpracowałem już niemal wyłącznie z midami / seniorami, więc też mnie to ominęło.

OK, są jakieś warsztaty czy meetupy czasami w firmach robione, i fajnie, ale to zdecydowanie nie wystarczy. Junior powinien mieć zapewniony dostęp do bardziej doświadczonych kolegów, a ci powinni mieć bufor czasu, który mogą zainwestować w dzielenie się wiedzą bez stresu, że nie wyrobią się ze swoimi zadaniami. Można organizować wewnętrzne panele dyskusyjne i warsztaty, prowadzone przez ludzi z rozmaitych poziomów doświadczenia i na różne tematy – to pozwoli ukierunkować ewentualne dodatkowe studiowanie ciekawych tematów i stworzy atmosferę dzielenia się wiedzą. Oczywiście nawet nie wspominam o tym jak ważny jest proces konstruktywnych przeglądów kodu pisanego przez juniora – nie w postaci mniej lub bardziej złośliwej krytyki ale konkretnych wskazówek, linków a nawet przykładów. Czas do mniej technicznej rozmowy przy ekspresie do kawy też powinien się znaleźć. A i można wówczas na luzie zarzucić jakimś frapującym problemem – są spore szanse, że akurat ktoś od dawna zna odpowiedź…

Odpowiada Paweł Wieczorek, Senior Fullstack Developer w Chop-Chopie:

Zachęcić do zadawania pytań na forum firmy (czy to twarzą w twarz czy przez komunikator firmowy). Pojawią się problemy, które będą zajmować zbyt wiele czasu, a w firmie będzie osoba, która albo się spotkała z podobnym (jak nie tym samym) problemem, albo taka, która będzie chciała się wykazać, co w rezultacie może przynieść świeższe spojrzenie do całej sytuacji.

Odpowiada Adam Włodarczyk, iOS/Android Developer w Hindbrain:

Junior powinien mieć mentora, który to będzie mu przydzielał zadania i to on najlepiej będzie wiedział na jakim etapie rozwoju intelektualnego jest junior i z czym sobie poradzi a z czym nie. Na pewno junior powinien dostawać zadania, które będą zmuszały go do myślenia, poszukiwań, zgłębiania zagadnienia. Smutne jest jeśli dostanie jakieś trywialne zadanie, które polega na klepaniu jak średnio inteligentna małpa. Najlepszym powiedzeniem, które można tu przytoczyć jest to, że nieużywany organ zanika i trzeba dawać juniorowi takie zadania żeby szare komórki musiały wejść na najwyższe obroty.