W ostatnich latach da się odczuć prawdziwy szał na pracę w IT. Bootcampy powstają jak grzyby po deszczu, na grupach Facebook’owych na których jestem obecny dość często przejawia się temat „przebranżowienia”, a z opowieści firm z którymi współpracuję wiem, że kariera dużej części ludzi aplikujących na stanowiska programistów i testerów ma swój początek całkowicie gdzie indziej. Powód w zdecydowanej większości jest oczywisty – pieniądze.
Nie ma co ukrywać – branża IT jeszcze bardzo długo będzie miała niedosyt pracowników. Do czasu aż AI nie nauczy się współpracować z biznesem i tworzyć rozwiązań których biznes potrzebuje i chce (a nie te o których mówi że chce, bo to bardzo często dwie różne rzeczy) można spać spokojnie. Popyt znacznie przekracza podaż… ale czy na pewno?
Niestety, wcale nie jest tak kolorowo. O ile faktycznie, szacuje się, że w Polsce w 2020 r. brakowało około 50 000 specjalistów, o tyle można rzec że rynek jest wręcz „zalany” osobami z bardzo małym doświadczeniem, świeżo po kursach lub bootcampach.
Oczywiście nie ma w tym nic złego, każdy musi jakoś zacząć. Jednak jeżeli chcecie na prawdę „wejść” w IT, musicie mieć sporo samozaparcia i chęci. Nie chcę w tym wpisie powielać informacji, które znajdziecie na każdym innym blogu/serwisie typu. Na pytania „jak zacząć”, „jaki język na początek” nie znajdziecie tutaj odpowiedzi. Ale bazując na własnym doświadczeniu, postawię kilka ciekawych (mam nadzieję) tez, które mogą rzucić nowe światło na to całe „IT”.
Pisz własne projekty – im więcej praktyki tym lepiej.
To tak jak z jazdą samochodem – można oglądać jak jeżdżą inni, ale jeżeli sami nie spróbujemy to praktycznie nic nam to nie da. Dlatego dołącz do swojej aplikacji na stanowisko link do swojego GITa. Jeżeli nie wiesz czym jest Git – Google IT! Natomiast jeżeli chodzi o pierwsze projekty – najfajniej pisze się coś, czego możemy użyć lub wykorzystać praktycznie. W moim przypadku był to prosty skrypt, który sprawdzał czy na stronie uczelni pojawił się nowy wpis odnośnie wyjazdu na CeBIT (gdzie obowiązywała zasada kto pierwszy ten lepszy) i informował mnie o nim SMS’em (o praktycznym użyciu SMS API przeczytasz tutaj).
Jeżeli jednak kompletnie nie masz pomysłu, a bardzo chcesz nabrać doświadczenia – polecam wyszukać frazę „it projects for begginers”. Na pewno znajdziecie coś dla siebie. Pamiętaj jednak aby starać się pisać kod jak najlepiej. Ponieważ…
Dobry programista to leniwy programista
Zdanie to usłyszałem kilka lat temu kiedy zaczynałem od mojego mentora, który akurat szedł sobie zrobić kawę. I mimo że początkowo nie potraktowałem tego poważnie, do dzisiaj jest to jedna z moich głównych zasad – bycie „leniwym”.
Oczywiście mam tu na myśli pozytywne lenistwo, które zmusza n.as do szukania lepszych, bardziej uniwersalnych rozwiązań. Bardziej doświadczeni od razu pomyślą o DRY (a przynajmniej powinni). Chodzi przede wszystkim o to, żeby każde kopiowanie kodu z jednego miejsca do drugiego wywoływało w nas wewnętrzny niepokój.
Często kopiowany kod rozrasta się niekontrolowanie, a jego utrzymanie będzie koszmarem. Wyobraź sobie że skopiowałeś kod stopki strony wraz z jej treścią na 50 podstron. Załóżmy że zajęło CI to godzinę. Następnego dnia zauważasz, że zrobiłeś literówkę. Wchodzisz więc w 50 różnych plików i ją poprawiasz. Ale robiłeś to przed świętami Bożego Narodzenia, a w stopce dałeś rok. W styczniu wchodzisz więc do niej znowu i zmieniasz rok. Tak, teraz będziesz miał spokój. Przynajmniej do kolejnego sylwestra… 🙂
Już przy samym kopiowaniu kodu powinna zapalić Ci się pomarańczowa lampka, a czerwona przy pierwszych zmianach, które musiałeś zrobić. Szczególnie zwracaj na to uwagę w swoim portfolio lub projektach, którymi chcesz zachęcić do siebie potencjalnego pracodawcę! Sam na początku chcąc wyświetlić nazwę miesiąca dla danej daty zrobiłbym 12 ifów/switcha z 12 case’ami. Kod oczywiście by działał, cieszyłbym się że napisałem 50 linijek kodu. Ale nie to w tym wszystkim chodzi.
Ale skąd wanna-be programista ma to wiedzieć?
Google it! Najpierw sam szukaj odpowiedzi.
Powinien to wiedzieć z internetu. I nie mam tu na myśli kolejnego posta z pytaniem „jak to zrobić”. Zdecydowanie zbyt wiele razy widziałem sytuację, gdzie niedoświadczona osoba dodaje posta z pytaniem „dlaczego to nie działa” jednocześnie dołączając zrzut ekranu z podkreślonym i opisanym przez IDE błędem takim jak poniżej:
Nikt teraz nie pisze w notatniku, nowoczesne IDE informują nas o błędach jeszcze przed kompilacją danego programu. Czytaj co mówi Ci IDE, a jeżeli dalej nie rozumiesz – wpisz w wyszukiwarkę treść błędu. W początkowym etapie gwarantuje, że znajdziesz odpowiedź na swoje pytanie. Pamiętaj że szukając w języku angielskim dostaniesz 95% więcej wyników! A jeżeli znajdziesz ją na Stack Overflow to…
Ze Stack Overflow używaj kodu z odpowiedzi, a nie pytania!
Kopiowanie kodu z odpowiedzi, przecież to oczywiste, czyż nie? Nie do końca 🙂 Najlepiej nie kopiować wcale, a implementować rozwiązania przystosowane do własnych potrzeb. Ale jeżeli już to robić, to z odpowiedzi, a nie pytania!
Na początku stawiaj na rozwój, pieniądze przyjdą chwile później.
Niestety wiele osób ze znikomym doświadczeniem uwierzyło w hasła, że widząc jak napisać prostą pętlę dostaną na początek dużo powyżej średniej krajowej.
Programiści go nienawidzą! Znalazł jeden prosty sposób na zarabianie 15 000zł po 12 tygodniowym kursie!
~Każda reklama Bootcampu
Przez to osoby, które mogły by mieć szansę na pierwszą pracę, z powodu zdecydowanie zawyżonych wymagań finansowych są odrzucane. Jeżeli jesteś świeżo po kursie, powinieneś się skupić na rozwoju, zdobyciu wiedzy i doświadczenia. Owszem, należy się cenić, nikt nie chce pracować charytatywnie. Ale biorąc pod uwagę przesycenie na rynku IT, kilka miesięcy pracy za 3000 brutto da Ci przepustkę do kolejnej pracy za dwa razy tyle. Jeżeli budżet na dane stanowisko wynosi 6000zł, a ktoś niedoświadczony poda kwotę o 4000zł wyższą, to niestety w 99% nie dostanie ani pracy, ani nawet kontroferty.
A może Bootcamp?
Osobiście mam raczej negatywne zdanie na temat Bootcampów. Może nie tyle na ich temat, co na „jakość” absolwentów takich kursów. Ale na to chciałbym poświęcić osobny, kolejny wpis.
Trudne całe to programowanie. Może zostanę testerem?
Jeżeli w przypadku junior developerów możemy mówić o przeroście podaży nad popytem, o tyle w przypadku junior testerów (szczególnie bez doświadczenia) można mówić o powodzi. Gdzie jest problem? W brakach znajomości podstaw oraz spaczeniem obrazu testera w oczach „wanna-be” testerów.
Jeżeli obce Ci są wyrażenia takie jak regresja, testy funkcjonalne czy cykl życia oprogramowania – nie zniechęcaj się, tylko się doucz. O ile w przypadku programistów wszelkie certyfikaty uważam za zbędne, o tyle w przypadku testera na pewno pomoże wyrobienie ISTQB. Według mnie w obecnych czasach to absolutny must have dla junior manual testera.
Podsumowanie
Nie zniechęcaj się! Możliwe że cały wpis ma wydźwięk lekko negatywny i sugeruje że jest ciężko. Jeżeli tak to… o to mi chodziło. Mit łatwości startu i „lekkości” pracy w stosunku do zarobków (nie wysokości, bo jest nieźle) w IT prawdopodobnie wziął się z wydatków marketingowych firm organizujących kursy. Niestety, nie jest tak różowo, a przynajmniej na samym początku.
Jednak powyższy wpis powinien przynajmniej trochę przybliżyć Wam wasz cel. Dla doświadczonych programistów poruszane tematy na pewno są oczywiste. Jednak z własnego doświadczenia mój start byłby łatwiejszy, gdybym to wszystko wiedział.
Serdecznie zachęcam do dyskusji lub podzieleniem się własnymi doświadczeniami w tym temacie!
PS. Jeżeli wziąłeś sobie do serca podpunkt o szukaniu informacji samodzielne, sprawdź koniecznie co to jest DRY i KISS.