Jak się odnaleźć w pierwszej pracy jako programista?

W sumie całkiem sporo już się uzbierało na blogu wpisów związanych z początkami kariery programisty. W jednym z nich Marcin Zalewski opisał na czym powinni skupić się kandydaci na front-end developerów jeśli chcą z sukcesem znaleźć pierwszą pracę. Z kolei ja przedstawiłem ostatnio kilka porad dotyczących tego, jak zrobić kolejny krok w swojej karierze. Myślę, że tego typu wpisy są potrzebne. Potwierdzają to zresztą statystyki bloga - wpisy dotykające tego obszaru są jednymi z najczęściej czytanych! Dlatego też dziś, po kilku z rzędu postach technicznych, powracam do tematyki kariery młodego programisty. Niniejszym wpisem postaram się przedstawić na jakie problemy możesz się natknąć oraz jak się odnaleźć w pierwszej pracy jako programista. Mam nadzieję, że będzie to dla Ciebie przydatna lektura!

Zespół

Pamiętam bardzo dobrze swój pierwszy dzień pracy jako Junior Developer. Nie powiem, było to stresujące na maksa… Człowiek w nowym miejscu, otoczony nowymi ludźmi i do tego pod presją aby się wykazać i udowodnić, że pracodawca dokonał dobrego wyboru zatrudniając mnie. Myślę, że jest to jak najbardziej normalna reakcja.

Na szczęście w 98% przypadków zespół programistów to fajna ekipa pozytywnych ludzi, przez którą szybko zostaniesz “wchłonięty”. Dlatego jeśli obawiasz się tego jak zostaniesz przyjęty przez innych, bardziej doświadczonych programistów, to nic się nie martw. Jeśli chodzi o relacje z zespołem to Twój brak doświadczenia nie będzie tutaj grał roli. Postaraj się tylko nie być “mrukiem”, idź z zespołem na obiad/kawę jeśli Cię zaproszą itp. To na pewno ułatwi Ci zrobienie dobrego pierwszego wrażenia.

Niektóre firmy przygotowują dla swoich nowych pracowników małe szkolenia wprowadzające. Wygląda to różnie - czasem jest to tylko takie HR’owe “pitu pitu” na temat “misji i wizji firmy”. Czasem jednak można z takiego spotkania wynieść trochę więcej. Na przykład to, jakie zasady panują w firmie jeśli chodzi o strój czy też jak bardzo elastyczny jest czas pracy w firmie. Myślę, że to też przydatna wiedza pozwalająca łatwiej odnaleźć się w te pierwsze dni pracy.

Narzędzia pracy

Oczywiście nikt Cię nie zatrudnia abyś tylko tworzył dobrą atmosferę w biurze. Twoim głównym zadaniem jest praca programistyczna przy projekcie, do którego zostałeś przydzielony.

Jeśli nigdy wcześniej nie pracowałeś jako Software Developer to możesz zderzyć się ze sporym natłokiem nowych narzędzi do ogarnięcia… Warto więc od samego początku poświęcić dodatkowy czas na przyswojenie ich sobie. A nawet więcej: możesz się do tego przygotować zanim znajdziesz pierwszą pracę, a znajomość tych narzędzi możesz umieścić w swoim CV…

System kontroli wersji

Przykładem narzędzi, które będziesz musiał opanować jest na pewno system kontroli wersji. Jest ich na rynku wiele ale obecnie niepodzielnie króluje Git! Oprócz tego w wielu firmach stosuje się jeszcze SVN, a także Mercurial. Jeśli natomiast zatrudniłeś się jako programista .NET to istnieje też prawdopodobieństwo, że w Twojej firmie wykorzystuje się TFS.

Jak więc widzisz trochę tego jest… Dlatego też moim zdaniem, jeszcze zanim znajdziesz pracę, dowiedz się co to w ogóle jest system kontroli wersji. Następnie zapoznaj się z zasadami pracy z Gitem oraz SVN. Dzięki temu zmniejszysz znacząco stres związany ze swoim pierwszym commitem do repozytorium…

Wiem co mówię: na początku swojej kariery nie miałem nawet bladego pojęcia o istnieniu czegoś takiego jak system kontroli wersji. Kiedy przyszło co do czego, musiałem wołać kogoś ze współpracowników aby w ogóle mi wyjaśnił co to takiego, po co to jest i w ogóle jak to działa, nie wspominając o przeprowadzeniu za rączkę przez cały proces commitowania. A nie daj Boże jeśli będziesz musiał od razu zrobić merge…

IDE/edytor

Kolejnym narzędziem, którego brak znajomości może przysporzyć Ci początkowo problemów jest IDE (skrót od angilelskiego: Integrated Development Environment) lub edytor tekstu, którego używa się w pracy.

Akurat w przypadku pracy jako Front-end Developer mamy często dowolność przy wyborze tego narzędzia. Warto jednak abyś miał już jakieś swoje ulubione, tak aby nie zaprzątać sobie głowy dodatkową nauką. Możesz więc wybrać edytor Atom, Brackets, Sublime Text czy VSCode albo IDE WebStorm (sam używam i polecam) i opanować jego podstawowe funkcje edycyjne czy popularne pluginy. Znajomość przynajmniej jednego z tych narzędzi będzie przydatna również wtedy, gdy okaże się, że w Twojej firmie używa się jakiegoś konkretnego edytora lub IDE. Pewien zakres niezbędnych funkcji dostępny jest bowiem w każdym z nich, łatwo jest się więc przesiąść z jednego na drugi.

Jeśli chodzi o stanowiska inne niż Front-end Developer to często z daną technologią/językiem programowania związane jest jakieś jedno popularne IDE. Dla świata .NET jest to na przykład Visual Studio, a dla Javy IntelliJ IDEA albo Eclipse (chyba, że teraz się czegoś innego używa?). Tutaj również, warto wcześniej poznać podstawowe możliwości tych narzędzi oraz sposób ich użycia.

Debugger

W zależności od tego czym się zajmujesz, debugger może być po prostu częścią IDE/edytora, którego używasz. Tak jest na przykład w przypadku Visual Studio. Jeśli jednak jesteś młodym Front-end Developerem (to blog dla front-endowców więc z dużym prawdopodobieństwem jesteś) to oprócz edytora warto abyś opanował też debugowanie kodu.

W świecie JavaScript robi się to głównie używając narzędzi developerskich Chrome (lub innej przeglądarki ale te od Google są w tej chwili najlepsze). Fajnie więc abyś umiał się nimi posługiwać, zarówno do wyłapywania błędów JavaScript jak do testowania stylów CSS itp.

Praca w projekcie

Skoro jest to Twoja pierwsza praca jak programista to zapewne nigdy wcześniej nie pracowałeś w projekcie realizowanym przez więcej niż jedną osobę. Aby usprawnić tę pracę, projekty takie realizowane są zwykle w oparciu o pewne metodyki. Najbardziej popularną z nich jest obecnie Scrum lub mówiąc bardziej ogólnie Agile. No dobra, jak powiedziałby jeden z moich byłych Scrum Masterów: Scrum to nie metodyka, to podejście… Oprócz tego, najczęściej w korporacjach, spotkać można też metodyki takie jak Waterfall czy PMI.

Scrum

Jest bardzo prawdopodobne, że to właśnie w modelu Scrum/Agile będzie realizowany Twój pierwszy projekt. Jest to obecnie najbardziej rozpowszechnione podejście, które sprawdza się chyba najlepiej. Dlatego też w dzisiejszym wpisie to właśnie na pracy z użyciem tej metodyki się skupię.

Nie będę się tutaj wdawać w szczegóły Scruma. Zamiast tego opowiem Ci raczej na co zwrócić uwagę aby od początku zrobić dobre wrażenie i uniknąć niepotrzebnego stresu.

Stand up

Pracując w Scrumie będziesz codziennie uczestniczyć w spotkaniach zwanych “stand up”, “daily” albo “daily Scrum”. Jest to krótkie spotkanie, na którym każdy z członków zespołu opowiada reszcie czym zajmował się dzień wcześniej, co planuje na dziś oraz jakie ewentualnie ma problemy. Jest to też połączone z aktualizacją “scrum boarda” czyli tablicy, na której wywieszone są wszystkie zadania zespołu.

Na początku takie spotkanie może być dla Ciebie krępujące… Sporo nowych osób, wszyscy się na Ciebie patrzą, a Ty masz coś do nich z sensem powiedzieć. A nie daj Boże jeśli zespół jest międzynarodowy i trzeba się wysłowić po angielsku… Jeśli więc jest to dla Ciebie stresujące to warto sobie przed takim spotkaniem pomyśleć nad czym się pracowało, i wypisać sobie to na kartce. Dzięki temu o niczym nie zapomnisz. Oczywiście nie chodzi o to aby czytać z kartki. Warto jednak sobie zrobić ściągę żeby niczego nie pominąć. Mi ten sposób zawsze pomagał, nawet kiedy nie byłem już Juniorem.

Codzienne “daily” to też dobre miejsce aby zasygnalizować problemy ze swoim zadaniem. Wiem, że czasem ciężko jest się przełamać i pójść do konkretnej osoby po pomoc. W takiej sytuacji możesz na “stand upie” powiedzieć czym się aktualnie zajmujesz oraz dodać, że masz z tym mały problem. Wtedy na pewno ktoś z zespołu zgłosi się na ochotnika aby Ci pomóc.

Planowanie

Innym elementem pracy w podejściu Agile jest planowanie, które odbywa się przed rozpoczęciem każdego “sprintu” (zwanego też iteracją). Sprint to taki ustalony przedział czasu, w trakcie którego zespół ma zadanie dostarczyć jakąś część systemu. Zwykle trwa on od 2 do 3 tygodni.

Podczas planowania przegląda się zadania (“user stories”) przeznaczone na daną iterację, dzieli się je na mniejsze pod-zadanka (“taski”) i estymuje ile każde z nich może zająć czasu. Dla osób z małym doświadczeniem takie estymacje mogą być problematyczne. Dlatego też podczas sesji planowania postaraj się dobrze zrozumieć co w ramach danego “taska” ma zostać wykonane. Nie bój się dopytywać, bierz udział w dyskusji. Następnie wypisz sobie wszystkie kroki, które według Ciebie będzie trzeba podjąć aby wykonać dany task. Kiedy masz już je wypisane, łatwiej będzie Ci oszacować ile może Ci zająć każdy z nich. Potem wszystko pododawaj i masz swoją estymację taska.

Estymowanie to nie jest nic trudnego, i nie należy się tego bać. Nie należy też się stresować, że Twoje estymacje znacznie odbiegają od estymacji bardziej doświadczonych programistów. Jeśli nigdy nie robiłeś jakiegoś zadania to trudno żeby zajęło Ci to tyle samo czasu co innym. Z czasem, kiedy nabierzesz doświadczenia Twoje estymacje będą coraz bardziej “realistyczne”.

Demo

Trzecim stresującym, nie tylko Juniorów, elementem Scruma jest demo dla klienta. Zwykle odbywa się ono na zakończenie iteracji. W jego trakcje przedstawia się co zostało wykonane w ramach danego “sprintu”.

W zależności od tego jaką decyzję podejmie zespół, prezentacji dokonuje jedna wybrana osoba lub każdy pokazuje to co sam wykonał. Prędzej czy później może się więc okazać, że też musisz coś pokazać…

Moja rada tutaj raczej nie będzie niczym odkrywczym. Warto się po prostu do tego dobrze przygotować. Ja zwykle “na sucho” klikam wszystkie ficzery, które wykonałem i wypisuję je sobie na kartce w punktach. Do każdego punktu dopisuję kilka zdań, które mógłbym na ich temat powiedzieć. Na koniec możesz wszystko jeszcze raz “przeklikać” dodając oczywiście od siebie odpowiedni komentarz.

Na co jeszcze zwrócić uwagę?

Powtórzę to co napisałem już w moim wpisie na temat tego, jak zrobić kolejny krok w swojej karierze: nie bój się pytać! Wydaje mi się, że najważniejsze w pierwszej pracy jest właśnie to przełamanie się. Twoje pierwsze zadania będą zapewne stanowić dla Ciebie wyzwanie ale dla Twoich bardziej doświadczonych kolegów mogą być trywialne. Jeśli więc tylko natkniesz się na jakiś problem w swoim zadaniu, zadawaj pytania - jest bardzo prawdopodobne, że ktoś inny będzie od razu znać odpowiedź. Dzięki temu będziesz szybciej “dowozić” swoje zadania i unikniesz wrażenia, że sobie nie radzisz! Oprócz tego łatwiej przyswoisz nową wiedzę - nauka idzie łatwiej kiedy zamiast szukać rozwiązania w Google, ktoś Ci je pokaże na rzeczywistym przykładzie i do tego wytłumaczy swoimi słowami.

Oprócz tego, moim zdaniem warto od początku wyrabiać sobie nawyk nieustannego podnoszenia kwalifikacji. Dlatego też, oprócz pracy 8 godzin dziennie w firmie, rozwijaj się też w domu - czytaj książki, rozpocznij jakiś poboczny projekt, studiuj wzorce projektowe. “Rozkminiaj” po godzinach problemy, z którymi zetknąłeś się w dzień, w pracy. Jeśli ktoś pokazał Ci jak coś zrobić, a Ty nie do końca jeszcze to rozumiesz - spróbuj popracować nad tym w domu! To wszystko pozwoli Ci szybciej wdrożyć się w pracę jako programista.

Jak się odnaleźć w pierwszej pracy - podsumowanie

Jeśli zastanawiałeś się jak się odnaleźć w pierwszej pracy jako programista, to mam nadzieję, że ten wpis chociaż po części będzie dla Ciebie pomocny! Pierwsza praca to zawsze dużo stresu, warto więc być jak najlepiej na to przygotowanym. Dla mnie na przykład byłoby bardzo pomocne, gdyby ktoś przed moją pierwszą pracą powiedział mi, że będę potrzebować znajomości SVN. Oszczędziłoby mi to sporo początkowych nerwów.

Założę się, że tych porad dla Juniorów mogłoby się tutaj znaleźć znacznie więcej. Jeśli więc masz to już za sobą, a chciałbyś coś tutaj dodać to zachęcam do tego! Możliwość komentowania wpisu stoi otworem!