Czasem w pracy developera pojawiają się zadania, z którymi nie potrafimy sobie poradzić od ręki. Ba! Nawet częściej niż czasem. Przecież nikt nie jest w stanie zdobyć całej wiedzy świata…
W takich sytuacja zdarza mi się odczuwać bezsilność i bezradność. Bezsilność związaną z tym, że chcę coś zrobić szybko, a nie mogę. Gdy pewne ludzkie ograniczenia dają o sobie znać, nie zawsze czuję się komfortowo. Bezradność z kolei powiązana jest z poczuciem, że brakuje mi wiedzy z danego języka / frameworka / biblioteki, którą POWINNAM mieć.
Gdy pojawiają się takie odczucia, łatwo mi zacząć w myślach obwiniać siebie, co obniża zdolność szukania rozwiązań. A ponieważ nie tylko ja odczuwam takie emocje, gdy kod stawia swoje wyzwania postanowiłam podzielić się swoimi pomysłami na to, jak wyjść poza bezsilność, bezradność i przejść do działania.
Bezsilność (nie tylko) juniora
Kiedy zaczynałam pracę w IT i mogłam dumnie tytułować się juniorem, wydawało mi się, że poczucie bezsilności i bezradności jest właściwe tylko juniorom. Przecież wynika ono z braku wiedzy i doświadczenia, które pozwoliłyby szybko uporać się z każdym zadaniem!
Wydawało mi się, że po zrobieniu odpowiedniej liczby kursów, ukończeniu bootcampa, codziennym kodowaniu przez rok i dostaniu się do programu mentoringowego, … (i tu dopiszcie swoje warunki), nie będę już nigdy walić głową w mur. Nigdy! Jak jeszcze nauczę się w kolejny rok całego frontendu, backendu, cybersecurity i może jeszcze czegoś z obszaru devops, ogarnę może jeszcze coś z LLM, to już żadna praca mi nie będzie straszna!
Jak możecie się domyślać, nie był to najlepszy pomysł – doprowadził jedynie do wzrostu odczucia frustracji. W końcu nie da się zdobyć całej wiedzy potrzebnej do pracy. Jednak mimo tej świadomości była we mnie pokusa „załadowania” głowy całą wiedzą już na początku drogi w IT. Było też poczucie, że jak zdobędę tę wiedzę, to wszystkie moje problemy rozwiążą się w magiczny sposób.
Podejrzewam, że wielu nowicjuszy myśli jak ja kiedyś. I nie tylko nowicjuszy – można z takim nastawieniem przejść całą swoją karierę. I nie chodzi mi tu o pęd do zdobywania wiedzy, lecz o poczucie, że jak zrobię jeszcze ten jeden kurs to już na pewno poczuję się pewnie, nie będę doświadczać trudnych emocji kodując, nie spotkają mnie wyzwania, w których będę potrzebować pomocy. Takie poczucie generuje tylko więcej frustracji, ponieważ każe działać na rzecz celu, który po prostu jest nieosiągalny.
Zadawanie właściwych pytań
W obliczu ogromu wiedzy w wielu przypadkach ważniejsza od jej posiadania staje się umiejętność nauczenia się odpowiedniego podejścia do nauki oraz wyszukiwania wiedzy, która jest nam potrzebna. Mindset, który jest obcy szkole, a który zakłada, że po zdobyciu pewnej bazowej wiedzy (np. podstawowych założeń JavaScipta, Reacta, czy jakiejkolwiek biblioteki) resztę wiedzy możemy znaleźć w sieci. Dopóki więc nie chcemy się wiązać z jakimś rozwiązaniem na lata, na start potrzebna jest wiedza ogólna i wiedza, jak odpowiednio tę wiedzę rozbudowywać.
Ten mindset jest ważny i jeszcze do niego wrócę w tym wpisie. Jednak w momencie, gdy napotykamy na poważny problem, nie interesuje nas budowanie podejścia, które może usprawnić dalszą pracę. Interesuje nas obecny problem i jego rozwiązanie w takim czasie, który nie przyprawi nas o siwe włosy. I tu przydaje się sztuka zadawania właściwych pytań, czyli umiejętność rozbijania problemów na mniejsze.
Jakiś czas temu po raz drugi podeszłam do oswajania ChataGPT3.5. To dla mnie wielkie osiągnięcie, ponieważ wbrew temu, iż pracuję w IT, do technologii podchodzę raczej staroświecko: na telefonie mam minimum potrzebnych aplikacji, a do rozwiązań typu Chromecast podchodzę z dystansem i potrzebuję czasu, by je oswoić. Dlatego też oswojenie ChataGPT też zajęło mi nieco czasu.
Moje pierwsze podejście zakończyło się porażką, ponieważ nie wiedziałam, w jaki sposób formułować prompty tak, by uzyskać pomocną odpowiedź. To z kolei wynikało z odruchowego, całościowego podejścia do problemu. Trzeba napisać wtyczkę – to piszę Chatowi co powinno w niej być i jak powinna działać. Trzeba napisać kwestionariusz – przedstawiam cały algorytm działania. Być może bardziej zaawansowane rozwiązania dałyby radę, ja jednak na ten moment korzystam z rozwiązania darmowego.
I nie jest to złe, ponieważ zmusza mnie do rozbijania zadań na mniejsze: napisanie jednej funkcji, dodanie jednego elementu. Zmusza też do napisania sobie roboczego algorytmu, jak dana funkcjonalność ma działać. To zaś pomaga mi w formułowaniu lepszych pytań dla ChataGPT i używaniu lepszych słów kluczowych, gdy korzystam z wyszukiwarki by znaleźć interesujące mnie odpowiedzi na StackOverflow.
Takie podejście pozwala mi uzyskać lepsze odpowiedzi, które przekładają się albo na przyspieszenie kodowania, albo na lepsze kolejne pytania. I jest zdecydowanie lepsze niż pisanie na chybił – trafił i oczekiwanie, że dostanę odpowiedzi na niezadane pytania. To nie znaczy, że nie patrzę wciąż całościowo – w końcu chcę osiągnąć jakiś cel. Jednak rozbijając duży problem na małe kawałki do zakodowania osiągam go szybciej, niż gdybym próbowała robić wszystko, naraz, bez odpowiedniego wsparcia LLM czy skumulowanej w siedzi wiedzy.
Sztuka zdobywania wiedzy
Ostatnio znów wróciłam do nauki VueJS. Wybrałam ten framework trochę na chybił trafił, znudzona pracą z WordPressem i z Reactem. Kurs nie idzie mi super lekko, co jednak nie jest związane z trudnościami z motywacją. Raczej z tym, że moje podejście do nauki się zmieniło i już nie robię kursów od deski do deski.
Projekty, w których koduję na co dzień, opierają się na różnych rozwiązaniach: od zwykłego HTMLa, CSSa i JSa, poprzez WordPress i Woo, na Astro, React i Vue kończąc. Gdybym uczyła się każdej technologii od deski do deski, może zaczęłabym w niej kodowanie w nieokreślonym KIEDYŚ – krainie, w której robię wszystkie kursy świata by uzyskać pewność, że rozwiążę każdy problem. O tej krainie wspomniałam pisząc o wręcz kompulsywnym zdobywaniu wiedzy na początku wpisu.
Jakiś czas temu, dzięki bootcampowi, w szybki sposób usystematyzowałam zdobytą już wiedzę i nauczyłam się podstaw m.in. Reacta. Dzięki tej wiedzy, powtarzanej prawie codziennym kodowaniem, mogę rozwijać projekty w innych technologiach, np. Vue czy Astro. Nie straszne mi jest czytanie dokumentacji, szukanie odpowiedzi na dobrze zadane pytania, czytanie książek czy robienie kursów.
Wszystko to jednak stosuję w formie doraźnej. Jeśli czegoś potrzebuję – to czasem robię kurs od deski do deski. Zazwyczaj jednak zaczynam coś i powoli kontynuuję, w miarę, jak moje doświadczenie rośnie i tworzy przestrzeń na nową wiedzę i nowe pytania. Nie katuję się tym, że nie zrobiłam jakiegoś kursu do końca.
Mam oczywiście za sobą i nietrafione zakupy kursów, lecz nie cierpię już na kursozę – konieczność kupowania kursów „na zaś” by poczuć, że się rozwijam. Mam kursy, które kończę szybko od deski do deski, jednak jeśli tak działam, mam ku temu dobry powód. Nie wpadam w pułapkę obiecywania sobie, że kiedyś skończę ten kurs, albo mówienia sobie, że zacznę kodować jak nauczę się czegoś jeszcze.
Po prostu działam. I w tym momencie przyspieszam kurs VueJS, ponieważ jest mi potrzebny do dalszego działania na projekcie.
W krainie sprawczości
Zmiana podejścia do nauki oraz dzielenie problemów na mniejsze pomagają mi omijać krainę bezsilności i bezradności. Odpowiednie nastawienie do nauki długoterminowej skutkuje coraz bardziej efektywnym podejściem do pisania kodu. Odpowiednie dzielenie problemu zaś pozwala uniknąć krótkoterminowej frustracji.
Jako człowiek, który uwielbia zdobywać wiedzę boleję, że nie mogę jej nabywać w tempie Neo z Matrixa. Zdobywam jednak wystarczająco dużo wiedzy, by rozwijać się jako programista i, potocznie mówiąc, „dowozić” projekty.
Mój kod nie jest idealny. Być może senior popatrzyłby nań i zapłakał rzewnymi łzami. Jednak dopóki ten kod działa i przynosi pieniądze, musi być wystarczająco dobry. Nieidealny, nie zawsze odpowiednio rozlokowany w modułach i napisany bez wstydliwego kodu typu znacznik !important w CSS. Tak, to potrafi generować dług technologiczny, ale który projekt go nie ma? Dopóki jest to dług, który jest do udźwignięcia – jest on akceptowalny.
Dzięki takiemu podejściu zamiast wiecznie czekać na swoją szansę mam do czynienia z żywym, projektowym kodem i zdobywam bezcenne doświadczenie. Nie przeszkadza mi też aż tak brak code review i brak mida czy seniora, który by mi coś podpowiedział. Praca w typowym zespole być może mogłaby przyspieszyć mój rozwój, lecz w sytuacji jej braku robię lemoniadę z tych cytryn, które dostałam od losu. I mam nadzieję, że kiedyś będę mogła jako mid czy senior pomagać w nauce innym!
Najważniejsze jednak jest to, że takie podejście pozwala mi budować moje poczucie kompetencji i obracać się w krainie, w której nie ma problemów nie do rozwiązania – są za to: wyzwania, na które jestem gotowa albo jeszcze nie jestem, ale mogę być. Albo wyzwania, które nie są moimi wyzwaniami – i wtedy zajmuje się nimi ktoś, kto np. jest specem od backendu czy cubersecurity.
