Wyznanie absolwenta z marnymi podstawami CS
Kiedy studiowalem, wydawalo mi sie, ze jestem calkiem dobry. Nawet nie rozumiejac, jak wazne sa podstawy CS, skupialem sie tylko na zdobywaniu ocen.
Po swojemu przykladalem sie do zajec kierunkowych i mialem nawet nagrody w uczelnianych konkursach programistycznych oraz zawodach capstone design. Gdy koledzy z roku meczyli sie z bledami w kodzie, stalem obok, rzucalem uwagami i czulem wyzszosc. Ale jesli mam byc szczery, to co wtedy budowalem, bylo na poziomie dziecinnej zabawy.
Podpiecie porzadnej bazy danych (DB) wydawalo mi sie zbyt trudne, wiec zapisywalem dane w plikach tekstowych (.txt), oddzielajac je przecinkami (,). Zamiast Raspberry Pi, ktory wymaga kontroli na poziomie systemu operacyjnego, wybieralem Arduino, bo wystarczalo dopisac kilka linijek kodu. Prowadzacy chwalili efekty, ktore tylko z zewnatrz wygladaly sensownie, a ja mylilem to z dowodem na swoje prawdziwe umiejetnosci.
Rozmowa kwalifikacyjna zdana na pamiec: tak zaczela sie tragedia
Ale kiedy tylko trafilem na rynek pracy, ta bezpodstawna pewnosc siebie rozpadla sie na kawalki. Odrzucenie gonilo odrzucenie. Sam tytul laureata konkursu nie byl w stanie ukryc moich lichych podstaw CS.
Im bardziej narastal niepokoj, tym mocniej uczepialem sie pustej wiedzy na pokaz. Zrozumienie schodzilo na dalszy plan, a ja wkuwalem modelowe odpowiedzi jak maszyna, byle tylko przejsc rozmowe. Listy typu „100 najczesciej zadawanych pytan na interview” skopiowane z blogow technologicznych staly sie moim podrecznikiem.
Kiedy rekruter pytal: „Jaka jest roznica miedzy TCP a UDP?”, odpowiadalem jak automat. „TCP jest polaczeniowy i zapewnia niezawodnosc, ale jest wolniejszy, a UDP jest bezpolaczeniowy, szybszy, ale mniej niezawodny.”
Prawda jest taka, ze kompletnie nie wiedzialem, czym jest pakiet ani jak naprawde dziala 3-way handshaking. A jednak ironicznie to wlasnie ta mechaniczna pamiec pozwolila mi oszukac rozmowcow, zdobyc niezle oceny i dostac prace. Myslalem, ze to szczescie. Nie wiedzialem jeszcze, ze to poczatek tragedii, w ktorej naraz splaci sie dlug zbierany przez cztery lata.
Fullstackowe przetrwanie w malym zespole
Trafilem do malego zespolu. Nie bylo tam zadnych wygodnych podzialow typu „frontend” czy „backend”.
Od pierwszego dnia pracy stalem przed stosem technologii, ktory nadchodzil jak tsunami. Myslalem, ze wystarczy dobrze znac Java albo JavaScript. Rzeczywistosc okazala sie czarnym ekranem terminala Linux przez SSH, tajemniczymi kontenerami Docker, pipeline’ami GitLab CI/CD, a do tego Spring Boot, Vue.js i Redis… Technologie, ktore na studiach odkladalem na „naucze sie pozniej” albo lekcewazylem tekstem „tego nie musze znac”, zaczely atakowac mnie z kazdej strony.
Wiedza, ktora tak sprawnie recytowalem na rozmowach, w praktyce nie przydawala sie do niczego. A wlasciwie, mowiac precyzyjniej, nie umialem jej zastosowac. Zeby zrozumiec, dlaczego kontener Docker, ktory uruchomilem, ciagle umiera (OOM), albo czemu Redis pozera pamiec, potrzebowalem wlasnie tych podstaw CS, ktore wykulem jedynie pod interview.
Zamek zbudowany na piasku
W koncu zostalem deweloperem od bezmyslnego kopiuj-wklej (Ctrl+C, V). Funkcje jakos dzialaly, ale nie mialem pojecia dlaczego.
Nie znajac zasad ukrytych za wygoda oferowana przez frameworki, nie potrafilem rozwiazac problemu, kiedy cos sie psulo. Budowalem chwiejny zamek z efektownych frameworkow na gruncie oslabionym przez kruche podstawy CS.
Re: Booting, z powrotem do punktu wyjscia
Dlatego postanowilem naprawde wrocic do samego poczatku. Zamiast od razu dorzucac kolejne efektowne portfolio, wazniejsze wydalo mi sie rozwiazanie podstawowego pytania: „Jak komputer w ogole rozumie i wykonuje moj kod?”
Ten blog jest brutalnym zapisem powrotu absolwenta z samym dyplomem do budowania od zera swoich podstaw CS. Nie bede tu po prostu wypisywal komend Linuxa ani instrukcji instalacji Dockera. Chce za to pokazac proces zadawania takich pytan jak ponizej i szukania na nie odpowiedzi.
Poza localhost
Ostateczny cel jest prosty: samodzielnie zbudowac i kontrolowac Linux, Docker, CI/CD, a nawet srodowisko chmurowe. Chce wyjsc z bezpiecznej szklarni o nazwie localhost i stac sie inzynierem, ktory potrafi przetrwac rowniez w surowym, dzikim srodowisku serwerowym.
Dla tych, ktorzy tak jak dawny ja mowia: „Mialem to na studiach, ale juz nie pamietam”, mam nadzieje, ze ten zapis stanie sie malym drogowskazem i wywola moment: „Aha, czyli o to wtedy chodzilo prowadzacemu!”