Ż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!