Od Juniora do Seniora. Odpowiadamy na pytania społeczności cz.3

To już trzecia odsłona pytań od społeczności, na które odpowiedzieli zaproszeni przez nas seniorzy. Młodsi koledzy zadali pytania z zakresu budowania ścieżki kariery, ale i przydatności studiów informatycznych. Jak na te pytania odpowiedzieli seniorzy?

Odpowiedzi na pytania udzielili:

• Radosław Madecki. Architekt / R&D w Clearcode. Swoją pasję do z IT odkrył w czasach wczesnoszkolnych. Pierwsze kroki w zawodzie stawiał jeszcze w gimnazjum, pisząc do internetowych redakcji związanych z jego hobby. Dziś specjalizuje się we frontendzie. Dzieli się także swoją wiedzą tworząc serię kursów wideo dla wydawnictwa Helion oraz będąc lead mentorem w szkole programowania Future Collars. Jego hobby to sport, nauka oraz dietetyka.
• Przemysław Rogowski. Senior Scala Developer w firmie Adevinta. Ukończył magistra matematyki na uniwersytecie im. Adama Mickiewicza w Poznaniu. Pasjonat programowania z wieloletnim doświadczeniem przy pracy nad międzynarodowymi projektami. Od pięciu lat mieszka w słonecznej Barcelonie. Miłośnik fantastyki i gier fabularnych. Stara się nie brać życia zbyt poważnie.
• Marcin Skrzypek. Lider techniczny w BGK. Ekspert IT z kilkunastoletnim doświadczeniem w wielu rolach (programista, lider techniczny, architekt, manager) zdobywanym w pracy dla dużych korporacji. Swoje doświadczenie zdobywał m.in. w branży: ubezpieczeniowej, medycznej i bankowości. Głównie zajmuje się programowaniem i projektowaniem architektury systemów korporacyjnych oraz zarządzaniem zespołami developerskimi.
• Paweł Łabuś. Senior Software Developer w Falkbuilt Ltd. Od najmłodszych pasjonował się komputerami, pierwsze proste strony internetowe tworzył w wieku kilkunastu lat. Od niecałego roku mieszkaniec Gdyni i zwolennik pracy zdalnej, która ułatwia mu podróże po świecie. Nieustannie stara się rozwijać i lubi rozmawiać o frontendzie.
• Łukasz Szczygiełek. Staff Software Engineer w HID Global. Inżynier oprogramowania specjalizujący się między innymi w takich technologiach jak C#, WPF, REST API, C++. Posiada wiedzę i umiejętności, które pozwalają mu projektować, programować i testować rozwiązania w ramach metodyki Scrum. Posiada doświadczenie z pracą z systemami, które były rozwijane latami i wymagały refaktoryzacji oraz migracji do nowszych technologii.

13. Czy kierujesz się w pracy czymś takim jak etyka zawodowa programisty?

Radosław Madecki, Architekt / R&D w Clearcode:

Dla każdego etyka będzie znaczyła coś innego, bo możemy wywodzić się z różnych kultur, byliśmy inaczej wychowywani. Firmy same w sobie też mają różny etos pracy. Osobiście przykładam dość dużą wagę do uczciwego traktowania ludzi podczas robienia biznesu, wierzę, że to owocuje umacnianiem współpracy, wzajemnym zaufaniem. Ewentualne opóźnienia zgłaszam odpowiednio wcześniej, nie ukrywam swoich błędów. Każdą wolną chwilę w ramach pracy staram się poświęcać na self development, który przysłuży się firmie, angażuję się w wewnętrzne inicjatywy. Na pewno nie pracowałbym dla firmy, której działania są według mnie niemoralne, wykorzystują czyjąś naiwność, zakrawają o oszustwo. Nie ważne jakie wynagrodzenie by mi oferowano, nie zrekompensowałoby ono poczucia czynienia zła.

Przemysław Rogowski, Senior Scala Developer w firmie Adevinta:

Tak, zdecydowanie. W dzisiejszych czasach, kiedy to technologia ma coraz większy wpływ na nasze życie będzie to coraz ważniejsze. Rozważmy hipotetyczną sytuację, gdzie na skutek jakiegoś błędu w kodzie dochodzi do tragedii. Może być to problem z autonomicznym samochodem, wybuch urządzenia z powodu przegrzania, strata oszczędności na koncie bankowym czy wadliwa integracja aplikacji z inteligentnym domem. Przykładów będzie przybywać z każdym rokiem. Jak w obliczu takiej sytuacji mogą brzmieć zdania, które często się słyszy, takie jak: “mój manager mi kazał”, “nie chciałem pisać testów”, “spieszyło mi się” czy “chciałem zamknąć zadanie przed końcem sprintu”.

Jako programiści, czyli grupa zawodowa z coraz większym wpływem na otaczający nas świat, powinniśmy z większą świadomością podchodzić do tego, jak produkujemy kod oraz po co. Jako ćwiczenie polecałbym tutaj uświadomienie sobie, że można naszemu przełożonemu zawsze powiedzieć NIE, jeśli uważamy, że efekt naszej pracy nie byłby zgodny z naszymi zasadami moralnymi.

Inny temat to uczestniczenie w produkcji software, który ma na celu żerowanie na słabościach, oszukanie czy zranienie innych osób. Wszelkim tego typu projektom zawsze odmawiam. Nawet jeśli wydają się legalne z punktu widzenia prawa. Na przykład, hazard czy mikropłatności w aplikacjach dla dzieci.

14. Jaka jest Twoja recepta na dobre code review?

Marcin Skrzypek, Tech Lead w BGK:

Moim zdaniem, przede wszystkim należy pamiętać po co robimy Code Review. Z jednej strony sprawdzamy czy kod:

• jest zgodny z obranymi przez nas, w danym projekcie wytycznymi (guidelines), tzn. czy spełnia zasady, jak np. konwencje nazewnicze zmiennych, zgodność z obraną architekturą, strukturą samego projektu, obranym kierunkiem rozwoju, itp.
• spełnia fundamentalne zasady dobrego kodu ( SOLID, KISS, DRY, YAGNI, etc. ) czyli np.
  – jest prosty i będzie zrozumiały dla czytającego, w tym dla programistów, którzy kiedyś dołączą do naszego zespołu,
  – czy kod nie jest powtarzany,
  – czy nie jest przerostem formy nad treścią,
  – czy spełnia obrane normy bezpieczeństwa.

Z drugiej strony: każdy może mieć gorszy dzień, być zmęczony danym tematem i popełnić, czasem nawet oczywisty błąd. I nie ma w tym nic złego – code review ma nas zabezpieczyć przed tego typu błędami, poprzez sprawdzenia naszego kodu przez inną osobę. Dlatego uważam, że każdy w zespole powinien móc swobodnie zgłosić swoje uwagi, każdemu, nawet, formalnie „wyższemu stanowiskiem” inżynierowi.

Ważne, by sam proces code review nie był zapalnikiem, psującym relacje w zespole, poprzez nadmierną krytykę. Każdą swoją uwagę, należy umieć uzasadnić i skonfrontować (merytorycznie) z podejściem autora. Z doświadczenia mogę też powiedzieć, że łatwiej jest przeglądać mniejsze changesety, w myśl zasady, że mniejszy commit, to krótsze review i mniej potencjalnych błędów, jak również lepsza kontrola postępu pracy.

Sam proces sprawdzania kodu, powinien odbywać się w skupieniu, nie w pośpiechu (np. zaraz przed releasem).

Paweł Łabuś, Senior Software Developer w Falkbuilt Ltd:

Jeżeli jesteś w firmie nowym programistą, warto zapytać kolegów/koleżanki z zespołu o standard Code Review w projekcie. Z reguły dobrą praktyką jest tworzenie częstych, niewielkich zmian dotyczących jednej konkretnej rzeczy (np. błędu, funkcjonalności). Celem Code Review jest zwiększanie ogólnej jakości kodu w repozytorium, ale nie powinno sprawić, że tworzenie jakichkolwiek zmian jest trudne.

Najważniejszy jest zdrowy rozsądek i skupienie się na rzeczach ważnych (prostota rozwiązania, unikanie powtórzeń, zgodność z pozostałymi komponentami i architekturą aplikacji, testy, nazewnictwo). W przypadku formatu kodu, powinniśmy odnosić się do Style Guide’a przyjętego przez zespół lub dodawać nowy kod, tak aby był zgodny z istniejącymi regułami.

Zdarza się, że Code Review jest przyczyną konfliktów w zespole, dlatego powinniśmy do nich podchodzić bardzo ostrożnie, szczególnie w stosunku do nowych osób w zespole. Komentarze należy pisać jasno, rzeczowo i kulturalnie.
Niejasności najlepiej wyjaśniać osobiście, świetnym sposobem na naukę dla niedoświadczonego programisty jest również pair-programming z Senior Developerem, który właśnie zostawił Wam 20 komentarzy. Można się wiele nauczyć!

Radosław Madecki, Architekt / R&D w Clearcode:

Panowie wyżej rozpisali się na tyle obszernie, że nie ma sensu powtarzać tego samego. Mogę tylko powiedzieć, że się z tym zgadzam i dać dobrą radę początkującym – cierpliwości. Czytaj kod powoli, nie “przelatuj” przez niego oczami. Jak czegoś nie rozumiesz – sprawdź. Nie bój się też zwrócić uwagi seniorowi, wszyscy popełniamy błędy!

15. Jak znaleźć “dobrego” mentora?

Marcin Skrzypek, Tech Lead w BGK:

Nie ma na to chyba uniwersalnej recepty. Jeśli natomiast miałbym coś doradzić to na pewno nie ograniczanie się do czerpania wiedzy od jednej osoby oraz nie nastawianie się, że ktoś będzie nas prowadził indywidualnie.

Super, jeśli trafimy w swojej pracy na kogoś doświadczonego, kto chętnie podzieli się wiedzą, uzasadni każdą swoją uwagę, podpowie dobre praktyki. Dla mnie to właśnie są cechy charakteryzujące dobrego mentora. Jednak nie zawsze jest tak wygodnie. Możliwe rozwiązania powinniśmy podpatrywać od różnych, bardziej doświadczonych osób, zarówno tych, z którymi pracujemy, których możemy na żywo zapytać o niejasne dla nas rzeczy, jak również od osób uznanych w świecie IT, udzielających się w szeroko rozumianym internecie.

Paweł Łabuś, Senior Software Developer w Falkbuilt Ltd:

Najłatwiej znaleźć dobrego mentora w pracy. Nauka od bardziej doświadczonych członków zespołu jest bezcenna, dlatego warto budować z nimi silne relacje. Warto prosić o dokładne Code Review, pair programming, zadawać pytania o ich źródła wiedzy (książki, newslettery, blogi, kanały na Youtube).

Szukać mentora możesz również poprzez uczestniczenie w meetup’ach, czy śledzenie kanałów na Discordzie. W społecznościach, które gromadzą pasjonatów nie trudno będzie Ci znaleźć odpowiedź na Twoje pytania lub chętnych do przejrzenia i ocenienia Twojego kodu.

Radosław Madecki, Architekt / R&D w Clearcode:

Patrząc po obecnym rynku nauczania w Polsce, nie jest jeszcze na tyle dobrze żeby móc przebierać w mentorach. Brakuje specjalistów do kodzenia, a jak tu jeszcze znaleźć kogoś kto lubi i potrafi uczyć. Nawet jak jakichś znajdziemy, to większość z nich ma pełne obłożenie. Wielu moich kursantów skarży się na to, że poza bootcampem, ciężko znaleźć indywidualne wsparcie. Nie ma na to złotej recepty.

Jakbym miał dać jedną radę, to polecam zaangażować się w open source – tam spotykają się ludzie, którzy lubią robić coś dla idei i dzielić się wiedzą. Najlepsze darmowe źródło mentoringu, w mojej opinii.

Oferty pracy z

Przemysław Rogowski, Senior Scala Developer w firmie Adevinta:

Nie wiem czy to kwestia tego, co niesie za sobą słowo “mentor”, ale osobiście bym odradzał szukanie kogokolwiek, kto miałby pełnić dla nas taką funkcję. Zamiast mentora polecałbym skupić się na szukaniu u ludzi innej perspektywy dla problemu, z którym się mierzymy. Przy czym można by zaaplikować tą regułę dla innych aspektów naszego życia, nie tylko pracy jako programista.

To co sprawia, że nasze rozumienie zawodu programisty się rozszerza, to właśnie inna perspektywa. Może to być inny sposób nazewnictwa zmiennych i metod, inny sposób pisania testów jednostkowych czy zastosowanie innego paradygmatu do naszego kodu. Po skonfrontowaniu nowej perspektywy z naszą własną możemy z czasem dojść do tego, które podejście wolimy i uważamy za bardziej wartościowe.

Inną perspektywę możemy znaleźć u kolegów z pracy, na blogach, w książkach, przy wideach instruktażowych, w nauce nowych technologii. Z mojego doświadczenia bardzo owocna była nauka nowych języków programowania, wraz z ich specyficznym podejściem, np. silnie typowana obiektowa java, dynamiczny javascript czy funkcjonalna scala. Zmiana sposobu myślenia przy pisaniu kodu pozwala ci dokonać głębokiej ewaluacji twoich wcześniejszych sposobów programowania.

16. Jak bardzo wiedza ze studiów informatycznych przydaje się w codziennej pracy? Ponieważ czuję, że jako osoba, która nie ukończyła studiów informatycznych brakuje mi podstawowej wiedzy z zakresu algorytmiki, struktur danych czy architektury oprogramowania, którą chciałbym nadrobić.

Marcin Skrzypek, Tech Lead w BGK:

Uważam, że studia są jedynie bazą do jakiegoś startu. Mogą jedynie pomóc, dać jakiś ogólny obraz danego obszaru, ale nie są absolutnie żadnym wymaganiem czy wyznacznikiem bycia dobrym programistą. Znam ludzi, którzy nie ukończyli żadnych studiów, a byli świetnymi programistami.

Algorytmów, struktur danych czy nawet architektury najlepiej nauczymy się rozwiązując realne problemy, szukając rozwiązań w różnego rodzaju materiałach, jak również patrząc na obecne rozwiązania w firmie, w której zaczniemy pracować. To w ten sposób właśnie zdobywamy tak cenne doświadczenie.

Osobiście nie ma dla mnie znaczenia wykształcenie kandydata. a po prostu kompetencje jakie posiada, jego chęć do dalszej nauki i to jaką jest osobą, w kontekście dopasowania do reszty zespołu czy atmosfery panującej w firmie.

Łukasz Szczygiełek, Staff Software Engineer w HID Global:

Studia dają podstawy do dalszej nauki. Ułatwia to na pewno rozwój, ale wątpię, aby uzupełnienie brakującej wiedzy w pewnych obszarach z powodu braku studiów wymagało kursów czy studiów podyplomowych – zwłaszcza, jeśli jesteśmy na etapie bycia juniorem. Książki są dobrym źródłem wiedzy z zakresu struktur danych, wzorców projektowych, algorytmów czy architektury oprogramowania. Praktyka ułatwia zrozumienie i usystematyzowanie wiedzy, a to dzieje się podczas codziennej pracy.

Ocena kandydata to przede wszystkim rozmowa rekrutacyjna. Żaden dyplom i kurs nie zastąpi komunikatywności, umiejętności rozwiązywania problemów, szacunku do innych i chęci do nauki.

17. Jak wygląda wprowadzenie juniora (pierwsza praca w zawodzie) w dużych firmach? Dostaje jakieś mniejsze prace do zrobienia, przegląda kod, czym się zajmuje w pierwszych tygodniach?

Marcin Skrzypek, Tech Lead w BGK:

Tutaj nie ma jednoznacznej odpowiedzi, ponieważ w każdej firmie podejście może być inne. Z mojego doświadczenia najczęściej wygląda to tak, że początkowo junior developer dostaje raczej mniejsze, łatwiejsze zadania, które nie mają dużego ograniczenia czasowego lub nie mają krytycznego wpływu na system.

Wykonywana przez niego praca jest oczywiście sprawdzana przez osobę nieco bardziej doświadczoną, która może dzięki temu zgłosić swoje uwagi i udzielić cennych wskazówek.

Jakub Stompor, Senior Frontend Developer w T-Mobile:

Na bazie mojej kariery zawodowej mogę napisać, że wprowadzenie juniora do dużej firmy (korporacji) wygląda tak, że przez pierwsze kilka dni poznaje się firmę, ludzi w niej pracujących, podstawowe systemy do zarządzania własną pracą oraz cel biznesowy projektu w którym się uczestniczy. Pierwsze dni to również wspólne wyjścia na lunch i nawiązywanie relacji z innymi osobami z zespołu, pobranie repozytorium i zapoznanie się z kodem aplikacji.

Jeśli chodzi o samą pracę w sobie to oczywiście dostaje się prostsze zadania, dla których nie ma wyśrubowanych limitów czasowych, lecz w jakiś tam sposób wymaga się aby były one ukończone choć w sposób przyzwoity. Osoby na stanowisku juniora są raczej traktowane łagodnie i bez nacisku.

Więcej o tegorocznej edycji akcji Od Juniora do Seniora dowiecie się z tej strony. Nadal szukamy m.in. chętnych do udziału w bezpłatnych spotkaniach z seniorami.