Nasze początki – część 1. Specjalistą stajesz się w zespole – historia Leszka

Jak zostać programistą? Okazuje się, że do tego zawodu prowadzi wiele dróg. Postanowiliśmy przybliżyć Ci kilka z nich na przykładzie naszych pracowników. Zaczynamy od Leszka, który dzisiaj pełni rolę Senior Director of Engineering.

Rozmowę z Leszkiem przeprowadził Patryk, jeden z naszych Team Leaderów odpowiedzialny za cały cykl. Zapraszamy Cię w podróż po technologiach, programistycznych wyzwaniach, a także – do przeszłości branży IT. Oddajemy głos Patrykowi…

Myślę, że każdy z nas, kto ma zajawkę techniczną, pewnego dnia stwierdził: okej, zostaję programistą. Wpadł w wir zagadnień, zagwozdek i wątpliwości – od czego zacząć i kiedy będę gotowy? Wiele godzin przeglądania Internetu, mnóstwo przeczytanych artykułów, ale pytanie „czy dam radę z moimi umiejętnościami”, „czy jestem w odpowiednim wieku”, pozostaje.

Głowa do góry! W tym i w kolejnych artykułach cyklu „Nasze początki” postaramy się przybliżyć historie kilku naszych developerów, ich wyzwania, zwątpienia, a wszystko po to, by pokazać Ci, że tak naprawdę – wystarczy Chcieć. I to „chcieć” przez duże C jest tutaj szczególnie istotne.

Jak zostać zaklinaczem kodu?

W pierwszej części poznasz Leszka, naszego Senior Director of Engineering, który swoją zawodową ścieżkę rozpoczął już w ósmej klasie. Skąd wzięła się u Leszka pasja do programowania i jak wyglądała jego edukacja? Oto, co mi powiedział:

A gdyby tak móc sprawić, żeby komputer zrobił to, czego od niego oczekuję? To pytanie nurtowało mnie już kilka lat, kiedy jako ósmoklasista stwierdziłem, że chcę iść do liceum, do klasy o profilu matematyczno-informatycznym. Nie miałem wtedy jeszcze wprawdzie komputera, ale różne filmy, w których bohaterowie, niczym magowie sprawiają, że maszyny spełniają ich polecenia, skutecznie rozbudzały młodzieńczą wyobraźnię.

Udało się! Przyszedł też i czas na pierwszy komputer. Wciąż pamiętam tę minę rodziców, gdy tego samego dnia, w którym odebraliśmy ów komputer, wieczorem zastali mnie z wszystkimi jego elementami rozłożonymi na biurku, zamiast wpatrującego się w monitor. Jako wieloletni prenumerator magazynu „Chip”, chciałem każdy element obejrzeć i skonfrontować pozyskaną wcześniej wiedzę z rzeczywistością. Moi rodzice niestety mojego optymizmu w tamtym momencie nie podzielili. Na szczęście wszystko udało się złożyć z powrotem w całość, a dowodem sukcesu, był fakt, że po skończonym zabiegu żadna śrubka nie pozostała samotnie na biurku.

Jak się również później okazało, wzmianka o profilu informatycznym w nazwie klasy nie znalazła się tam przez przypadek, a nasz nauczyciel nie zwlekał zbyt długo z wprowadzeniem pierwszego języka programowania, z którym miałem zostać na dłużej, na całe liceum.

Program, User, Begin, End… tak, w tym właśnie momencie dowiedziałem się, że Pascal, to nie tylko jednostka ciśnienia. Sukcesywnie więc przez kolejne semestry za sprawą języka Pascal realizowaliśmy kolejne zadania rozwiązując coraz to bardziej złożone problemy matematyczne i fizyczne. Już przed maturą przyszedł więc czas na pracę końcową, najważniejszą – zaliczenie. Pamiętam jak dziś dane wejściowe: prędkość, masa, biblioteka graficzna, zderzenia sprężyste, bo o tym traktował program. Miało być nie tylko policzone. Miała być również stosowna animacja z zachowaniem proporcji wszelkich jednostek. Cóż to było wtedy za osiągnięcie, jaka duma… a przecież to był dopiero początek długiej i wyboistej drogi, której z perspektywy czasu nie byłem sobie w stanie jeszcze wyobrazić. Typowy efekt Dunninga-Krugera. Matura? Po takim przygotowaniu poszło jak z płatka. Inżynieria Komputerowa na uniwersytecie czekała z otwartymi drzwiami.

Skomplikowana droga programisty

Pytając Leszka o jego historię, kompletnie nie wiedziałem, na co się piszę. To, co dostałem, to idealny obraz tego, do czego doprowadzić może upór i masa chęci. A zaczął od C++.

C++ czyli rozwinięcie ANSI C zrobił w mojej głowie chyba największe spustoszenie. To była kontynuacja drogi, o której wspominałem wcześniej, drogi, w której nie wiedziałem, że za rogiem czeka programowanie obiektowe. Porzucenie tak bardzo utrwalonego do tej pory myślenia strukturalnego, na rzecz obiektowości, polimorfizmu i dziedziczenia, było chyba najtrudniejszym co spotkało mnie w świecie programowania. 

Kiedy jednak pokonałem ten odcinek specjalny czułem się niczym Neo w Matrixie. Nie widziałem już liter i liczb, lecz obiekty i modele danych. To było niesamowite. Jeszcze jedną wartość, którą niosło za sobą korzystanie z C++, był ogromny szacunek do zasobów. Tam nie było Garbage Collectora i funkcjonalności wybaczających programiście jego rozrzutność, czy też ukrywających pewne implementacje. Większość rzeczy trzeba było zrobić ręcznie. Z perspektywy języka wysokiego poziomu jest to uciążliwe, niemniej pozwala doskonale zrozumieć zachowanie się komponentów systemu i płynące z tego korzyści, jak również konsekwencje.

Jak łatwo można się domyślić, to nie koniec historii. Kontynuować ją będzie Java oraz SQL:

Java była kolejnym krokiem milowym. Krokiem, który wprowadził łatwy do zaprojektowania interfejs użytkownika, pozwolił na jeszcze więcej zabaw z obiektami. Oto pojawił się język, w którym programowanie potrafiło sprawiać frajdę. Wykorzystanie wielowątkowości, użycie grafiki 2D w aplikacjach, możliwość debugowania. Wszystko to razem pozwoliło wejść na zupełnie nowy poziom. To był moment, w którym utwierdziłem się w przekonaniu, że właśnie to chcę w życiu robić. Przecież połączenie pracy zawodowej z zabawą kodem, która sprawia tyle radości, to recepta na sukces. Czyż nie? Od tej pory wszelkie projekty, na studiach starałem się realizować właśnie w tym języku, jeżeli tylko była taka możliwość. Ostatnim zrealizowanym w ten sposób projektem była, a jakże, praca magisterska. Mógłbym w tym momencie rzec, że moje myślenie w tym czasie oparte było o „Thinking in JAVA” Bruce’a Eckela.

Czymże jednak są algorytmy, czy najlepsze techniki programowania, kiedy nie mamy odpowiednich danych do manipulowania nimi? A najlepiej danych w dużej ilości. Człowiek znów się zastanawiał: przecież jestem wytrawnym programistą obiektowym, po cóż mi więc te archaizmy bazodanowe?! Błąd! Im szybciej jako programista zrozumiesz zależność pomiędzy danymi i kodem, tym lepiej dla Ciebie. Kilkadziesiąt pozycji z pewnością możesz przechować w byle pliku, jednak możliwość skutecznego przechowywania milionów rekordów, budowania relacji między nimi, czy też efektywnego tych danych przeszukiwania to kolejny poziom, lub też… kolejny zakręt na drodze, którą pokonujesz. Modelowanie świata czy problemów, z którymi będziesz się mierzył, w dużej mierze zaczynać się będzie właśnie od danych, a kończyć właśnie w kodzie Twojego programu.

Słucham Leszka i myślę sobie: no dobra, backend, backend… Czyli pewnie nigdy nie robił frontu… Okazało się, że niezupełnie:

PHP, MySQL, HTML i CSS, czyli jestem programistą, więc chcę mieć swoją stronę internetową. Bo chociaż, przynajmniej w moim przypadku, tych zagadnień zbyt wiele na studiach nie było, to postanowiłem, że swoją pierwszą stronę internetową popełnię w modelu learning by doing. To było coś zupełnie innego niż do tej pory. Znów zafascynowanie, nieprzespane noce, mnóstwo zupełnie niepotrzebnych na stronie funkcjonalności tylko po to, aby je zakodować i zobaczyć w działaniu. Coś niesamowitego. Pierwszy raz w historii mój kod był oglądany nie tylko przez kolegę z grupy czy wykładowcę. Mogłem podać w opisie GaduGadu adres mojej strony i każdy mój znajomy mógł na nią wejść i zobaczyć efekt mojej pracy. Wprawdzie tylko ja wiedziałem w tamtym momencie (a właściwie to dowiedziałem się później), że spaghetti code nie jest najlepszym rozwiązaniem, niemniej czas na stosowne frameworki webowe przyszedł odpowiednio później.

W ten oto sposób intensywny i radosny okres studiów dobiegł końca. Odbierając dyplom magistra inżyniera znów czułem się dokładnie tak, jak na koniec szkoły średniej i chociaż bardziej doświadczony, to znów złapałem się w pułapkę efektu, o którym pisałem wcześniej.

Gdybym miał wskazać jedną rzecz, którą uważam za ważną z okresu studiów, to z pewnością będą to słowa, które usłyszałem niegdyś podczas zajęć: „Studia nie są po to, aby was wszystkiego nauczyć. Są od wskazania kierunku, a kompleksową wiedzę pozyskać musicie sami”. I chociaż początkowo słowa te wydawały mi się absurdalne, z perspektywy czasu ich wartość jest nieoceniona. Wszakże ta ogromna ilość czasu na rozwiązanie zadań stawianych sobie, tylko po to, aby nauczyć się kolejnych elementów różnych technologii, znacząco ułatwiła mi dalsze kroki w tym nieustannie zmieniającym się świecie.

AUCTANE

Na koniec mojej rozmowy z Leszkiem zostawiłem… koniec, czyli ten najbardziej aktualny etap w jego pracy – AUCTANE oraz wspomniany język programowania:

Przyszedł więc czas na pierwszą po studiach pracę. „Umiesz w JAVA? To doskonale, będziesz pisał w C#!”. Tak właśnie rozpoczęła się kolejna i chyba najdłuższa w moim życiu przygoda z jednym językiem programowania. Po początkowych wyzwaniach związanych z pewnymi różnicami pomiędzy JAVA a C# okazało się, że nie taki diabeł straszny jak go malują. Oczywiście zderzenie aktualnie posiadanej wiedzy z poziomem kolegów programistów pracujących już jakiś czas w fachu tylko zachęciło do dalszego drążenia i poznawania obszarów dotąd nieznanych.

Człowiek może spędzać mnóstwo czasu ucząc się samodzielnie, ale dopiero środowisko ambitnych ludzi, którzy chcą się dzielić swoją wiedzą i otwarcie dyskutować o problemach, z którymi się mierzą pozwala naprawdę dokładnie poznać różne technologie wraz z mnogością aspektów, które ich dotyczą. To właśnie wtedy stajemy się specjalistami, którzy doskonale wiedzą i rozumieją o czym mówią, a wcześniej pozyskana, ugruntowana wiedza pozwala im rozumieć mechanizmy działające pod przysłowiową maską. A gdy dodatkowo trafi się, że każdy w zespole ma nieco inny obszar technologii, który jest jego konikiem, ilość bezcennej wiedzy, którą możemy w ten sposób pozyskać, ulega zwielokrotnieniu. Tak właśnie wyglądało to w zespołach, w których na przestrzeni lat przyszło mi pracować. Wzajemne motywowanie się, omawianie problemów, różne podejścia do ich rozwiązania, niejednokrotnie zakończone porażką. Należy przy tym pamiętać, że porażek nie należy się bać. Należy z nich wyciągnąć wnioski i iść dalej. Wszak błędów nie robi tylko ten, co nic nie robi.

Kolejne etap rozwoju to wzorce projektowe. Genialny zestaw zagadnień, który, w mojej ocenie, każdy programista znać powinien, ponieważ nie tylko ułatwia pracę z kodem, ale również znacznie ją w dłuższej perspektywie przyspiesza, o utrzymaniu kodu nie wspominając. A najciekawsze w tym wszystkim jest to, że programista, kiedy jeszcze wzorców nie zna, ale jest wystarczająco leniwy, stosuje wzorce mimo woli, nie mając o tym świadomości. Tak! Uważam, że leniwy programista to dobry programista, ponieważ zawsze myśli jak potrzebną rzecz zrobić tak, by móc ją wykorzystać gdzie indziej.

Decydując się, aby pracować rozwijając oprogramowanie, ze spokojem możesz spoglądać w przyszłość, ponieważ miejsca na nudę raczej nie będzie. W tej branży nieustannie idziesz do przodu i nieustannie uczysz się nowych technologii, frameworków i pojęć. Zawsze za zakrętem jest obszar, którego nie znasz, a który warto zagłębić poszerzając swoje horyzonty. Pamiętaj przy tym, aby nie ograniczać się tylko do pracy nad kompetencjami twardymi. One są kluczowe, ale bez odpowiedniego podejścia do zespołu, którego częścią zostaniesz, bez umiejętności pracy w grupie, bez umiejętności tłumaczenia, ale też słuchania, każda praca przerodzi się w szereg nieprzyjemnych doznań.

Kompetencje miękkie to to, co sprawia, że innym ludziom dobrze się z nami pracuje. W ten właśnie sposób, kiedy jest taka konieczność, dużo łatwiej rozładować jest napięcie, a stres przekuć w chęć do działania. Zespół, który posiada odpowiedni przekrój fachowców o odpowiedniej kulturze to najbardziej efektywna i kreatywna część każdej firmy. Ja obecnie z perspektywy swojej, trochę innej już roli przykładam do tego ogromną wagę. Doświadczenie wielokrotnie pokazało, że ludzie mniej doświadczeni, ale skorzy do współpracy, otwarci na naukę, ale też wzajemną, konstruktywną krytykę, dużo szybciej w swoich zespołach realizowali powierzone im zadania ucząc się przy tym w zdwojonym tempie. To jest coś co działa jak katalizator i zawsze warto o tym pamiętać. Warto poświęcić też chwilę refleksji na to, jak organizujesz sobie pracę, aby nie wpaść w pułapkę dnia, w którym nieustannie zmieniasz kontekst, na koniec którego ciało myśli tylko o tym, by oddać się w objęcia Morfeusza, a tak naprawdę dochodzisz do wniosku, że nic nie udało Ci się zrobić. „Mistrz czystego kodu” Roberta C. Martina, czy „15 tajemnic zarządzania czasem” Kevina Kruse to pozycje idealne na start, które w sposób lekki dostarczą Tobie niezbędnych podstaw.

Jeżeli więc masz pociąg do nowych technologii, lubisz się uczyć i nie przeraża Cię myśl, że część wieczorów spędzisz przy ekranie z debuggerem, nie Netflixem, to zapraszam. Nie obiecam, że będzie łatwo, ale z pewnością będzie ciekawie. Jestem przy tym pewien, że po pewnym czasie spojrzysz na swoje doświadczenie przez ramię stwierdzając, że było warto.

The end?

Huh… Trzeba przyznać, że Leszek potrafi opowiadać o swoich przygodach. Magnum opus technicznych ciekawostek i przydatnych wskazówek.

W kolejnej odsłonie cyklu „Nasze początki” przybliżymy obraz drogi do programisty z perspektywy Pawła, Director, Software Development. A tymczasem nie pozostaje nic innego, jak powiedzieć: klawiatura w dłoń i przed siebie!