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ą. 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.

No i się zaczęło. Jak przez większość lat szczenięco-młodzieńczych i do wczesnej dorosłości unikałem chodzenia w garniturach, tak tutaj czekało na mnie garniturowe piekło ("Mamy dress code"). 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, z zaledwie małymi lufcikami, przez które niechętnie wpadały 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ą Hellraisera jako interfejsem graficznym (mój wykładowca pokazując moje dzieło naszej wykładowczyni od grafiki komputerowej z pewnym lękiem zapytał, czy to właśnie tego nas uczy na zajęciach). 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 to 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 (koledzy mieli już jakieś doświadczenie na rynku). 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).

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.

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 - w tych dyskusjach nie ma clue, czyli np.: "czy to jest dobre narzędzie do rozwiązania danego problemu".

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, czyli rapera Popka: "Technologia to tylko zabawka, jak będę chciał to zaprogramuje se w brainfucku". Naucz się "uczenia na robocie". 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 moment przywitania Cygwina, a później WSL i WSL2 jako gotowego narzędzia w ramach Windowsa 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%.

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).