10 błędów, które niszczą Twoje szanse na karierę w IT

Transkrypcja

Dziś gościem i prowadzącym jestem ja sam. Z tej strony Mateusz Bogolubow, programista od 20 lat i mentor od 10 lat. Dziś opowiem o 10 błędach, które niszczą szansę na karierę w IT. Skupię się w szczególności na pracy programisty, ale omawiane błędy są w miarę uniwersalne, więc nie tylko przyszli programiści skorzystają. Jak widzisz, testuję nową formę podcastu, więc już teraz proszę Cię o łapkę w górę i komentarz, jeśli taka forma przypadła Ci do gustu.

Na początek wypada się przedstawić. Postaram się skrócić ten element do minimum, aby jak najszybciej przejść do konkretów. Uważam jednak, że warto go wysłuchać, aby ocenić kontekst moich spostrzeżeń z kolejnych punktów. W 2005 roku uruchomiłem swoją pierwszą stronę internetową webmade.org, która dotyczyła webmasterki, czyli wszystkiego, co jest niezbędne do utworzenia strony internetowej. Już w 2009 roku założyłem działalność gospodarczą związaną z wytwarzaniem aplikacji internetowych. Głównymi moimi technologiami były JavaScript, PHP, bazy danych, różnego rodzaju frameworki, biblioteki oraz CMS-y. Od 2016 roku prowadzę szkolenia stacjonarne, a od 2020 roku mentoring online z programowania. W międzyczasie stworzyłem kilka kursów wideo dla Strefy Kursów czy No Fluff Jobs w ramach Masterclass. Udzielałem się także dla serwisu Just Join IT jako autor treści na bloga.

Z moich szacunków wynika, że ponad 100 osób, które uczyłem programowania, znalazło pracę w branży IT. Każdego tygodnia rozmawiam z około 10 osobami, które chcą się przebranżowić do IT, dlatego uważam, że jestem na bieżąco z problemami, które dziś omówię. Jeśli Ty również chcesz ze mną porozmawiać na temat przebranżowienia do IT, niezależnie od technologii, jaką wybrałeś, to zapraszam na bezpłatną rozmowę pod adresem devmentor.pl/rozmowa. I to tyle, jeśli chodzi o moją osobę. Teraz przechodzimy do obiecanych błędów. Czym się charakteryzują i jak je zidentyfikować oraz naprawić dzięki odpowiednim pytaniom.

Zaczynamy od pierwszego błędu, czyli brak planu i chaotyczna nauka. Charakteryzuje się to brakiem określonych etapów nauki, ciągłą zmianą technologii oraz kursów, a także brakiem zadań utrwalających i projektów systematyzujących. Dla przykładu, na ścieżce Frontend, którą prowadzę, jest 120 zadań oraz 19 projektów. To zadania niezależne od materiałów kursowych, trzeba pogłówkować i nie odtwarzać tego, co zostało przedstawione przez autora kursu. Dzięki temu mocno przyswajamy i testujemy to, czego się nauczyliśmy.

Pomocne pytania, które pozwolą zidentyfikować problem i go naprawić, to na przykład: jaki jest Twój konkretny cel, kiedy chcesz go osiągnąć, jak wyglądają jego poszczególne etapy, czego chcesz się nauczyć i w jakim czasie. Dzięki temu możesz oznaczać i sprawdzać, czy jesteś na dobrej drodze, czy masz odpowiedni timing itd. 

Dodatkowo warto się zastanowić: gdzie chcesz pracować, w jakiej formie, jakie masz atuty i ograniczenia. Na przykład atutem może być poprzednia praca. Załóżmy, że pracowałeś w banku, czyli znasz zasady, co powoduje, że dużo łatwiej trafisz właśnie do banku na stanowisko programisty. Znasz już procedury, więc nie trzeba Cię tak długo wdrażać. Natomiast Twoimi ograniczeniami może być czas, czyli na przykład masz rok na naukę. Warto to osadzić w twoim planie. Dodatkowo ważne jest, jakie kursy już zrealizowałeś, których nie dokończyłeś i jakie chcesz zrealizować w przyszłości. To wszystko warto zaplanować, żeby wiedzieć, z czym musisz się zmierzyć. 

Najważniejszy element to określenie działań, które mają najwyższy priorytet. Jeśli będziesz miał ograniczony czas i musiał coś wybrać, nie będziesz się zastanawiać, tylko zrealizujesz ten element, który wcześniej uznałeś za ważniejszy.

Drugi błąd to brak specjalizacji. Jeśli uczysz się frontendu, musisz wiedzieć, w którym kierunku chcesz iść. Czy będzie to React, Vue, czy Angular. Oczywiście można nauczyć się każdego z tych rozwiązań, ale to wymaga dodatkowego czasu. Podobnie w Pythonie, języka trzeba się nauczyć, ale potem warto zdecydować, czy wybierasz bibliotekę albo framework typu FastAPI czy Django. Wybór jednej ścieżki przyspieszy proces nauki i pozwoli Ci pójść dalej. 

Pytania, które warto sobie zadać, to na przykład: jak wybrana technologia wpływa na formę zatrudnienia? W przypadku Angulara częściej będzie to praca w korporacji. Ile czasu musisz poświęcić na naukę tego rozwiązania? Przykładowo, FastAPI jest szybsze do opanowania, Django wymaga więcej czasu. Musisz też sprawdzić, ile jest ofert pracy w danej technologii. Pewnie w przypadku FastAPI będzie ich mniej, w Django więcej. Jeśli masz trochę więcej czasu i chcesz zwiększyć szansę na zatrudnienie, prawdopodobnie lepiej będzie wybrać Django. To nie są łatwe pytania, ale pokazuje Ci, że warto je sobie zadać, żeby widzieć, jakie zalety i wady ma dane rozwiązanie.

Kolejny błąd, trzeci, to zbyt szybkie nastawienie na pieniądze. Oczywiście potwierdzam, że np. po trzech latach w branży można zarabiać 15 000 zł i tak było w przypadku mojego absolwenta około trzy lata temu. Potwierdzam też, że można zarabiać 50 000 zł, mój bliski znajomy tyle osiąga, licząc w euro i przeliczając na złotówki. Można też w pierwszej pracy zarabiać prawie 6 500 zł na rękę i tyle właśnie dostała osoba, która w tym roku znalazła zatrudnienie jako frontendowiec. To była Warszawa, więc stawka mogła być wyższa niż w innych lokalizacjach, ale i tak uważam, że to bardzo dobra płaca na start.

Rozumiem też, że część z was chętnie poszłaby na bezpłatny staż, ale musimy zdawać sobie sprawę z tego, że na początku, Ty jako pracownik, nie wytwarzasz wartości dla firmy. To oznacza, że firma dopłaca do Twojego stanowiska, choćby dlatego, że ktoś bardziej doświadczony musi poświęcić Ci swój czas. Nawet oferta bezpłatnego stażu może być więc dla firmy mało atrakcyjna. Musisz pokazać, że w ciągu sześciu miesięcy inwestycja w Ciebie się zwróci. Dlatego umiejętności oraz portfolio są tak ważne i zaraz o nich powiemy. To też pokazuje, dlaczego specjalizacja jest istotna. Stwierdzenie typu „chętnie się nauczę tej biblioteki, tego frameworka” nie jest zachęcające dla pracodawcy. On oczekuje, że już to potrafisz, bo z jego perspektywy zwiększa to szansę na zwrot inwestycji.

Aby wytrwać proces nauki, poszukiwania pracy i wdrożenia, musisz mieć odpowiednie przygotowanie. Jeśli programowanie sprawia Ci przyjemność, dużo łatwiej wytrwasz cały proces przebranżowienia. Jeśli chcesz zostać programistą tylko dlatego, że można dobrze zarobić, to może być za mało. 

Dlatego prezentuję pytania, na które warto sobie odpowiedzieć. One pozwolą Ci zrozumieć, czy faktycznie programowanie jest dla Ciebie. Pierwsza rzecz: czy lubisz programować, czy daje Ci to satysfakcję, czy będziesz chciał programować nawet wtedy, gdy wynagrodzenie wystarczy tylko na zaspokojenie podstawowych potrzeb Twojej rodziny? Czy masz poduszkę finansową, która pozwoli Ci nie zarabiać w okresie stażu niskopłatnego lub nawet bezpłatnego? Czy liczysz się z trudnym początkiem po to, by w przyszłości mieć lepiej? 

Przechodzimy do czwartego błędu, czyli brak praktyki i portfolio, o czym wspominałem wcześniej. Projekt typu kółko i krzyżyk czy to-do lista jest dobry na pierwszą styczność z językiem, ale nie do pracy, gdzie firma oczekuje wartości, którą przyniesiesz w ciągu sześciu miesięcy. Chciałbym jednak zaznaczyć, że rozbudowana to-do lista zadań też może być dobrym rozwiązaniem, jeśli będzie naprawdę dopracowana. Na rynku jest wiele aplikacji do zarządzania zadaniami, które zarabiają miliony, ale one mają dopracowane funkcje. Prosty mechanizm: dodaj, usuń i tyle, to za mało, bo każdy zrobi coś takiego w godzinę.

Moim zdaniem powinniśmy pokazać co najmniej sześć rozbudowanych projektów na GitHubie. Pewnie zastanawiasz się, dlaczego aż tak dużo, skoro wszędzie mówi się o jednym dużym projekcie. Już odpowiadam, ale zanim to zrobię, przedstawię moją koncepcję. Warto, żeby w tych sześciu projektach pokazać mocne strony każdej technologii. W przypadku frontendu, mając HTML i CSS, dobrze jest stworzyć landing page z responsywnym designem, żeby pracodawca zobaczył, że znamy się na RWD. W czystym JavaScripcie warto przygotować na przykład portfel kryptowalut z wykresami, odpytywaniem do API, żeby znać aktualną cenę i testami jednostkowymi. To pokazuje znajomość ekosystemu JavaScriptu, co może nie być takie oczywiste, bo dużo osób od razu wchodzi w Reacta. Jeżeli trzeba potem przejść na inną bibliotekę, innego frameworka, pojawiają się problemy, bo zaciera się granica, gdzie jest czysty JavaScript, a gdzie dany framework. Jeśli ścieżka dotyczy Reacta, to kolejnym projektem może być aplikacja z wykorzystaniem Reduxa, na przykład narzędzie do zarządzania czasem z testami integracyjnymi. Można też zrobić ciekawy projekt z Reactem i animacjami, na przykład z użyciem styled-components lub podobnego rozwiązania CSS-in-JS.

Ważne, aby każdy projekt dostarczał jakąś wartość. Mam na myśli to, że rozwiązanie powinno być użyteczne dla kogoś w praktyce. Landing page może być stroną dla znajomego prowadzącego biznes. Aplikacja kryptowalutowa może posłużyć osobie, która chce w jednym miejscu przechowywać informacje o posiadanych kryptowalutach, jakichś zmianach i wiadomościach rynkowych. Aplikacja do zarządzania czasem może być pomocna choćby do śledzenia, ile godzin poświęcasz na naukę i budowanie projektów itd. Właśnie o taką wartość mi chodziło, żeby z każdego projektu faktycznie można było skorzystać.

I teraz wracając do tego, dlaczego jeden projekt nie jest najlepszym rozwiązaniem. Za każdym razem, kiedy tworzysz kolejny projekt, jest on zazwyczaj lepszy od poprzedniego, bo zdobyłeś doświadczenie przy wcześniejszych pracach. Nie zawsze masz możliwość ciągłego przebudowywania tego samego projektu. Jeśli na początku popełniłeś błąd, to jego naprawa mogłaby wymagać przebudowania całej aplikacji, co jest nieopłacalne. Dlatego polecam tworzenie kilku projektów, które pokazują Twój rozwój i pozwalają uniknąć problemów z jakością aplikacji. Mam na myśli dług technologiczny, który często pojawia się w trakcie tworzenia rozwiązań. Kiedy wybierzesz jakąś ścieżkę, musisz się jej trzymać, bo cofanie się zwyczajnie się nie opłaca.

Podam przykład, którego często używam w rozmowach, które prowadzę. Wyobraź sobie, że chcesz pomalować dom. Do wyboru masz pierwszą osobę, która pomalowała tylko swój pokój i mówi, że wyszło całkiem dobrze. Masz też drugą osobę, która przygotowała galerię kilku realizacji, pogrupowanych zdjęć pokojów w różnych kolorach, z różnymi układami i odpowiednimi odcięciami. Kogo wybierzesz? Podobnie jest z projektami. Mając kilka, mamy większe prawdopodobieństwo, że ten ktoś się zna na tym, co robi. Jeden projekt mógł wyjść, ale też nie pokazuje całego spektrum umiejętności. Mam nadzieję, że ten przykład dobrze tłumaczy, dlaczego warto zrobić kilka projektów zamiast jednego dużego.

I teraz przechodzimy do pytań pomocniczych związanych z tym błędem. Jakiego typu projekty realizują firmy, do których chciałbyś trafić? Jakich technologii używają te firmy? Kto w nich pracuje i jakie ma portfolio? Odpowiadając na te pytania, łatwiej określisz, jakie projekty sam powinieneś tworzyć i w jakich technologiach. Dzięki temu problem wyboru projektu do zrobienia znika.

Kolejny błąd, piąty, to za dużo teorii i za mało praktyki, często określany mianem tutorial hell. Oznacza to ciągłe oglądanie kursów i mało pisania kodu. Powtarzasz materiał zamiast iść do przodu. Wykonujesz zadania i projekty pokazane w kursach zamiast robić coś twórczego. Efekt jest taki, że nie uczysz się, tylko powtarzasz to, co zobaczyłeś. Taka wiedza łatwo umyka i może się okazać, że nie poradzisz sobie z problemem, który pojawi się później.

Pytania, które warto sobie zadać, to: ile czasu poświęciłeś na pisanie własnego kodu, a ile na oglądanie i czytanie materiałów. Najlepiej, żeby stosunek wynosił 80 do 20, czyli 80% pisanie własnego kodu, 20% oglądanie materiałów. Po drugie: ile projektów napisałeś w ciągu ostatnich ośmiu tygodni? Spokojnie w miesiąc można zrobić dwa projekty, oczywiście w zależności od tego, ile czasu poświęcasz tygodniowo. Ja zakładam, że to około 10–20 godzin. W takim czasie powinieneś zrobić co najmniej kilka projektów. Chodzi o projekty, które sam wymyślisz, a nie te, które zostały Ci pokazane od początku do końca. Jeśli masz tylko zarys, a resztę musisz rozwiązać sam, to jest świetne, bo zmusza Cię do samodzielnego myślenia. I kolejne pytanie: ile dni w tygodniu programujesz, a ile dni masz przerwy. Tu zdecydowanie poleciłbym maksymalnie jeden dzień w tygodniu przerwy. Jeśli przerwy będą dłuższe, to może powodować konieczność ciągłego wracania do materiału, bo łatwo zapominamy. Dlatego bardzo istotne jest, żeby trzymać się założenia, że programujemy codziennie albo maksymalnie co drugi dzień.

Idziemy dalej. Szósty błąd, czyli strach przed porażką i odkładanie procesu rekrutacji. Charakteryzuje się on brakiem wiary w siebie. Uważasz, że ciągle mało umiesz, mimo że masz już za sobą kilkanaście projektów. Wiedza z kursów i pytania na forach są dla Ciebie oczywiste, co świadczy o tym, że Twój poziom jest odpowiedni. 

Warto wtedy zadać sobie kilka pytań pomocniczych, które pomogą zidentyfikować problem lub pokażą, że go nie ma. Ile czasu poświęciłeś na naukę? Policz, ile godzin spędziłeś nad projektami, ale nie wliczaj w to oglądania filmów czy czytania materiałów. Ile projektów zrobiłeś podczas nauki? Czy zrozumienie kodu napisanego przez innego programistę sprawia Ci trudność? Czy rozumiesz koncepcje omawiane przez bardziej doświadczonych programistów? Jeśli odpowiedzi są satysfakcjonujące, to może to jest moment, żeby zacząć szukać pracy, a nie odkładać tego na później. W programowaniu zawsze jest coś nowego do nauki, ale nie o to chodzi, żeby uczyć się bez końca. Trzeba w końcu spróbować.

Dodam, że nie ma też co przesadzać w drugą stronę. Jeśli jesteś dopiero na początku i uczysz się od trzech miesięcy, to raczej nie jest dobry moment, by szukać pracy. Wysyłanie podrasowanych CV tylko po to, żeby zobaczyć, czy ktoś odpowie, to według mnie tworzenie sztucznego tłumu. To jednak temat na inny odcinek.

Przechodzimy do siódmego błędu, czyli złego przygotowania do poszukiwania pracy. Objawia się to brakiem rozeznania wśród ofert i firm. Na podstawie oczekiwań rynku powinieneś przygotować CV, a zazwyczaj robimy odwrotnie. To, czego się nauczyliśmy, wpisujemy do dokumentu i liczymy, że będzie dobrze. Kolejny problem to brak listy miejsc, gdzie można szukać pracy. Jobboardy są najpopularniejsze, nie mówię żeby z nich rezygnować, ale tam łatwo zginąć w tłumie, bo wysłanie CV sprowadza się do wybrania oferty, kliknięcia i gotowe. Wszyscy robią to samo, więc przebicie się przez setki zgłoszeń jest trudne.

Inny objaw to brak odzewu na Twoje CV. To także jest feedback i trzeba o tym pamiętać. W tej sytuacji masz dwie opcje. Pierwsza: problem tkwi w CV i trzeba je poprawić. Druga: Twoje umiejętności jeszcze nie spełniają kryteriów i musisz poświęcić więcej czasu na naukę, projekty czy inne elementy. Nie ma sensu wysyłać kolejnych kilkudziesięciu takich samych dokumentów, skoro efekt wciąż jest zerowy. Trzeba coś zmienić. Charakterystyczny błąd to również brak dostosowania CV do oferty. Jeśli starasz się o dwa stanowiska, na przykład fullstackowe i frontendowe, powinieneś mieć osobne CV pod każde z nich. Dzięki temu lepiej pokażesz elementy ważne dla danej roli.

Pytania pomocnicze w tym obszarze to: czy w portfolio masz projekty potwierdzające umiejętności oczekiwane przez przyszłego pracodawcę? Czy tworzysz statystyki dotyczące rozesłanych CV? Czy robisz rozeznanie wśród obecnych i byłych pracowników? Czy pytasz o feedback? Czy regularnie wprowadzasz poprawki do CV i oceniasz ich jakość?

Błąd ósmy to ignorowanie umiejętności miękkich i sieci kontaktów. Objawia się między innymi ukrywaniem informacji o tym, że chcesz się przebranżowić. Możesz się obawiać, że nie chcesz, aby Twój obecny pracodawca dowiedział się o twoich planach. Ale warto zastanowić się, czy nie powiedzieć o tym swoim znajomym. 

Pewnie uważasz, że Twoje dotychczasowe doświadczenie nie ma znaczenia i nie warto o nim wspominać. Pytania mogą jednak pokazać coś innego: kto w Twoim otoczeniu może mieć styczność z branżą IT? Wiele razy spotykam się z odpowiedzią, że nikt. OK, może nie masz bezpośrednio takiej osoby, ale partner lub partnerka Twojego znajomego może już być w branży, albo ich znajomi. Tutaj nigdy nic nie wiadomo. Warto informować wszystkich wokół.

Ostatnio miałem przypadek, kiedy mój podopieczny został polecony do pracy przez znajomą, która akurat realizowała stronę internetową w innej firmie. Poleciła go i tam właśnie odbył trzymiesięczny staż. To historia, która wydaje się trudna do wyobrażenia, a jednak się wydarzyła. Dlatego mówię, że trzeba rozsiać to ziarno. Nie wiadomo kiedy wyrośnie, ale jeśli go nie rozsiejemy, to na pewno nic się nie wydarzy.

Drugie pytanie: w jaki sposób mogę dotrzeć do osób, które są w branży IT? W jakich sytuacjach i momentach będę informował o tym, że chcę się przebranżowić? Gdzie i kiedy odbywają się meetupy, czyli spotkania branżowe? Można korzystać ze strony crossweb.pl, gdzie znajduje się lista wydarzeń. Ostatni punkt: w jaki sposób moje dotychczasowe doświadczenie może mieć wartość dla przyszłego pracodawcy? Wspominałem wcześniej przykład osoby, która pracowała w banku. To, że znała procedury bankowe, ułatwiło jej wdrożenie się w nową pracę. Miałem też przypadek osoby z linii lotniczych, która trafiła do projektu tworzącego oprogramowanie właśnie dla tej branży. Jej wiedza z wnętrza organizacji była ogromnym atutem, bo potrafiła przewidywać problemy i znała możliwe rozwiązania.

Nawet brak doświadczenia może być wartością. Jeśli jesteś osobą młodą, możesz być bardziej kreatywny, nie zamknięty w schematach i szukać rozwiązań w różnych miejscach. Wszystko zależy od firmy i projektu. Zawsze warto się zastanowić, co z dotychczasowych doświadczeń można wykorzystać.

Błąd dziewiąty to porównywanie się do innych. Przykład: ktoś szybciej robi zadanie niż ja, więc nie ma to sensu i rezygnuję. Pamiętaj, że nigdy nie wiesz, z jakiej pozycji startowała ta druga osoba. Może podchodzi do tematu drugi czy czwarty raz, dlatego radzi sobie szybciej.

Druga sprawa, odwrotna: jeśli ktoś nie może znaleźć pracy, to ja też sobie nie poradzę. Ponownie, nie wiesz, jakie czynniki o tym zadecydowały. Może to być coś tak prostego jak brak klauzuli RODO w CV, co uniemożliwia rekruterom kontakt. Spotykałem się z tym już nieraz podczas przeglądania dokumentów kandydatów. To pokazuje, że nie zawsze powód jest oczywisty. Pamiętaj, aby nie rezygnować tylko dlatego, że komuś innemu się nie udało.

Porównywanie się do innych powoduje tylko spadek motywacji i zwiększa szansę na niepowodzenie. Jeśli śledzisz wątki na grupach facebookowych i czytasz dużo negatywnych komentarzy, algorytm zacznie podsuwać Ci ich coraz więcej. Wtedy możesz mieć wrażenie, że wszyscy o tym piszą, choć wcale tak nie jest. Jeśli ignorujesz pozytywne treści i skupiasz się tylko na tych trudnych, obraz całej branży jest w czarnych barwach. Jednym z rozwiązań, które polecam, jest po prostu przestać reagować na negatywne treści albo wypisać się z grup. To poprawi nastrój i przełoży się na naukę oraz poszukiwanie pracy.

Dodam jeszcze, że z mojego doświadczenia większą wartość ma wytrwałość niż talent. To, że teraz Ci się nie udaje, nie oznacza, że za tydzień, dwa czy miesiąc też się nie uda. Jeśli się poddasz, to oczywiście nie dasz rady. Talent ułatwia na początku, ale później wytrwałość staje się ważniejsza nie tylko w poszukiwaniu pracy, ale też w nauce. Wielokrotnie widziałem osoby, które miały trudności w połowie nauki, a potem nagle coś zaskakiwało i wiele rzeczy stawało się prostych. Dlatego Tobie też tego życzę i pamiętaj, żeby się nie poddawać.

Przejdźmy do pytań wspomagających. Moim zdaniem warto zadawać je sobie zamiast porównywać się do innych: jaki postęp zrobiłem w ciągu ostatniego miesiąca? Pewnie dostrzeżesz ile sam się już nauczyłeś i ile zostało Ci materiału do osiągnięcia celu. Chodzi o to, żebyś zobaczył jaką już drogę przebyłeś i że szkoda na tym etapie rezygnować. Jakie błędy popełniają inni, abyś Ty nie musiał ich popełniać. I ostatnie pytanie: dlaczego to ja osiągnę cel, a nie inni? Jedną z odpowiedzi może być właśnie wytrwałość.

Błąd dziesiąty to zła motywacja. Jej charakterystyka to przede wszystkim uznanie, że programowanie czy branża IT to łatwy sposób na zarobek. O pieniądzach już wcześniej rozmawialiśmy, więc nie będę rozwijał tego tematu. Kolejnym przykładem złej motywacji jest sytuacja, gdy ktoś bliski namówił Cię do programowania. Warto spróbować, ale jeśli po miesiącu czy dłuższym czasie nie poczułeś satysfakcji, to może warto odpuścić i poszukać czegoś innego. Tutaj kluczowa jest wytrwałość i zaangażowanie.

Wiele osób myśli też, że praca przed komputerem jest łatwa. Owszem, nie jest fizycznie wymagająca, zwłaszcza w porównaniu z budowlanką, ale siedzenie osiem godzin dziennie też ma swoje minusy. Może powodować bóle i dyskomfort, szczególnie dla kogoś, kto wcześniej był w ciągłym ruchu. Często słyszę też, że w pracy programisty nie ma stresu, a to nieprawda. Wystarczy przykład z wdrożeniem nowego feature’a i obawą, że nie został poprawnie przetestowany, a od niego zależą duże pieniądze. Odpowiedzialność potrafi wywołać stres. Podobnie z nadgodzinami, zazwyczaj ich nie ma, ale jeśli goni deadline i coś poszło nie tak, to trzeba zostać dłużej. Nie jest tak idealnie, choć na pewno lepiej niż w wielu innych branżach.

Pytania wspomagające w tym obszarze to: czy programowanie sprawia mi przyjemność, czy lubię rozwiązywać problemy, czy lubię tworzyć coś z niczego? Czy jestem świadomy minusów pracy programisty? Porozmawiaj z innymi, podpytaj osoby, które już pracują i zastanów się, czy te minusy będą Ci przeszkadzać.

I to wszystko. Omówiliśmy wszystkie błędy. Daj znać w komentarzu, co dodałbyś do tej listy, czy się ze wszystkimi błędami zgadzasz? Mam nadzieję, że taka forma objawów i pytań wspomagających Ci się spodobała. Może na początku mogą brzmieć dziwnie, ale zachęcam, żebyś spróbował na nie odpowiedzieć i zobaczysz jaki będzie efekt. Pewnie z początku będzie dużo niejasności, ale z czasem pojawią się rozwiązania i wiele spraw stanie się jaśniejszych.

Na koniec przyjęło się, że jednym z ostatnich pytań w podcaście jest pytanie o materiał, z którym warto się zapoznać, dlatego ja polecam mojego ebooka: Przygotuj się do rekrutacji, który z kodem: podcast kosztuje jedynie 9,99 zł. Link znajdziesz w opisie.

Zapraszam do lajkowania i komentowania odcinka na YouTubie, jeśli spełnił on Twoje oczekiwania. Jeśli chciałbyś porozmawiać ze mną o swojej karierze w IT, umów się na bezpłatną rozmowę na stronie devmentor.pl/rozmowa.

Trzymaj się, cześć.