Świat oczami Beat(k)i

blog osobisty Beaty Lipskiej

11 cennych lekcji po 5 latach jako programistka

Żaden kurs na Udemy nie zastąpi Pair Programming

Często jest tak, że dwoje kochających się ludzi chce mieć dzieci. Wszystko jest super, lecz gdy pewnego dnia dziecko przychodzi i mówi, że jest głodne – kupują mu kurs na Udemy i mówią: masz tu się nauczysz jak gotować. Można też posadzić dziecko przed telewizorem i niech się życia uczy! Oczywiście to jest przenośnia, która obrazuje bardzo częste sytuacje, z jakimi mierzą się młodzi-stażem programiści. Niech oglądają godzinami tutoriale to się tak wyszkolą, że hoho! Jakie jest zatem wyjście? Jaka jest właściwa droga na początku? To jest logiczne – by iść dalej w swoich umiejętnościach – trzeba dziecko wysłać do innych dzieci – niech się razem bawią, doświadczają, uczą rozumieć siebie nawzajem. Jak to jest z programistami? Tak samo. Pracujcie RAZEM, doświadczajcie RAZEM – nie ma lepszej lekcji. I tu wcale nie trzeba być juniorem – ilekroć przychodzi nowa osoba do pracy i nie ma jeszcze doświadczenia w domenie, infrastrukturze, rozeznania w kodzie i kulturze pracy, będzie zagubiona. Czy to ważne? Tak – możesz być seniorem, ale bez doświadczenia w konkretnej firmie, będziesz błądzić jak dziecko we mgle. Dlatego potrzebujesz innych dzieci, które znają rzeczywistość poza mgłą, które znają świat na pamięć i przeprowadzą Cię przez najbardziej zamglone zakamarki systemów. I tak to działa.

Nie chcę programować do końca kariery

To chyba najciekawsza lekcja – dowiedzieć się po kilku latach programowania jako profesjonalny inżynier oprogramowania, że nie chcę programować. Tak. Dokładnie – taka jest prawda – nie chcę. Na początku kariery owszem, pisanie kodu to największa frajda i tak naprawdę tego od nas oczekują – pisania kodu! Świetnie! Ale im więcej się ma doświadczenia tym mniej się koduje – taka jest rzeczywistość. Powiesz, że to totalnie nielogiczne – może i tak! Ale praca programisty to w dużej mierze myślenie, planowanie, projektowanie, wdrażanie, komunikowanie, ewaluacja, odpowiedzialność za wiele rzeczy, które są związane z kodem, ale też zwyczajnie nim nie są. Kod jest tylko środkiem wyrazu, narzędziem, równaniem, a nie wynikiem. A na czym nam zależy? Na kilometrowym równaniu czy wyniku? Moje wnioski po 5 latach są dość mocno związane z procesami i ludźmi. Jeżeli myślisz, że dowiesz się tutaj jakiś nowinek technologicznych to… nie. Nic takiego tutaj nie znajdziesz, bo wiesz – cokolwiek napiszę to po roku czy dwóch będzie tak bardzo nieaktualne, że będzie mi wstyd, że coś takiego napisałam.

To jest świetna branża, ale nie dla wszystkich

Tworzymy z ludźmi dla ludzi, jednak bardzo często zapominamy o tym i tracimy cel sprzed oczu skupiając się na szczegółach, które owszem są ważne, ale gdy stają się ważniejsze niż sam cel – wszystko się rozjeżdża. W tym całym ferworze tworzenia, bardzo łatwo jest się zwyczajnie zgubić. Tak zwyczajnie – po ludzku. I przyznaję – ludzie się gubią. Nawet ci herosi z latami doświadczeń, z tysiącami linijek kodu, z dowiezionymi projektami na czas – jednak dalej się gubią. To jest bardzo ludzkie, jednak sztuką programowania jest również znalezienie wyjścia z tego zagubienia. Dlatego programujemy w teamach, dlatego nie podejmujemy samodzielnie decyzji – ważnych decyzji, dlatego też dzielimy wspólnie sukcesy i porażki. Programowanie to gra zespołowa i jeżeli ktoś tego nie widzi/czuje, nie powinien podejmować pracy jako programista. To nie chodzi o to, by kod po prostu działał, ale żeby miał sens: był spójny, prosty, czytelny, gotowy do rozbudowy. Do tego potrzebujesz wiedzy nie tylko o SOLID czy jakie są wzorce, ale kiedy i w jakim stopniu są przydatne, kiedy warto ich używać. Jednak by móc to dobrze dostrzec, warto rozumieć domenę, w której pracujesz. Tak – cele biznesu powinny być Twoimi. Jeżeli nie są – będzie to praca odtwórcza, a nie twórcza, a takiej pracy – przynajmniej ja – nie chcę.

Trzeba się cenić

Siedzisz na dupie większość dnia, pewnie jeszcze w domu, gapisz się w monitor i Twój mózg pracuje na kofeinie, którą wchłaniasz w zastraszających ilościach. Większość ludzi stwierdzi, że to spoko – bo siedzisz w cieple i tylko stukasz w klawisze. No i w sumie to ma sens, ale… tracisz zdrowie (kręgosłup!!!) i zużywasz siebie. Pytanie: po co? W większości przypadków jest to tylko po to, by ktoś mógł zarobić więcej. Dzięki czemu Ty też zarobisz, jednak jakim kosztem? Jeżeli akceptowalnym to jest ok, jeżeli nie – zawijaj się. Bo jeżeli to, co robisz nie sprawia Ci radości i nie daje Ci korzyści materialnych – szkoda życia. Jeżeli masz korzyści materialne ze swojej pracy, która Cię nie cieszy, to też nie ma na dłuższą metę sensu. Tak samo jest z pracami, które kochasz, ale wynagrodzenie jest niewystarczające to wypalisz się jeszcze szybciej. Jaki tu znaleźć złoty środek? Poznać swoją wartość – od czasu do czasu wyjrzeć zza monitora i dostrzec świat poza nim, zadać sobie pytanie co warto robić, a co się tylko opłaca, a potem znaleźć coś, co warto robić i się opłaca. I musi Ci to dawać radość, choćby tylko na początku. A potem iść dalej zanim wypalisz się totalnie.

Bycie inżynierem(ką) nie jest równe przeciąganiu „tykiecików” jak błyskawica

Chociaż nasza praca czasami tak powinna wyglądać, zwłaszcza, gdy jest dobrze zaplanowana i “dogadana” z drużyną i resztą biznesu. Jednak bezmyślne i bezkrytyczne “dowożenie” nie jest zbyt dobrym sposobem na wzrost jako programista(tka) – to właśnie krytyczne myślenie staje się tu kluczowe do tego, by pracować sprawniej i unikać wąskiego spojrzenia na projekt, ale widzieć większe znaczenie we wszystkim, co robimy. Kwestionujmy ile się da! Warto zadawać sobie i innym pytania, które czasami wydają się być oczywiste, ale czasami mogą zaoszczędzić nam mnóstwo czasu, a co za tym idzie i pieniędzy.

Robienie certyfikatów ładnie wygląda na profilu na LinkedIn lub na CV, ale to strata czasu

Jeżeli robisz certyfikat w nadziei, że się czegoś nauczysz… spoko – może ja coś zrobiłam nie tak, ale… jedyne, czego nauczyłam się robiąc certyfikat AWS to robić notatki z kursów na Udemy i jak wykuć kilkadziesiąt pytań. I to tylko po to, by udowodnić sobie i komuś, że coś potrafię. W istocie czułam się wspaniale dowiedziawszy się, że zdałam, jednak czy moje umiejętności powiększyły się? Nie. Jedyne, co mogło sprawić, że sprawnie korzystam z usług AWS jest po prostu korzystanie z nich na codzień poprzez budowanie i utrzymywanie rozwiązań. Tyle. Budowanie fikcji, udowadnianie, że “coś rozumiem”, gdy niekoniecznie jest to prawdą. Jeżeli robię to dla siebie jako wyzwanie – tylko wtedy ma to sens. Jeżeli masz potrzebę – zrób dla siebie.

Ludzie są ważni, czyli nie samym kodem człowiek żyje

Czy znasz ludzi, którzy odchodzą z pracy, bo im nie pasuje tech stack? Pewnie tak – ja też! Jednak zdecydowana większość ludzi odchodzących z pracy to osoby, które nie odnalazły się w relacjach z innymi: czy to w drużynie czy w departamencie, albo zwyczajnie nie widzieli swojej przyszłości w firmie. Pracujemy w drużynach, a czym jest drużyna? To nie jest grupa ludzi, którzy po prostu pracują ze sobą – to grupa ludzi, która ufa sobie. Nie ma innego wyjścia. To właśnie z innymi ludźmi spędzasz najwięcej czasu w pracy – bez odpowiednich relacji, nie ma szans na dobrą współpracę.

Zostań pragmatycznie agnostyczna(y)

Nie ma sensu się przywiązywać do jednego języka programowania. Zmiany są dobre i potrzebne, jednak czując się zbyt komfortowo z jednym językiem, zamykasz się na zmiany i to już nie jest bezpieczne. Z językami programowania jest trochę jak z modą czy polityką – ludzie podążają za trendem, który w danym momencie wydaje się być najbardziej optymalnym rozwiązaniem. I na pytanie który język jest lepszy/najlepszy – każdy będzie miał inną odpowiedź, bo w gruncie rzeczy języki programowania służą jednemu celowi – tworzeniu oprogramowania, a to jaka ilość ludzi korzysta z danego języka to już kwestie bardzo… ludzkie. W moim przypadku przesiadka z PHP na Golang była dla mnie fajna, jednakże środowisko pracy wymagało pracy w PHP dużo większym wymiarze niż w Go, więc zmiana nigdy nie była całkowita. W moim przypadku to zmiana myślenia i nastawienia była kluczowa w przesiadce na inny język. Na chwilę obecną na tapecie będzie Ruby. I dla mnie nie ma większego znaczenia jaki to będzie język, ważne, bym umiała osiągnąć to, co chcę i by było to zgodne z najważniejszymi założeniami fundamentalnych zasad programowania.

Pewności siebie nabierasz wraz doświadczeniem, doświadczenia z pewnością siebie

W pewnym momencie poczułam się pewniej. Nie potrafię powiedzieć co dokładnie się stało, bo zdecydowanie nie był to jakiś spektakularny moment w mojej karierze. To był proces. Gdy w pewnym momencie zauważyłam, że z każdym nowym zadaniem mam coraz mniej niewiadomych, doszłam do wniosku, że to jest ta droga, którą już przechodziłam. Mam wrażenie, że z architekturą, kodem itd. jest jak z wielkim miastem – by zapamiętać wszystkie ścieżki, należy zwyczajnie nimi przejść raz czy dwa, potem znasz miasto na pamięć i wiesz która ścieżka jest najlepsza, która najkrótsza i która najładniejsza. Gdy piszesz kod – musisz wiedzieć, które rozwiązanie jest najszybsze, a które najbardziej odpowiednie. Co to znaczy odpowiednie? Definicję trzeba dostosować do potrzeb projektu, sytuacji, czasu itd. Kod nie może po prostu „tylko” działać. Tak myślałam na początku – teraz wiem, że to nie jest najważniejsze.

Strach jest dla wygodnych

Rozmowy kwalifikacyjne są jak małe egzaminy – w naszej branży trwają niejednokrotnie bardzo długo i składają się z kilku etapów. Większość z nich to sprawdziany techniczne. Oblałam sporo z nich, zdałam też całkiem sporo. Co jest ciekawe w tym wszystkim… to są doświadczenia, lekcje. Nie umiem nie odbierać ich personalnie. Bałam się być oceniana, bałam się porażek. Wygodnie jest nic nie zmienić, nie przechodzić przez ten strach znowu i znowu… I tak oto mają wybór: przechodzić przez kolejne mozolne często etapy rozmów kwalifikacyjnych albo wykonywać dobrą, bezpieczną pracę – wybór wydaje się być oczywisty, jednak jeżeli cele firmy nie pokrywają się z Twoimi – wybór może okazać się trudniejszy niż cokolwiek innego. Zwłaszcza, gdy nie masz konkretniejszego celu niż po prostu zarabianie pieniędzy. Jeżeli Ty nie zadbasz o własną karierę i rozwój to nikt tego za Ciebie nie zrobi. Nikt.

Będąc lepszą programistką, stałam się lepszym człowiekiem

Jednym z największych wyzwań w moim życiu jest okiełznanie chaosu i wiem – brzmi to zdanie jak żywcem wyjęte z Wiedźmina, ale to nie tego typu chaos. I wcale nie chodzi o chaos dookoła mnie (aka bałagan) tylko ten chaos… we mnie. Okiełznać nie znaczy wykluczyć z mojego życia, bo gdyby nie chaos to pewnie nie byłabym taka twórcza. A co to właściwie oznacza i jak to się ma do programowania? W moim przypadku było to złożenie wielu rzeczy: od praktykowania cierpliwości, łagodności, zgłębiania problemów, studiowania każdego przypadku, praktyka skupienia i akrobacji logicznych. Wcześniej wszystko było YOLO. Dosłownie. Jestem w gorącej wodzie kąpana. Podejmuję wiele pochopnych decyzji, a z kodem tak nie można. Z kodem trzeba widzieć więcej, rozumieć więcej i przewidywać. I tak – te trzy lata zmieniły moje podejście do wielu spraw. Nabrałam pokory do życia, umiejętności, profesjonalizmu. Jedyne, co mogę to praktykować i nabierać doświadczenia. Nie ma innej drogi.

A jak to jest u Ciebie? Jakie lekcje byś dodał(a) – napisz co myślisz w komentarzu! Dzięki za wytrwanie!

Next Post

© 2024 Świat oczami Beat(k)i

Theme by Anders Norén

%d bloggers like this: