Wyznanie absolwenta informatyki bez solidnych podstaw
Na studiach uważałem się za całkiem niezłego. A przecież nie miałem pojęcia, jak ważne są podstawy informatyki, i goniłem wyłącznie za ocenami.
Na swój sposób przykładałem się do zajęć kierunkowych, a do tego miałem nagrody z uczelnianych konkursów programistycznych i konkursów capstone design (zespołowych projektów na zakończenie studiów). Kiedy koledzy z roku męczyli się z błędami w kodzie, stałem obok, sypałem radami, o które nikt nie prosił, i czułem się od nich lepszy. Ale dziś przyznaję się bez bicia: to, co wtedy tworzyłem, było na poziomie dziecięcej zabawy.
Podłączenie porządnej bazy danych (DB) było dla mnie za trudne, więc zapisywałem dane w pliku z Notatnika (.txt), oddzielając je przecinkami (,). Zamiast Raspberry Pi, które wymaga sterowania na poziomie systemu operacyjnego, szedłem na skróty z Arduino, które działa po wrzuceniu kilku linijek kodu. Profesorowie chwalili efekty, które działały sprawnie tylko z pozoru, a ja brałem to za swoje prawdziwe umiejętności.
Rozmowy rekrutacyjne zaliczone na pamięć – tak zaczęła się tragedia
Ale gdy tylko rzuciło mnie na rynek pracy, ta bezpodstawna pewność siebie rozsypała się w drobny mak. Odpadałem raz za razem już na etapie CV. Tytuł laureata konkursów nie zdołał przykryć moich wątłych podstaw informatyki.
Im bardziej dopadał mnie niepokój, tym bardziej obsesyjnie gromadziłem wiedzę na pokaz. Zrozumienie zeszło na dalszy plan – jak maszyna wkuwałem wzorcowe odpowiedzi, byle tylko przejść rozmowy. Moim podręcznikiem była ściągnięta z blogów technicznych lista „100 pytań, które padną na rozmowie”.
Na pytanie rekrutera: „Jaka jest różnica między TCP a UDP?” odpowiadałem jak automat z napojami: „TCP jest połączeniowy i gwarantuje niezawodność, ale jest wolny, a UDP jest bezpołączeniowy i szybki, ale mniej niezawodny”.
Tak naprawdę nie miałem pojęcia, czym jest pakiet ani jak w praktyce przebiega 3-way handshake. Ale, jak na ironię, właśnie dzięki temu mechanicznemu wkuwaniu oszukałem rekruterów, zebrałem całkiem dobre oceny i dostałem pracę. Myślałem, że po prostu miałem szczęście. Nie wiedziałem, że to początek tragedii, w której karma za cztery lata spadnie na mnie za jednym zamachem.
Jak przetrwałem jako full stack w małym zespole
Trafiłem do małego zespołu. Nie było tam żadnych wygodnych podziałów na „frontend” czy „backend”.
Od pierwszego dnia musiałem stawić czoła tsunami technologii. Myślałem, że wystarczy dobrze znać jedno: Javę albo JavaScript. Rzeczywistość wyglądała jednak tak: czarny ekran terminala SSH na Linuksie, kontenery Dockera, o których nie wiedziałem nic, pipeline’y CI/CD w GitLabie, a do tego Spring Boot, Vue.js, a nawet Redis… Technologie, które na studiach odkładałem z myślą „zajmę się tym później” albo lekceważyłem, bo „tego nie trzeba umieć”, atakowały mnie ze wszystkich stron.
Wiedza, którą na rozmowach recytowałem jednym tchem, w pracy na nic się nie zdała. A ściślej mówiąc: nie umiałem jej „zastosować”. Bo żeby zrozumieć, dlaczego uruchomiony przeze mnie kontener Dockera ciągle pada (OOM) i dlaczego Redis zżera pamięć, naprawdę potrzebowałem tych samych podstaw informatyki, które wkuwałem pod rozmowy.
Zamek zbudowany na piasku
W końcu stałem się „programistą kopiuj-wklej”, który jak leci kopiował i wklejał kod (Ctrl+C, V). Funkcje jakoś działały, ale nie wiedziałem, dlaczego.
- CORS Error: dlaczego moja przeglądarka odrzuca odpowiedź serwera? (niewiedza o nagłówkach HTTP)
- OOM (Out Of Memory): dlaczego serwer, który dobrze działał, nagle pada? (niewiedza o wyciekach pamięci i GC)
- Connection Refused: lokalnie działa, to dlaczego po wdrożeniu przestaje? (niewiedza o przekierowaniu portów i zaporach sieciowych)
Nie znając zasad ukrytych za wygodą, którą dają frameworki, nie umiałem niczego naprawić, gdy pojawiał się problem. Budowałem chwiejny zamek z efektownych frameworków na gruncie, w którym podstawy informatyki były dziurawe.
Re: Booting, z powrotem do punktu wyjścia
Dlatego postanowiłem wrócić do początku. Uznałem, że pilniejsze niż zrobienie kolejnego efektownego projektu do portfolio jest znalezienie odpowiedzi na fundamentalne pytanie: „Jak właściwie komputer rozumie i wykonuje mój kod?”.
Ten blog to zapis zaciętej powtórki: absolwent z samym dyplomem w ręku od zera buduje swoje podstawy informatyki. Nie będę tu po prostu wypisywać komend Linuksa ani instrukcji instalacji Dockera. Zamiast tego chcę pokazać, jak stawiam pytania takie jak poniższe i szukam na nie odpowiedzi.
- Language & OS: co się dzieje od kompilacji kodu Javy aż do chwili, gdy dociera on do CPU?
- Network: jaką drogą podróżują pakiety, gdy wcisnę Enter w pasku adresu?
- Virtualization: czym mój laptop różni się od komputera w serwerowni i po co w ogóle wirtualizacja?
- DevOps: jak wdrażać kod, który piszę, bezpiecznie i automatycznie?
Poza localhost
Ostatecznym celem jest samodzielne zbudowanie i kontrolowanie Linuksa, Dockera, CI/CD, a nawet środowiska chmurowego. Mam nadzieję, że będziesz śledzić, jak opuszczam bezpieczną cieplarnię, jaką jest localhost, i staję się inżynierem, który przetrwa nawet w dzikim świecie prawdziwych serwerów.
Tym, którzy jak ja kiedyś mówią: „Przerabialiśmy to na studiach, ale nic nie pamiętam”, chciałbym, żeby ten zapis stał się małym drogowskazem, przy którym klepną się w czoło: „Aha, więc to miał na myśli profesor!”.
