wróć

Jajko czy kura?

Ogłoszenia o pracę w branży IT mogą wydawać się bardzo dziwne. Czasami wręcz niezrozumiałe. Obok licznych nazw technologii, z których wiele może nam nic nie mówić, często pojawia się też wymaganie posiadania kilku lat doświadczenia.

Czymże jednak jest to doświadczenie? Czy odnosi się ono do tego ile lat korzystamy z danej technologii? A może do tego ile lat używamy danej technologii komercyjnie? No i wreszcie, czy chodzi o każdą z wymienionych technologii czy tylko o dowolną wybraną z nich?

W tym artykule spróbuję przybliżyć nieco jak należy rozumieć “doświadczenie” w kontekście ogłoszeń o pracę branży IT. Mimo iż wielu pracodawców wymaga takiego doświadczenia, nie znaczy to że nie dostaniemy żadnej pracy w branży jeśli wcześniej nie pracowaliśmy w branży. Technologia informacyjna nie lubi problemów nieskończenie rekurencyjnych, możemy więc założyć że istnieje prostsze rozwiązanie.

Prawdę powiedziawszy, doświadczenie w pracy w branży nie odnosi się zwykle tylko do umiejętności technicznych. Technologia zmienia się na tyle szybko, że wielu z popularnych dzisiaj rozwiązań nie było na świecie 5 lat temu, więc szukanie ekspertów z “pięcioletnim doświadczeniem z technologią X” byłoby niewykonalne (co nie znaczy, że nie trafiają się takie ogłoszenia). By lepiej zrozumieć stawiane przed nami wymagania przyjrzyjmy się jak wygląda i na czym polega praca programisty.

Dzień z życia programisty

Wydawać by się mogło że podstawą pracy programisty jest tworzenie kodu. To założenie jest częściowo słuszne. Lepszym byłoby jednak stwierdzenie, iż programiści rozwiązują problemy, tworzą opisy tych rozwiązań (algorytmy) a następnie zapisują je jako kod zrozumiały dla maszyny.

Dlaczego to rozróżnienie jest ważne? Sama umiejętność pisania kodu, czyli znajomość jednego lub więcej języków programowania, nie oznacza że potrafimy samodzielnie rozwiązywać problemy. Podobnie jak znajomość liter nie czyni z nas jeszcze poetów.

Żeby rozwiązywać problemy, programista musi najpierw je poznać. Skąd się biorą problemy i jak możemy je poznać? Zwykle, problemy pochodzą od klienta. Klientem może być firma zewnętrzna, klientem może być nasz szef, klientem mogą być nasze koleżanki i koledzy, a czasami klientem możemy być my sami.

Rozważmy przykład napisania programu który wyświetla wszystkie transakcje na naszej karcie kredytowej z danego dnia. Ten program prezentuje kilka problemów. Musimy ściągnąć listę transakcji z naszego banku. By tego dokonać musimy się najpierw uwierzytelnić. Po ściągnięciu listy musimy rozdzielić odpowiednie rekordy (jak opis, kwota i data), a następnie posegregować je według daty. Gdy tego dokonamy musimy wybrać tylko te rekordy które odpowiadają interesującemu nas dniu, a następnie zaprezentować je użytkownikowi.

Każdy z powyższych problemów może składać się z mniejszych problemów. Wspólnie tworzą one zbiór zadań do wykonania. Te zadania przechowywane są w odpowiednim systemie zarządzania zadaniami. Opiekun projektu w konsultacji z zespołem projektowym przygotowuje zbiór zadań a następnie są one rozdzielane między programistów.

Zanim przystąpimy do pisania kodu musimy więc najpierw nauczyć się korzystać z systemu zarządzania zadaniami, a także wziąć udział w planowaniu zadań (przy czym to ostatnie nie zawsze ma miejsce). Chociaż mogłoby się wydawać że naszym jednym partnerem będzie maszyna, okazuje się że wchodzimy w interakcje także z innymi członkami zespołu projektowego. Praca programisty to zwykle praca zespołowa.

Stworzenie odpowiedniego kawałka kodu nie jest oczywiście końcem pracy. Wręcz przeciwnie, kod który działa na naszym komputerze to tylko początek dłuższego procesu wydawniczego.

Musimy wpierw przetestować czy stworzony przez nas kod rzeczywiście spełnia wymagania opisane w zadaniu. Następnie musimy upewnić się że nie zepsuliśmy istniejących wcześniej funkcji. Jeśli oba warunki zostały spełnione możemy podzielić się naszym kodem z innymi. W tym celu sprawdzamy czy kod działa także bez problemu na innych maszynach. Różnice w konfiguracji pomiędzy dwoma komputerami bardzo często są przyczyną problemów.

Naszym obowiązkiem jest udowodnić że program wykonuje się poprawnie nie tylko u nas, ale przede wszystkim tam gdzie docelowo będzie uruchamiany (np. Na serwerze lub na komputerze klienta). Gdy nasz kod trafi wreszcie do wspólnej puli pozostaje tylko przeprowadzić wydanie i potencjalnie wdrożenie. Kolejny krok, czyli demonstracja wykonanej pracy przed klientem nie jest powszechną praktyką, ale również warto o nim pamiętać.

Jeśli w tym momencie czujesz już nadmierne obciążenie obowiązkami, mam dobrą wiadomość. Wiele z tych kroków jest w pełni bądź częściowo zautomatyzowanych i potrafi zajmować łącznie mniej niż godzinę.

Warto dodać że kod tworzony przez programistów pracujących w firmie nie jest własnością ani zespołu projektowego ani pojedynczych programistów. Stanowi własność firmy i w związku z tym powinien spełniać pewne określone standardy.

Ich celem jest zapewnienie by każdy pracownik, niekoniecznie związany z danym projektem, był w stanie zrozumieć co robi dany projekt oraz dokonać w nim zmian. Do tego celu tworzy się zarówno dokumentację techniczną, jak i reguły dotyczące np. sposobów formatowania kodu, nazewnictwa funkcji i zmiennych, czy sposobów komunikacji w zespole.

Doświadczenie w rozwiązywaniu problemów

Teraz, gdy widzimy szerszy obraz pracy programisty, lepiej możemy zrozumieć czym może być wspomniane na początku doświadczenie. Może więc ono zawierać: doświadczenie w korzystaniu z technologii w rzeczywistych projektach, doświadczenie w korzystaniu z systemów zarządzania zadaniami, doświadczenie w pracy zespołowej, umiejętność rozwiązywania problemów, umiejętność zarządzania własnym czasem, umiejętność zrozumiałej komunikacji, empatię z klientem i resztą zespołu, umiejętność czytania i pisania dokumentacji technicznej, czy umiejętność stosowania się do obowiązujących reguł.

Wiele z tych umiejętności nie jest cechą wyjątkową branży IT, dlatego można ją zdobyć także w innych dziedzinach. Jak jednak nauczyć się tych, które nie występują nigdzie indziej? Poniżej przedstawię kilka przykładów które mogą pomóc zaznajomić się z branżą i zdobyć odpowiednie doświadczenie.

Praktyki i staże

Jedna z popularniejszych metod zdobywania doświadczenia to wzięcie udziału w praktykach lub stażach. Wiele firm oferuje taką formę zatrudnienia. Informacji o dostępności praktyk zwykle możemy szukać na uczelniach technicznych, natomiast w przypadku staży — w Urzędach Pracy.

Zarówno staże jak i praktyki służą ułatwieniu zdobycia pierwszego doświadczenia w branży. Są między nimi jednak pewne różnice. Praktyki skierowane są głównie do studentów i mogą być płatne lub bezpłatne. Czas trwania praktyk, jak i zakres obowiązków nie są odgórnie ustalone.

Staże współfinansowane są przez urzędy pracy. W zamian za to pracodawca zobowiązany jest zatrudnić stażystę po upływie czasu trwania stażu. Czas ten nie może wynosić więcej niż 12 miesięcy.

Podczas poszukiwania praktyk bądź stażów które pozwolą nam zdobyć doświadczenie warto jest szukać firm które pozwolą nam pracować w zespole. Jak wyjaśniliśmy we wstępie, to właśnie umiejętność współpracy, komunikacji i używania narzędzi wspierających komunikację jest tym, czego nie nauczymy się czytając książki, artykuły, bądź oglądając kursy wideo.

Pomimo tego że praca w zespole jest ważna, nie możemy jednak zapominać o wątku technicznym. Dobór praktyk czy stażu powinien nam umożliwić również rozwój i naukę w wybranych technologiach w których chcielibyśmy się specjalizować lub które chcielibyśmy poznać.

Projekty i społeczność Open Source

Temat udzielania się w projektach i społeczności Open Source jest tematem bardzo szerokim. Można mu spokojnie poświęcić osobny artykuł. Taka działalność bowiem może nam pomóc na każdym etapie kariery, nie tylko na początku gdy chcemy dopiero poznać branżę.

W tym artykule skupimy się tylko na jednym z aspektów. Mianowicie jak Open Source może nam pomóc zdobyć doświadczenie w interesujących nas technologiach, w pracy zespołowej oraz w użyciu narzędzi wspierających taką pracę.

Zanim do tego dojdziemy, wyjaśnijmy sobie najpierw czym jest Open Source. Mimo iż wiele osób mogło słyszeć ten termin nie każdy zdaje sobie sprawę z jego pełnego znaczenia.

W wolnym tłumaczeniu “Open Source” znaczy tyle co “Otwarte Źródło”. Otwarte czyli dostępne dla każdego (do czytania lub modyfikacji). Źródło zaś odnosi się do kodu źródłowego, czyli instrukcji zapisanych w określonym języku programowania. Kod źródłowy zwykle kompilowany jest do kodu maszynowego i w takiej formie dystrybuowany. Dlatego nie jesteśmy w stanie zmieniać zachowania wielu programów z których korzystamy na co dzień. Mamy dostęp do kodu maszynowego, a nie do łatwego w modyfikacji kodu źródłowego.

Mimo iż wiele programów funkcjonuje wyłącznie w formie zamkniętej, jest też mnóstwo popularnych projektów które tworzone są przez społeczność. Społeczność, ponieważ w projektach Open Source każdy z nas może być współautorem. Do popularnych programów Open Source należą system operacyjny Android, przeglądarka internetowa Mozilla Firefox, odtwarzacz multimediów VLC, czy edytor graficzny GIMP.

Na udzielanie się w projektach Open Source możemy patrzeć jak na wolontariat. Pomimo iż istnieje wiele sposobów zarabiania na Open Source (jako dodatkowy dochód lub jako jego główne źródło) większość osób nie traktuje takiej pracy jako zarobkowej.Motywacją jest zwykle możliwość rozwoju lub stworzenia czegoś korzystnego dla większego grona odbiorców.

Udzielanie się w społeczności Open Source jest korzystne nawet wtedy gdy dopiero uczymy się umiejętności technicznych takich jak testowanie, czy programowanie w określonym języku. Projekty często potrzebują także wsparcia w innych dziedzinach jak pisanie dokumentacji, tłumaczenia, przygotowywanie grafik, czy marketing. Krótko mówiąc jeszcze zanim zaczniemy zdobywać umiejętności z branży IT możemy wykorzystać swoje obecne zdolności by wspomóc projekty Open Source.

Takie projekty w dużej mierze funkcjonują jak analogiczne projekty komercyjne. Praca odbywa się w zespołach projektowych, opiekunowie projektu wraz z innymi członkami zespołu przygotowują zadania oraz korzystają z podobnych narzędzi co komercyjne firmy.

Co więcej, ponieważ projekty Open Source tworzone są w sposób otwarty i publiczny mają do nich wgląd także rekruterzy. Coraz powszechniejszym zjawiskiem jest otrzymywanie ofert pracy tylko i wyłącznie w oparciu o nasze osiągnięcia w pracy z Open Source. W odróżnieniu od CV czy profilu LinkedIn które możemy mocno koloryzować, nasz wkład widoczny publicznie na platformach takich, jak GitHub, GitLab, czy BitBucket pokazuje nasze praktyczne umiejętności. Nic dziwnego w tym że mnóstwo programistów starannie pielęgnuje portfolio zapełniając je projektami Open Source. Dzięki temu rozwijają się osobiście, a ponadto mogą przedstawiać swoje osiągnięcia potencjalnym pracodawcom.

Udział w warsztatach i hackathonach

Ostatnim sposobem zdobywania doświadczenia jakiemu się przyjrzymy jest udział w warsztatach i hackathonach. Warsztaty to nic innego jak zorganizowane spotkania, zwykle trwające kilka godzin, których celem jest stworzenie działającego produktu wykorzystując praktyczną wiedzę. Warsztaty zwykle są prowadzone przez doświadczoną osobę, mają określony temat, a często także określony przebieg.

Czymże jednak są hackathony? To określenie powstało jako zbitka wyrazowa “hacking” i “marathon”. Oznacza więc ono hackowanie bez przerwy przez dłuższy czas. Zwyczajowo hackathony trwają od kilku godzin do kilku dni (z przerwami lub w ekstremalnych odmianach bez przerw).

Jeśli w głowie pojawiają nam się teraz podejrzanie wyglądający ludzie próbujący włamać się do czyjejś skrzynki pocztowej i wykraść dane, trzeba wyjaśnić jeszcze jedną rzecz. W żargonie używanym przez programistów “hackowanie” oznacza po prostu rozwiązywanie ciekawych problemów, zwykle w sposób kreatywny a często również zaskakujący. Bardziej ogólnie można tym mianem określić także dowolne działania programistyczne nie związane bezpośrednio z pracą zarobkową. Stąd często spotyka się określenie “hackerzy Open Source” (czyli osoby udzielające się w projektach hobbistycznie).

W przeciwieństwie do warsztatów które posiadają strukturę i prowadzącego, hackathony zwykle pozbawione są konkretnego planu. Mają określony temat przewodni, jednak dobór zespołów, wybór technologii, czy określenie zakresu projektu pasującego do tematu zależą już tylko i wyłącznie od wyobraźni uczestników.

Zarówno warsztaty jak i hackathony są nie tylko świetnym sposobem do nauki i zdobywania doświadczenia. Ponieważ w obu przypadkach wytwarzamy funkcjonujący produkt, możemy go następnie wykorzystać do rozszerzenia naszego portfolio. W tym miejscu dwa tematy niejako łączą się, gdyż efekt naszych warsztatów lub hackathonu staje się jednocześnie naszym wkładem w społeczność Open Source w momencie gdy publikujemy jego źródła.

Warsztaty i hackathony pozwalają nam rozwinąć zdolności zarówno techniczne jak i interpersonalne. Są więc dobrą podstawą do budowy doświadczenia. W odróżnieniu jednak od poprzednich sposobów brakuje im możliwości obserwowania długoterminowej dynamiki pracy w zespole. Po kilku godzinach (lub dniach) zespoły rozchodzą się i najprawdopodobniej nie będą już w najbliższym czasie pracowały w zbliżonym składzie.

W życiu zawodowym natomiast rzadko kiedy po wydaniu jednej wersji produktu zabieramy się za kolejne wyzwania. Warto więc traktować je jako wartościowy dodatek, ale nie jedyne źródło zdobywania doświadczenia.

Zakończenie

Jak widać praca w branży IT to znacznie więcej niż tylko rytmiczne uderzanie w klawiaturę. Mnogość procesów, narzędzi czy rytuałów może wydawać się onieśmielająca. W rzeczywistości są one znacznie mniej straszne. Prawdą jest natomiast że wymagają oswojenia i częstej praktyki.

Jeśli zależy nam na znalezieniu pierwszej pracy jako programista warto już wcześniej zacząć zdobywać doświadczenie i z bliska poznawać branżę. Najlepiej jeśli temu poznawaniu towarzyszy także budowanie portfolio rzeczywistych projektów.