Historia moich zawodowych kontaktów z branżą IT zaczęła się w 2005 roku. Pierwsza robota, którą zdobyłem zaraz po studiach to praca w jednej z wielkich firm konsultingowych. W owym czasie nie miałem pojęcia nawet co to za bardzo znaczy – była to dla mnie firma jak każda inna. Różnica polegała na tym, że znajomy powiedział, że u niego szukają toteż zgłosiłem tam swoją kandydaturę. Poszedłem na jakiś psychotest zdolności paranormalnych i podobno poszło znośnie, więc mnie zaprosili na dalsze etapy rekrutacji. Na rozmowie kwalifikacyjnej zdaje się nie błysnąłem (ze stresu), ale finalnie bogowie konsultingu orzekli, że się nadam.

Pierwsza praca i projekt w IT to nie była bułka z masłem, a raczej suchy chleb dla konia

No i się zaczęło. Jak wspomniałem na stronie Wiesz z kim tańczysz, tudzież 'O mnie' zaczynałem od piwinicy - no więc co z tą piwnicą? Już spieszę z wyjaśnieniami. Na pierwszym projekcie na jaki trafiłem manager powitał nas (mnie i dwóch innych kolegów świeżaków) tymi oto słowy: „zapraszamy na galery”, po czym wybrał w windzie przycisk piętra -1. I rzeczywiście – siedzieliśmy stłoczeni jak sardynki, "wiosłując" na dosyć wiekowym sprzęcie, przy malutkich biurkach. A nasz jedyny kontakt ze światem zewnętrznym odbywał się przez mikro-lufciki, przez które niechętnie wpadały do naszej piwnicy promienie słoneczne (ciekaw jestem czy coś w konsultingu się w tym zakresie zmieniło).

Pierwszy projekt to nie były żarty. Przyszliśmy i dostaliśmy na twarz jakąś tonę dokumentacji, power point'ów i cholera wie czego. Wtedy pomyślałem sobie – gdzie ja jestem, co ja tu robię? Chciałem kodować. Jeszcze wczoraj budowałem swój własny odtwarzacz MP3 z głową Pinheada z Hellraisera jako interfejsem graficznym (przyznaję, ku lekkiej konsternacji mojego wykładowcy). W każdym razie – przejście od narzędzia do odtwarzania i ripowania muzyki (które potrafiło również wysunąć tackę CD-ROMa – z tego ficzera byłem szczególnie dumny) vs. niekończące się prezentacje BEZ JEDNEJ LINIJKI KODU. Czy da się bardziej przegrać w życie? No nie sądzę.

Pamiętam jak po kilku pierwszych tygodniach rozmawialiśmy z innymi świeżakami na temat jak najszybszego zawinięcia się z tej roboty. Przeprowadzaliśmy kalkulacje ile powinno się wysiedzieć w danej pracy, żeby w CV dobrze wyglądało. Ja (z zerowym doświadczeniem w temacie - pierwsza praca) kiwałem tylko głową jak piesek-zabawka postawiony w na desce rozdzielczej. Ale, ale – są nowiny. Mieliśmy zacząć kodować. W końcu! Dostaliśmy dostęp do środowiska developerskiego kobylastego CRMa marki PeopleSoft (2/10 – nie polecam) + książkę objętości 1500 stron + zadanie – zrobić, żeby coś się wyświetlało. Nie powiem – była to przygoda. Uzbrojeni jedynie w książkę i brak dostępu do Internetu (w którym umówmy się, na owe czasy i tak byśmy nic nie znaleźli) mieliśmy podołać zadaniu. I tak te dni mijały, a my próbowaliśmy napisać „Helloł World” w „piplsoftowemu” (język to była jakaś wersja Visual Basica, ale równie dobrze mogli mi to kazać pisać w piśmie węzełkowym, bo byłem zakochany w możliwościach C# i nie uznawałem wtedy innych sposobów tworzenia softu niż Visual Studio).

Drugi projekt w IT - czy Excel to narzędzie do grafiki komputerowej?

Z tego obłędu uratowało nas przeniesienie na inny projekt. Mieliśmy „coś robić”, chyba znowu przy PeopleSofcie (jakbym się na tym znał) i jakichś systemach bilingowych (ponieważ widziałem raz biling na jednej prezentacji to byłem przedstawiany jako ekspert). Ale na miejscu okazało się, że trafiliśmy z deszczu pod rynnę. Jedyne co zapamiętałem z tego projektu to wizyty w nieodległej chińskiej knajpce i to, że z nudów napisałem w Excelu operacje rysowania, przesuwania, rotowania obiektów 3D (dokładnie ich siatek) wykorzystując komórki arkusza jako piksele.

Do trzech razy sztuka - wreszcie koduję!!!

I wreszcie (chyba mniej więcej po 2 miesiącach od startu pracy) przyszedł przełom. Wreszcie trafiłem do projektu, gdzie miałem jakąś styczność z kodem. Najlepsze, że był to PL/SQL, który poznałem dopiero na drugim stopniu studiów. A odbyło się to mniej więcej tak:

Przyszedł Senior Manager i rzecze do nas tak:

- Któren tu zna PL/SQL? (a mówił to w języku language, bo taka była moda i dlatego, że był Włochem – go figure)

Jako, że nie należałem specjalnie do wyrywnych i mocno wierzących w swoją studencką wiedzę nie wystrzeliłem z ręką w górze krzycząc JA!JA!, ale zrobił to za to za mnie mój kolega:

- Maciek, ty chyba znasz się na PL/SQLu?

- Prawda li to? - menadżer na to rzecze

Kłamać nie umiałem wtedy jeszcze bardziej niż teraz, więc bez bicia się przyznałem, że:

- No trochę coś kojarzę.

- No to doskonale - rzekł manager, po czym wydał salomonowy wyrok:

- Ty [w sensie do mnie] pójdziesz na projekt X, a Ty [do kolegi] na projekt Y.

Co było dalej?

Dalej było jak na wspomnianych galerach: krew, pot, łzy, a no i pomieszczenie z lufcikami zamieniłem na schowek na szczotki (zupełny brak okien), ale najdziwniejsze z tego wszystkiego, że trochę mi się to podobało. Po powrocie z roboty (a miałem taki okres, że parę miesięcy pracowałem od 9 do 9), krótka przerwa, okazyjny trening i wracałem do nauki. Napędzało mnie to, że odkryłem tyle rzeczy, które były dla mnie nowe, że starałem się w ekspresowym tempie nadrabiać nie tyle zaległości, co zasypywać braki w wiedzy, żeby móc jak najlepiej wykonywać swoją robotę. Krótko mówiąc przy spotkaniu z klientami nie chciałem wyjść na debila - przynajmniej w zakresie wiedzy technicznej, bo w zakresie innych umiejętności zdarzało mi się to nad wyraz często.

Pierwsza praca wymagała ode mnie cały czas uczenia się nowych rzeczy (twardych i miękkich):

• najpierw te PeopleSoft'y
• później grafika komputerowa w excelu ;)
• bash scripting (mnóstwo skryptów, bo wszystko stało na Unixach - na studiach szczerze nienawidziłem ich pisać, dziś nie umiem bez nich żyć)
• Java, WebLogic (Javy uczyłem się sam na studiach w trakcie projektów na zaliczenie, więc moja wiedza była mocno podstawowa)
• mnóstwo tematów związanych z bazą Oracle - znałem PL/SQLa, miałem jakąś wiedzę o podstawowej administracji, ale nic z komercyjnych projektów
• rozeznanie się cokolwiek w procesach biznesowych w telco
• zdobywanie wiedzy o architekturze rozwiązań w firmie telekomunikacyjnej: billingi, integracje, smsy, data huby, CRMy, SMSC, IN, TIBCO, MNP (generalnie to budowaliśmy tam pionierskie rozwiązanie w zakresie zarządzania procesem przenoszenia numerów) - więcej skrótów nie pamiętam, żadnego nie żałuję
• praca z klientem: wymagania, testy odbioru, zamykanie projektu, utrzymanie & rozwój

Ani razu nie zdarzyło mi się skorzystać w pierwszej pracy z narzędzi, z których wydawało mi się, że byłem najlepszy (C#, Visual Studio).

Pierwsza praca mocno określiła mnie jeśli chodzi o technologie i podejście do nich. Pokazała mi, że technologia to są tylko narzędzia i to, że dzisiaj używamy jednej, to nie ma się co obrażać na inne. Do tej pory nie rozumiem internetowych kłótni o to, który język programowania jest lepszy, bo ma jakieś tam ficzery. Mi osobiście w tych dyskusjach zazwyczaj brakuje clue, czyli np.: "czy to jest dobre narzędzie do rozwiązania problemu, który mamy przed sobą?"

Z innych ciekawostek, to takie jedno małe przypadkowe zdarzenie (kiedyś w luźnej rozmowie z kumplami w pracy rzuciłem, że kojarzę tego PL/SQLa + to, że kolega niejako „wypchnął” mnie do projektu) miało wpływ na dalszy rozwój wydarzeń w mojej karierze zawodowej. Na tym projekcie, na który zostałem wypchnięty, poznałem przyszłych byłych wspólników, z którymi tworzyliśmy firmę - najpierw konsultingową, a później tworzącą i wdrażającą rozwiązania na zamówienie dla klientów korporacyjnych.

Co w tym jest dla Ciebie jako osoby początkującej w IT?

1. Technologie mogą nie pasować do tego czego uczyłeś się na projektach własnych, czy uczelni

Prafrazując współczesnego wieszcza (popularnego, ostatnio z dziwnych względów, rapera):

Technologia to tylko zabawka, jak będę chciał to zaprogramuje se w brainfucku

(przyp. red.: Brainfuck to autentyczny język programowania, stworzony w latach 90.).

Naucz się "uczenia na robocie". Wiem, brzmi jak masło maślane, a smakuje jeszcze lepiej. Chodzi o to, że zdobywasz wiedzę i od razu możesz ją zastosować w prawdziwym życiu. Im lepiej opanujesz tę umiejętność tym łatwiej będzie Ci dostosować się do warunków na kolejnym projekcie. Daje to też niepowtarzalną możliwość poszerzania zakresu wiedzy, poznawania nowych technologii i nowych zastosowań dla technologii już znanych. Dzięki temu daje szanse zobaczenia szerszego spektrum dostępnych rozwiązań danego problemu. Kiedy masz tylko młotek, to wszystko wygląda jak gwoździe, a nierzadko po prostu pieprzniesz się nim w rękę, bo potrzebowałeś śrubokręta, tylko nie wiedziałeś, że istnieje.

Mój ulubiony przykład w tym zakresie pochodzi jeszcze z czasów studiów. Wykładowca rzucił nam zadanie: "Analiza korpusu języka polskiego". "A panie psorze - jaka technologia?" '- Dowolna'. No to elo - odpalam Visual Studio i jazda w C#. "several hours later" większość grupy dalej pisze te swoje koślawe IFy, a wykładowca ze zdziwieniem pyta, czy nie znamy narzędzi powłoki Linuxa. Na co my: "że kogo / czego?" (dopełniacz). "No to patrzcie tera" - mówi nam profesor. Napisał parę linijek na czarnym ekranie terminala, które w kilkadziesiąt sekund pozwoliły uzyskać oczekiwany efekt. To warto zapamiętać: dla klientów (lub ogólnie odbiorców Twojego oprogramowania) ważny jest właśnie EFEKT, a nie technologia taka czy inna.

2. Da się nauczyć tego, czego nie lubiłeś i nawet to polubić, ba, stać się w tym nawet niezłym

Robota tak mnie ukształtowała, że pomimo odwiecznego korzystania z Windowsa długo brakowało mi na nim konsoli shell / bash'a, a moment przywitania Cygwina, a później WSL i WSL2 jako gotowego narzędzia w ramach Windows'a przyjąłem jak przyjście mesjasza na ziemię. Do dzisiaj nie przerzuciłem się na PowerShella, bo wszystkie awki, sedy, caty, grepy, curle i wgety żyją sobie w moim mózgu nie płacąc za czynsz, z drugiej strony nie pozwalając się osiedlić tam wiedzy na temat innych możliwości w zakresie skryptowania systemu.

3. Pracuj jakby jutra miało nie być

Cytując innego rapera:

Cannabis, whisky, ananas

Jeszcze będzie czas, by odpoczywać

Ja wiem, że worklife balance, ale warto dawać z siebie wszystko, bo nie wiadomo co czeka za rogiem. Nie bądź roszczeniowy, tylko weź się do roboty.

Na początku drogi najczęściej jesteś zatrudniany/a ze względu na POTENCJAŁ jaki ktoś w Tobie zobaczył.

Potencjał ten, przy odpowiednim zaangażowaniu i dzięki stawianym wyzwaniom pozwoli Ci się sprawdzić, rozwinąć, zdobyć praktyczne doświadczenie. Więc nie spieprz tego. Nigdy nie będzie lepszego czasu, żeby docisnąć gaz do dechy. Jeśli czujesz, że nie rozwijasz się w pierwszej pracy, rób kursy, szukaj innej pracy, koduj po godzinach, angażuj się w open-source, robisz we froncie, zajrzyj do backendu, albo ogarnij o co chodzi w tym CI/CD, pisz testy, automatyzuj skryptami - możliwości jest sporo, a ogranicza chyba tylko wyobraźnia.

Wiem, że zaraz mi wyskoczy jedna z drugim, że to wszystko taka mowa kulczykowa, czy innego boomersa, ale znajdź mi w historii ludzkości ludzi, którzy chcieli coś osiągnąć i zdołali to zrobić dając z siebie 30%. Ja rozumiem, że pracuje się, żeby żyć, ale z drugiej strony uważam, że w życiu są różne okresy - okresy wzmożonej aktywności (w tym zawodowej) i czas, kiedy ta aktywność będzie niższa. Życie co do zasady nie jest "liniowe".

Jeszcze jedna uwaga odnośnie tego okresu, gdy jesteś młod(-a/-y) i zaczynasz swoją przygodę z pracą (nie tylko w IT). W przyszłości będzie już tylko trudniej. Trudniej chłonąć wiedzę i uczyć się nowych rzeczy, trudniej znaleźć na to czas, trudniej znaleźć na to chęci. Za młodu mózg jest jeszcze jak gąbka i łatwo chłonie nowości (pomimo np. wyzwań pozauczelnianych życia studenckiego lub świeżo post-studenckiego;) Druga kwestia to ilość życiowych zobowiązań - jeśli wydaje Ci się, że za młodu masz ich dużo, to masz rację - wydaje Ci się. Z biegiem lat będzie ich coraz więcej, co sprawi, że ilość czasu jaki można poświęcić na zdobywanie wiedzy i doświadczenia będzie coraz mniejsza.

4. Wszyscy narzekają na konsulting, a ja uważam, że na początku kariery jest to ciekawe doświadczenie

Konsulting pozwala inaczej spojrzeć na zadania. Pozwala spojrzeć na nie przez pryzmat rozwiązywania problemów, a nie onanizmu technologicznego, który współcześnie jest coraz częstszy. W szczególności ma to miejsce w środowiskach, które nie zajmują się rozwiązywaniem realnych problemów z wykorzystaniem dostępnych narzędzi, tylko budowaniem od nowa takich samych (ale tylko trochę innych) odpowiedników istniejących bibliotek, języków. W wielu przypadkach jest to przejaw megalomanii, który nie wnosi wiele do otaczanej nas rzeczywistości (oprócz kolejnego frameworka, który problem rozwiązany na 100 sposobów rozwiązuje po raz 101, niekoniecznie lepiej).

Pierwsza praca w IT - podsumowanie

"W tej robocie nic się nie nauczę, uciekam stąd po maks. 3 miesiącach ..."

"Mają jakieś przestarzałe technologie ... Ja mogę tylko w najnowszym ReactJS, deno i żeby nie było bazy relacyjnej, bo się ich boję"

"Nie warto się starać, bo mało płacą ..."

To są częste zdania, które zdarza mi się czytać na temat podejścia do pracy początkujących osób. Co więcej, one nie są związane z kolejnymi pokoleniami, którym ktoś daje ładne amerykańskie łatki, żeby było o czym pisać. Te wszystkie myśli również mi przechodziły przez głowę, gdy zaczynałem swoją przygodę w branży IT.

Historia pokazuje (i pewnie nie tylko na moim przykładzie), że niezależnie od czasów i generacji, w początkowych etapach kariery olbrzymie znaczenie ma solidnie i z zaangażowaniem wykonana praca, umiejętność adaptacji i uczenia się przez doświadczenie.

Pierwsze projekty często bywają trudne i wymagają dużej ilości pracy oraz poświęcenia, ale jednocześnie są cenną lekcją i fundamentem dla dalszego rozwoju zawodowego. Nie warto też podchodzić do technologii jako nowej religii (i wkręcać się w religijne wojny typu czyje kung-fu jest najlepsze), bo język programowania na końcu niewiele różni się od młotka - jest tylko narzędziem.