Junior Developer - pierwsza praca jako programista - JavaDevMatt. 1. Sponsorzy Partnerzy projektu Po co to wszystko?...

Transkrypt

1

2 Spis treści 1. Sponsorzy Partnerzy projektu Po co to wszystko? O czym i dla kogo jest ta książka? Dlaczego nie warto zostać programistą? Dla pieniędzy Bo to "łatwa praca w biurze" MUSISZ się ciągle rozwijać i śledzić nowości Dlaczego w takim razie warto zostać programistą? Do rzeczy: co powinieneś potrafić, by zacząć pracę jako programista? Język Angielski Umiejętność szukania informacji Rozbijanie zadań na małe części i skupienie się na jednej rzeczy jednocześnie Napisać (nawet bardzo mały) projekt od początku do końca Potrafić skonfigurować środowisko pod projekt / 147

3 6.6. Podstawy baz danych (generalnie zapisywanie i czytanie danych), technologii webowych, działania sieci, programowania obiektowego, pisania testów i web serwisów Parsowanie danych: json i xml Praca z narzędziem kontroli wersji: np. git Usprawnianie pracy w IDE, czy innym środowisku Szkoła, studia i odwieczne pytanie o matematykę Zaczniemy od najczęstszego pytania Jak podchodziłem do kwestii szkoły/studiów Dlaczego moim zdaniem warto iść na studia (informatyczne) Dlaczego moim zdaniem nie warto iść na studia (informatyczne) Krótko o belfrach CV, rozmowy kwalifikacyjne i sam proces szukania pracy Co zawierało moje pierwsze CV przy pierwszej pracy programisty i dlaczego było do bani Drugie CV jest poprawa, ale mogło być lepiej Jakbym dzisiaj przygotował CV / 147

4 8.4. Proces szukania pracy Rozmowy kwalifikacyjne Zbieraj doświadczenie w aplikowaniu i wyciągaj wnioski Zadanie praktyczne Przydatne portale Podsumowanie Dzień, organizacja i role w pracy. Agile, Scrum i inne mądre słówka Agile, Scrum i inne mądre słówka Dlaczego lepiej pracować z podejściem agile'owym? Sprint Role w takiej organizacji pracy Podsumujmy krótko czego się już nauczyłeś Praktyczna ścieżka rozwoju same konkrety Język Angielski Umiejętność szukania informacji Dopisywanie example do szukanej rzeczy Nie bój się szukać (nawet prostych rzeczy) Szukaj i nabieraj doświadczenia / 147

5 10.6. Krótki kurs zaawansowanego szukania w Google Rozbijanie zadań na małe części i skupienie się na jednej rzeczy jednocześnie Karteczki samoprzylepne popularne sticky notes Trello proste w obsłudze narzędzie do rozbijania zadań Ćwiczenie skupiania się/wyciszania się krótko o medytacji możesz olać ten punkt Napisanie (nawet bardzo małego) projektu od początku do końca Manager schroniska dla zwierząt Pierwsza gra Skonfigurowanie środowiska pod projekt Rzeczy, w których powinieneś się orientować: Pliki z danymi, zapisywanie i czytanie danych Bazy danych Podstawowe technologie webowe Protokoły komunikacyjne Programowanie obiektowe Web serwisy / 147

6 Testy jednostkowe Parsowanie danych json i xml Praca z narzędziem kontroli wersji: np. git Usprawnianie pracy w IDE, czy innym środowisku Podsumowanie Skąd się uczyć? lista polecanych stron/materiałów Najlepszy start w programowanie świetna (i darmowa!) książka Eloquent JavaScript Marijn Haverbeke Start w Javie Krótkie i przyjemne wprowadzenie w Ruby (po polsku) Dobra książka do C Najlepsze źródło informacji o nowinkach w androidzie Android Weekly Jak wygląda typowy tydzień pracy programisty? Planowanie, estymacja, meetingi Coś nagle nie działa i nie masz na to wpływu Zależności ciąg dalszy / 147

7 12.4. Bugfixing / debugging szukanie i rozwiązywanie błędów Czasami wszystko idzie gładko! Nauka w pracy Krótkie podsumowanie typowego tygodnia Jesteś gotowy do pierwszej pracy? Pytania Podsumowanie Co dalej? Parę słów na koniec Co dalej? / 147

8 1. Sponsorzy Ebook powstał dzięki akcji na portalu PolakPotrafi.pl. Łącznie projekt wsparło 425 osób. Oto lista osób, które wsparły projekt za przynajmniej 75zł i trafiły na listę sponsorów. Łukasz "echoman" K. Patryk Dolata Michał Franc Dominik Minta Piotr Stefański Dominik Kubis Mlody-inzynier.pl - oferty pracy dla młodych inżynierów Organizer leków na Androida - Mobilna Apteczka Jan Jakub Jurec Marek Pawłowski Krzysztof Podkanowicz Damian Kolanek 'Kolan' Paweł Sawicz 8 / 147

9 2. Partnerzy projektu Radio internetowe Kontestacja w sporym stopniu ukształtowało moją przedsiębiorczą naturę, przez którą zacząłem blogować i napisałem tego ebooka. Szczególny wpływ miały na mnie audycje Wydania głównego z lat i audycje Janka Fijora. Posiadanie własnego podcastu w tym radiu również pomogło dotrzeć do szerszego grona odbiorców. Z magazynem Programista współpracuję od stycznia Magazyn wniósł sporo w promocję mojej osoby i tego ebooka. 9 / 147

10 3. Po co to wszystko? Skąd pomysł na napisanie tego ebooka? W lipcu 2014 nagrałem pierwszy filmik na mój kanał na YT. Prosty tutorial o libgdx: bibliotece do multiplatformowego tworzenia gier w Javie (i nie tylko). Ostatecznie na moim kanale JavaDevMatt powstało 10 filmików z serii "LibGDX dla Zielonych". Po promowaniu tej krótkiej serii tutoriali na Wykop.pl, Warsztat.gd i paru innych miejscach w sieci, zaczęło się pojawiać sporo pytań o to gdzie pracuję... Gdy wspomniałem, że w niemieckim startupie tworzącym aplikacje mobilne pojawiły się kolejne pytania: "Jak wyglądała rekrutacja?" "Co zrobić, by kiedyś pracować w podobnym miejscu?" "Czy zarabiasz 15k? ;)". Nagrałem więc filmik o tym jak wyglądała rekrutacja. Taki materiał zdobył sporą popularność: w 2 dni po dodaniu miał więcej wyświetleń niż cała seria o libgdx razem wzięta. Tak zaczęło się nagrywanie filmików i później również pisanie bloga jako "Programista Na Emigracji". Po prawie 1,5 roku prowadzenia bloga JavaDevMatt.pl oraz związanego z nim kanału YT wykrystalizowało się parę 10 / 147

11 pytań, które dostaję ciągle. Na sporo z nich odpowiadam w jakimś filmiku lub wpisie na blogu, ale potrzebne było jakieś miejsce, gdzie jest to wszystko zebrane w całość i jakoś logicznie uporządkowane. Ebook wydał się dobrym rozwiązaniem. Czytelnik ma solidny produkt, gdzie od początku do końca wyjaśniam parę spraw, o które najczęściej pyta, a ja mam sposób finansowania mojego bloga, by nie musieć zaśmiecać go wyskakującymi okienkami z reklamami. Win-win: korzystają wszystkie strony transakcji. Jeśli pobrałeś pdf-a tego ebooka z innego źródła, to polub przynajmniej mojego bloga na FB i daj subskrybcję na YouTube. Uważam, że walka z piractwem to walka z wiatrakami i nie warto na to tracić czasu. Zresztą sam też nie jestem święty w tej kwestii, a nie lubię hipokryzji. Bawcie się dobrze. Mateusz 11 / 147

12 4. O czym i dla kogo jest ta książka? Sporo osób śledzących mojego bloga "Programista Na Emigracji" dobrze wpisuje się w poniższe punkty i zadaje podobne pytania: Interesuję się programowaniem, ale nie wiem czy wiązać z tym przyszłość zawodową. Jeśli wiąże z tym przyszłość, to czy konieczne są w tym kierunku studia? Jaki poziom umiejętności należy posiadać, by aplikować do pierwszej pracy jako programista? Jeśli się uczyć, to z czego? Jak się uczyć, by nauka była skuteczna? W końcu jest sporo pułapek, gdy marnujemy na coś czas, a efekty są kiepskie. Czego spodziewać się w pierwszej pracy jako programista? Jak wygląda typowy dzień i organizacja pracy? W końcu, gdy raz się napisze program i ten "już działa", to po co są te zespoły ludzi, którzy pracują przy utrzymaniu danego oprogramowania?...a co jeśli jestem kiepski z matematyki? 12 / 147

13 Kiedy mam wiedzieć, czy to zajęcie nie jest dla mnie? Co z zarobkami? Chociaż o tym dużo nie będzie. W skrócie: każdy specjalista danej dziedziny może dobrze zarabiać. Nie uważam, że wysiłek, który należy włożyć tutaj jest większy/mniejszy niż w innych branżach. Podążanie w tym kierunku, czy jakimkolwiek innym tylko i wyłącznie dla pieniędzy jest moim zdaniem stratą czasu i marnowaniem sobie życia. Jak wygląda rekrutacja? Jak się przygotować, czego oczekiwać od pracodawcy, co mieć w CV itp. Kiedy można pracować w tym zawodzie zdalnie lub jako wolny strzelec mieszkający na Bali? Jakieś przykłady praktycznych zadań/problemów z którymi spotkałeś się w pracy? Nauka programowania, by zostać programistą gier: jak to jest z pracą w branży gier? Jak bardzo różni się ona od innych branż? Jakie inne stanowiska (oprócz developera/programisty) mogą mnie zainteresować w tej branży? Czym zajmuje się tester/project manager/scrum master? 13 / 147

14 Co to ten cały scrum/agile? Jak to wygląda w praktyce? Na to wszystko postaram się odpowiedzieć w tej książce, czy tam ebooku (w końcu jeśli wydrukujesz sobie ebooka i posklejasz kartki, to już jak książka :D). Jeśli w jakimś stopniu odnajdujesz się w powyższych podpunktach, to zapraszam Cię do dalszej lektury. Jeśli stwierdzisz, że to nie dla Ciebie, to w celu dalszego szukania swojego "Ja" i inspiracji do tego co można ciekawego robić w życiu zapraszam do odwiedzenia radia internetowego Kontestacja.com lub Enklawa.net. W końcu w życiu nie chodzi o to, by było nam łatwo i wygodnie, tylko ciekawie i satysfakcjonująco. Podczas czytania warto pamiętać, że zawarty tu materiał to moje subiektywne opinie i osobiste wnioski oraz przemyślenia. Sporo z Was może (i powinno) się nie zgadzać z częścią zawartej tu treści. Chętnie przeczytam uwagi/krytykę/opinie. Wysyłajcie je na Matt@JavaDevMatt.pl Miłej lektury! 14 / 147

15 5. Dlaczego programistą? nie warto zostać Zanim zaczniemy na coś poświęcać swój czas, warto się zastanowić, czy to jest faktycznie to co chcemy robić. Zdaję sobie sprawę, że programista, to bardzo popularny zawód w mediach: "dobrze zarobisz / zawsze znajdziesz pracę / masz ciepły stołek w biurze", ale osobiście uważam, że współcześnie istnieje taki ogrom rzeczy, które można w życiu robić, że nie warto rzucać się na to, co jest aktualnie polecane nam przez media, znajomych, czy społeczeństwo. Oto parę rzeczy, które nie powinny Cię motywować do tego, by wybrać ścieżkę zawodową programisty. Plus jeden punkt, który jest równocześnie wadą i zaletą (zależy dla kogo) Dla pieniędzy Obecnie najczęstszy powód i pierwsza rzecz, od której zaczynają się konwersacje na temat zawodu programisty: pieniądze. Polska jest tutaj może trochę ewenementem, bo faktycznie na niektórych szczeblach kariery zarabia się trochę lepiej niż w wielu branżach, które wymagają podobnego poziomu 15 / 147

16 zaangażowania. Głównie z powodu możliwości pracy zdalnej dla zagranicznych klientów, czy dużego zapotrzebowania na programistów, przez które tacy pracownicy bardzo chętnie są podbierani. Jednak na świecie programista, tak jak każdy inny specjalista może zarabiać bardzo dobrze, może też średnio, albo po prostu mało (jak na średnią w branży) wszystko zależy od tego, jak dobry jest w tym, co robi. Bardzo dobry inżynier budownictwa, prawnik, dentysta, doradca podatkowy: jeśli jest dobry w tym co robi, to ma sporo klientów, może pozwolić sobie na podniesienie stawki i nadal mieć masę roboty. Bez zbędnego lania wody: chodzi o to, że warto być specjalistą w jakiejś dziedzinie, która sprawia Ci frajdę albo jest Twoją pasją. Bądź specjalistą programistą, jeśli jest to coś, co chcesz robić, a nie dlatego, że rodzina Cię do tego namawia i pcha na takie studia. Warto czasami poświęcić 2-3 lata na szukanie swojego zajęcia, próbowanie różnych rzeczy, niż obudzić się w wieku 50 lat i stwierdzić, że wszystko co robiliśmy nigdy nie sprawiało nam przyjemności i zmarnowaliśmy kawał życia Bo to "łatwa praca w biurze" Z tą łatwością bywa różnie. Zależnie od tego w jakiej 16 / 147

17 firmie pracujemy (inaczej jest w małych firmach, gdzie jesteśmy "od wszystkiego", inaczej w średniej wielkości startupie, a inaczej w korporacji), poziom stresu może być różny, jednak możesz być pewny, że zawsze pojawi się sytuacja, w której praca nie będzie miała z przyjemnością dużo wspólnego. Czy to przez nieprzyjemnego klienta, zbliżający się deadline, czy po prostu mnogość monotonnych i nieciekawych zadań. Szczególnie jeśli chcesz pracować w branży gier komputerowych. Idź w tym kierunku tylko i wyłącznie, gdy jest to Twoja pasja, albo chcesz nabrać doświadczenia, które później wykorzystasz w swoich projektach. Gamedev to bardzo często nadgodziny, które nie są dodatkowo płatne. Sam nie pracowałem nigdy w firmie, która tworzy gry komputerowe, ale na podstawie rozmów z wieloma kolegami, którzy mają taką przeszłość w branży, zawsze pojawiał się temat nieodpłatnych nadgodzin. Nie nastawiaj się, że wszędzie tak jest, bo pewnie istnieją i tutaj przyjemniejsze firmy, ale na pewno jest to zjawisko występujące często. Jak to wygląda w branżach "pozagrowych"? Często obserwowanym schematem jest rozluźnienie na początku projektu. Następnie zostają wprowadzane zmiany do pierwotnych założeń (problematyczny klient, który zmienia zdanie, albo nie zdawał sobie sprawy z tego, czego chce rozwiązaniem tego 17 / 147

18 problemu może być AGILE, o którym trochę później), pojawia się jakiś problem z wybraną przez nas technologią (okazuje się, że coś nie jest możliwe do zaimplementowania i należy sporo przebudować, przez co wymagane jest parę tygodni pracy których nie mamy) i pojawiają się problemy. Teraz należy mieć nadzieję, że mamy dobrą kadrę zarządzającą, która rozwiąże problem w inny sposób niż zarządzenie nadgodzin dla zespołu. Nie zawsze mamy na to wpływ, więc warto sobie uświadomić, że nie zawsze jest różowo. Trzeba jednak przyznać, że ze względu na częste podbieranie sobie pracowników przez różne firmy, to zazwyczaj o pracownika w tej branży dobrze się dba. Nie jest to "łatwa praca w biurze", ale jeśli wykażesz, że jesteś coś wart i konsekwentnie się rozwijasz, to bardzo prawdopodobne, że zostaniesz doceniony MUSISZ się ciągle rozwijać i śledzić nowości Ten punkt to dla jednych ogromna zaleta, dla innych: największa wada. Jeśli jest to dla Ciebie wadą, to warto się zastanowić, czy nie chcemy pracować w branży, w której nie pojawia się aż tyle nowości, jak w przypadku programowania. W 18 / 147

19 wielu dziedzinach stały rozwój jest niezbędny, ale postęp technologiczny jest tutaj ogromny. Dlaczego jest to zaleta? Istnieje grupa osób, dla których ciągły rozwój technologiczny i interesowanie się swoim konikiem jest zarazem hobby i pasją. Taka osoba męczy się w monotonnej pracy. Wystarczy trochę poszukać i znaleźć np. jakiś newsletter (w przypadku programisty android Android Weekly jest świetnym źródłem informacji), który kumuluje nowości z danej branży. Nie trzeba czytać wszystkiego od deski do deski, ale sporadyczne przeczytanie ciekawego artykułu, czy napisanie prostego programu to cenne doświadczenie. Ważna jest tutaj regularność, a nie intensywność. Lepiej co tydzień poświęcić godzinę, dwie, a nie cały weekend co dwa miesiące. Dla innych to wada. Nie mają ochoty ciągle się uczyć (albo przynajmniej nie tak intensywnie) i szukają czegoś, co mogą robić zawodowo za rozsądną stawkę, a resztę czasu chcą poświęcać innemu hobby, albo rodzinie. Oczywiście da się to pogodzić. Nie trzeba poświęcać wszystkiego i żyć tylko programowaniem: ważna jest ciekawość świata technologicznego, w którym się na co dzień poruszamy. Jeśli nie jest to rzecz, którą lubisz/potrafisz regularnie robić, to powinna zapalić się u Ciebie czerwona lampka. 19 / 147

20 Osoby, które posiadają telefon z androidem (właściwie to dla wszystkich właścicieli smartfonów) pewnie pamiętają telefony z roku 2010 i jak bardzo różnią się one od tych z lat to cała epoka. Osoba, która bez problemu dostała pracę jako android developer w roku 2010 i od tego czasu nic się nie rozwijała, w roku 2015 miałaby z tym problemy. By się utrzymać u najlepszych klientów/dostać awans w pracy, należy być na bieżąco z technologią Dlaczego w takim razie warto zostać programistą? Największy plus jaki widzę, to łatwość dostępnych materiałów do nauki. Problemem może być to, że jest ich aż za dużo (sporo teorii i praktycznych projektów z otwartym kodem źródłowym mamy na wyciągnięcie ręki) i łatwo wpaść w spiralę uczenia się nie tego, co jest nam potrzebne (o tym jak i z czego się uczyć w dalszej części). Trudno mi sobie wyobrazić branżę, w której tak łatwo możemy stworzyć coś tak solidnego do CV, jak w przypadku działki programisty. Nie potrzebujesz żadnych drogich maszyn, licencji, ani Oczywiście żadnego istnieją specjalistycznego płatne środowiska 20 / 147 oprogramowania. programistyczne i

21 specjalistyczne narzędzia, ale tym co jest dostępne za darmo można zrobić TAK DUŻO, jak w żadnej innej branży. Nie potrzebujemy klienta, nie potrzebujemy żadnych materiałów. Najprostszy komputer, trochę prądu i internet (chociaż można i bez internetu) i jesteśmy wyposażeni we wszystko co potrzebujemy, by się rozwijać. No i co najważniejsze... trzeba mieć chęci. Fajni ludzie. Serio. Jeśli jesteś osobą, której ta praca pasuje, to znajdziesz tutaj masę ciekawych i wartościowych ludzi. Z moich obserwacji wynika, że wśród ludzi, którzy zajmują się programowaniem jest wyjątkowo duży odsetek ludzi z wszelkimi pasjami i ambicjami życiowymi. Może właśnie dlatego, że jest to zawód dla osób ciekawych świata i chcących się rozwijać. Przekłada się to często na inne dziedziny. Mój główny powód: ogrom możliwości usamodzielnienia się. Po paru latach doświadczenia i pracy nad sobą, zaczyna otwierać się przed Tobą sporo dróg, o które trudno w innych zawodach. Praca zdalna dla bogatego klienta (mieszkając w kraju, gdzie koszty życia są tanie), czy stosunkowo łatwe tworzenie własnych produktów (nie ma ogromnych kosztów materialnych, jak w innych branżach). Przy okazji niskie ryzyko zawodowe. Jakaś odpowiedzialność jest, ale nie zabijemy kogoś tak łatwo, jak lekarz i nie wsadzimy kogoś tak szybko do 21 / 147

22 więzienia lub narazimy na karę, jak prawnik, czy doradca podatkowy. Chociaż jak się postarasz, to możesz sporo na świecie namieszać - i to jest właśnie fajne! 22 / 147

23 6. Do rzeczy: co powinieneś potrafić, by zacząć pracę jako programista? Jak i gdzie się tego nauczyć omówimy później. O rzeczach, które opiszę w tym rozdziale można pomyśleć jak o mnożniku. Zawsze będziesz w stanie wykonać pewną ilość pracy, nauczyć się pewnej ilości nowinek z Twoją średnią prędkością pomnożoną przez A, B i C (kiedyś wyczytałem, że mądrze nazywać to dźwignią, więc również postanowiłem się tym słowem powymądrzać). Prędkość z jaką się uczysz, czyli wdrażasz w projekt, przyswajasz sobie technologie wykorzystane w projekcie, czy robisz research technologii, które warto tym razem zastosować 23 / 147

24 zależy od paru punktów/dźwigni. Aktualnie wymienię te punkty i opiszę dlaczego są one ważne. Co konkretnie możesz zrobić, by wskoczyć oczko wyżej w danym punkcie wyczytasz w rozdziale Praktyczna ścieżka rozwoju same konkrety. Zaczynamy Język Angielski Jeśli chcesz robić coś więcej od tworzenia stron, wizytówek w html-u i instalowanie wordpresów, to jest to mus. Jako programista często pracujesz z dokumentacją. Ta dokumentacja w większości przypadków jest po angielsku. Najwięcej materiałów w sieci (w książkach w sumie też. Co więcej: często czytałem w recenzjach, że do polskich tłumaczeń wkradają się błędy rzeczowe) jest po angielsku, czy to artykuły, filmiki na YouTube, albo materiały video na innych stronach (Lynda.com, Udemy, CodeCademy etc.). Jest to zdecydowanie największa dźwignia, nad którą należy u pracy/nauki siebie radzisz popracować. sobie Jeśli wolniej podczas niż inni, codziennej to bardzo prawdopodobne, że przyczyną jest słaba znajomość języka 24 / 147

25 angielskiego. Tak jak w przypadku programowania większość czasu projektu to czytanie kodu, a nie jego pisanie (dotyczy oczywiście projektów, która trwają więcej niż prace zaliczeniowe na 2 wieczory) i mniej czytelny kod jest głównym powodem wolnych postępów w projekcie, tak samo wolne postępy w rozwoju młodego programisty są często spowodowane słabą znajomością angielskiego. Oprócz szybszej i efektywniejszej nauki pojawiają się inne zalety: większa wartość na rynku pracy, lepsza współpraca w przypadku pracy zdalnej (gdy każdy pracuje w innym miejscu na ziemi, to cała komunikacja odbywa się po angielsku), możliwość pisania bloga, który dobrze wygląda w CV Umiejętność szukania informacji Druga dźwignia na liście bardzo ściśle powiązana z poprzednim punktem. O ile w przypadku szukania rozwiązań zadań typowo szkolnych/uczelnianych szukanie w języku polskim może wystarczyć, to większość błędów, które wkleisz do wyszukiwarki, dadzą wyniki w języku angielskim. 25 / 147

26 Wiedzieć jak (i czego) szukać, to w przypadku wielu zadań już połowa sukcesu. Umiejętność odpowiedniego szukania to w 90% doświadczenie (które nabywa się wraz z udziałem w projektach, które trwają dłużej niż tydzień, czy miesiąc), a 10% to proste wskazówki. Postaram się to przybliżyć w rozdziale Praktyczna ścieżka rozwoju. same konkrety na paru praktycznych przykładach Rozbijanie zadań na małe części i skupienie się na jednej rzeczy jednocześnie. W różnych poradnikach na temat efektywnej pracy/nauki pojawia się czasami pewne pojęcie: monkey mind. Mowa o metaforycznej małpce, która siedzi w naszej głowie i domaga się natychmiastowej gratyfikacji. Skutkiem ulegania takiej małpce jest znana nam wszystkim prokrastynacja. 26 / 147

27 Należy przyjąć za fakt, że nie da się takiej małpy z umysłu wygonić. Można jedynie wyrobić sobie nawyki, które ułatwią nam negocjacje z nią. Takim nawykiem jest rozbijanie większych zadań na wiele małych, które można wykonać krok po kroku. Mentalny obraz dużego zadania może bardzo zniechęcić. Jednak jeśli skupimy się zawsze tylko na jednym kroku z wielu małych, to łatwiej nam przekonać nasz małpi umysł, by jednak wykonał następny produktywny krok, a nie udał się na beztroskie przeglądanie Reddita, czy przekopiowane z Reddita śmieszne obrazki na Wykop.pl Napisać (nawet bardzo mały) projekt od początku do końca Bardzo złą praktyką nauki programowania jest ślepe przeklepywanie tego, co jest pokazane w jakimś tutorialu. Powinieneś potrafić brnąć do przodu w projekcie przez stosowanie tak zwanego just in time learning, czyli uczenia się czegoś dopiero w momencie gdy tego faktycznie potrzebujesz. Najlepszym sposobem, by zacząć tak się uczyć jest napisanie nawet bardzo prostego projektu od początku do końca. Załóż sobie konto na Githubie (protip: nie zakładaj konta z Twoim 27 / 147

28 nazwiskiem, czy jakimś oficjalnym nickiem: będziesz się czuł bardziej komfortowo wrzucając pierwszy kod) i zaczynaj i kończ małe (może czasem średnie) projekty. Dodatkowa korzyść: jeśli jakiś projekt okaże się w miarę fajny, to od razu masz coś do CV. Szczególnie w przypadku braku pierwszego doświadczenia zawodowego Potrafić skonfigurować środowisko pod projekt Na tym spędzisz pierwszy dzień (ewentualnie nawet parę 28 / 147

29 dni) w pierwszej pracy. i bardzo prawdopodobnie też w każdej kolejnej. O ile w przypadku małych projektów pisanych na zaliczenie ich konfiguracja przeważnie jest prosta, to w przypadku czegoś bardziej złożonego (nad czym zespół osób pracuje już parę lat) konfiguracja środowiska nie jest taka prosta. Bardzo często, by zbudować projekt potrzebne jest zapewnienie Ci odpowiednich praw dostępu. Jest to normalne. Nie przejmuj się, w firmie będzie im zależało na tym, byś sprawnie mógł zacząć pracować. Ktoś Ci pomoże, ewentualnie będziesz musiał o to parę razy poprosić. Myślę również, że początkowa konfiguracja środowiska jest jednym z powodów, przez które wiele początkujących zniechęca się na starcie: Jak to? 1-3h ustawiałem wszystko, by wypisać w konsoli dwa słowa albo wyświetlić puste okienko?. 29 / 147

30 Dlatego warto to poćwiczyć na paru projektach z np. Githuba. Z każdym samodzielnie skonfigurowanym środowiskiem do projektu coraz lepiej będziesz łapał, jak do tego podchodzić. Zanim stanie się to intuicyjne będziesz musiał przejść przez wiele godzin frustracji. Ważne by pamiętać, że nie jesteś z tym sam. Często wiąże się to z instalacją jakiegoś lokalnego serwera, założeniem lokalnej bazy danych, by mieć jakieś środowisko testowe (nie zawsze mamy serwer testowy) itp. Poradzisz sobie Podstawy baz zapisywanie i czytanie webowych, działania danych (generalnie danych), technologii sieci, programowania obiektowego, pisania testów i web serwisów. Podkreślam, że chodzi o solidne podstawy, a nie wiedzę ekspercką. Zdziwisz się ile rzeczy uczyłeś się z obawy, że będą od Ciebie wymagane, a nigdy nie będą Ci potrzebne. Dlatego ważne jest pamiętanie o just in time learning, czyli zagłębianie 30 / 147

31 wiedzy wtedy, gdy jest nam faktycznie potrzebna. W przypadku baz danych powinieneś potrafić założyć nową tabelę, wykonać zapytania, by wyciągnąć z niej dane/dodać nowe dane. Na detale przyjdzie czas, jeśli będziesz na co dzień pracował z bazą danych. Z mojego doświadczenia wynika, że niepotrzebnie bałem się mojej mocno podstawowej wiedzy na temat baz danych: okazało się, że musiałem jedynie wykonywać proste zapytania, by sprawdzić jakieś dane (dodatkowo istnieją współcześnie narzędzia, które znacznie to ułatwiają i usprawniają Twoją pracę), a ważniejsza okazała się sprawna komunikacja z osobami, które zajmowały się webserwisami. W praktycznej dalszej części książki przytoczę parę praktycznych rzeczy, które możesz zrobić, by nabrać pewności siebie i sprawdzić czego musisz się douczyć. Dlaczego technologie webowe? Nawet jeśli całe dni grzebiesz w serwerze i tworzysz zaplecze (backend), to umiejętność stworzenia sobie lekkiego webowego frontendu jest ważna. Tym bardziej, że jest to proste: mały nakład pracy, by to ogarnąć, a korzyści z tego są spore. Działanie sieci? Na początek doczytanie o HTTP/HTTPS, FTP albo POP wystarczy. Ważne, by podejść do tego od strony programistycznej 31 / 147 i wykorzystać któryś z

32 protokołów w prostej aplikacji (język programowania nie ma znaczenia: znasz głównie Ruby -> zrób w Ruby). Programowanie obiektowe: tutaj, tak jak wszędzie, większość przyjdzie z doświadczeniem. Na początek warto byś znał podstawowe pojęcia takie jak: obiekt, klasa, klasa abstrakcyjna, interface, dziedziczenie, kompozycja, metoda, wzorzec projektowy (nie bój się o nie pytać Jakie wzorce stosujecie w projekcie? Chciałbym o nich doczytać., to dobre pytanie na pierwsze dni w pracy). Web serwisy. Jeśli nigdy ich nie stosowałeś, to warto zacząć od zainteresowania się czym jest REST. Pisanie testów jednostkowych. Warto wiedzieć po co je się pisze i jakie technologie są popularne w Twoim ulubionym języku programowania. Np. w przypadku Javy warto zainteresować się czym jest JUnit i Mockito. Jeśli dopiero 32 / 147

33 zaczynasz, to niepotrzebnie się nimi zniechęcisz. Na razie wystarczy wiedzieć, że takie coś istnieje i jest przydatne w przypadku projektów, które są rozwijane przez dłuższy czas. Im dłużej ma być rozwijany projekt, tym bardziej wartościowe są testy jednostkowe. Kiedy je pisać i ile ich pisać to temat na inną książkę. Chcę w tej książce wprowadzić juniora i pokazać mu ogólny obraz pracy programisty. MÓWIĘ DO CIEBIE doświadczony programisto, który czyta tego pdf-a, zamiast zająć się swoją pracą (wiem, wiem: prokrastynacja to suka) Parsowanie danych: json i xml Dane, z którymi będziesz pracował, często są w jednym z tych dwóch formatów: json, xml (istnieją też inne bardziej zaawansowane rzeczy jak np. protobuf, ale nie powinieneś sobie nimi na początku zawracać głowy). Przetworzenie danych, by móc z nimi pracować z poziomu kodu to popularne parsowanie nie jestem pewny, czy takie słowo istnieje w języku polskim, ale powinieneś je znać: jest powszechnie stosowane w codziennej pracy programistów. Początkowo wydaje się to dziwnie trudne, ale z czasem 33 / 147

34 staje się to banalną rutyną Praca z narzędziem kontroli wersji: np. git. Powinieneś się zaprzyjaźnić z gitem. Jest on niezbędny do pracy zespołowej. Jeśli zaczniesz go stosować, to nigdy nie będziesz chciał pracować bez niego. Serio. Jeśli zawsze to odwlekałeś, to odstaw wszystko inne i pobierz sobie jakieś narzędzie wizualne (np. SourceTree). NIE MUSISZ BYĆ MISTRZEM STOSOWANIA GITA W KONSOLI. Sam znam tylko podstawy konsoli gita i na co dzień stosuję narzędzia wizualne. Jeśli jestem zmuszony do konsoli, to na bieżąco googlam to, co potrzebuję. Powinieneś wiedzieć co to: branch, checkout, clone, merg mergowanie, commit, push, pull, GitFlow. Całość rozjaśnię na przykładzie w praktycznej części książki Praktyczna ścieżka rozwoju. same konkrety na razie tylko wypisuję co mniej więcej powinieneś potrafić. Przy okazji ten rozdział to dobre miejsce na powrót i późniejsze odhaczanie punktów, o których powinieneś trochę doczytać. 34 / 147

35 6.9. Usprawnianie pracy w IDE, czy innym środowisku. Co jakiś czas napotkasz coś, co robisz regularnie i zajmuje to dziwnie dużo czasu. Np. zmiana nazwy metody/funkcji. IDE ma wbudowane różne ułatwienia, które usprawniają Twoją pracę. Powszechną pułapką jest próba wyuczenia się tych wszystkich ułatwień jednocześnie. Znowu pojawia się just in time learning : naucz się jednej praktycznej sztuczki (np. przeskok do następnego erroru albo usunięcie danej linii kodu skrótem klawiszowym) i postaraj się ją stosować. Zapisz sobie skrót klawiszowy na karteczkę i przyklej ją pod monitor. Jeśli po paru dniach uznasz ten skrót za bezużyteczny, to olej go. Widocznie nie jest Ci aktualnie potrzebny. Po paru miesiącach uzbiera Ci się cały arsenał sztuczek, które faktycznie usprawniają Twoją pracę. Czasami jakiś kolega szepnie coś, co uznasz za przydatne. Zero pamięciówki. Przydatne rzeczy same zaczynają wchodzić do głowy, gdy widzisz, że faktycznie ułatwiają codzienną pracę. Komentarz mojego kolegi Marka (Senior Developera) odnośnie sprawnej pracy w IDE: Sam miałem pytanie o to w jakim IDE pracuję i jakie znam z 35 / 147

36 niego skróty. Jak miałem rozmowę do projektu dla klienta w Warszawie. Może to wydawać się głupie, ale jednak coś tam sprawdza. 36 / 147

37 7. Szkoła, studia i odwieczne pytanie o matematykę Uwaga! W żadnym wypadku nie bierzcie tego rozdziału jako prawdę objawioną. Traktujcie to jako jedną z wielu opinii, które mogą Wam pomóc podjąć decyzję. Jestem typem człowieka, który preferuje uczyć się samodzielnie, dlatego też mam opinie jakie mam i nie jestem fanem formalnych studiów. Chciałbym tutaj opisać jakie decyzje związane ze studiami podjąłem, dlaczego postąpiłem tak, a nie inaczej, aby następnie podsumować wnioski Zaczniemy od najczęstszego pytania co do matematyki, o którą wiecznie pytacie. Nie. Nie musiałeś być dobry w szkole z matematyki, by zostać programistą. Jeśli potrzebujesz zastosować coś z matematyki, to zawsze możesz się tego douczyć w momencie gdy tego potrzebujesz. I nie przejmuj się jeśli nauczyciel matematyki mówi jak chcesz być informatykiem/programistą, to MUSISZ być dobry z 37 / 147

38 matematyki. Chcesz zostać murarzem, to pytaj murarza jak zostać murarzem. Chcesz zostać programistą, to pytaj programisty. Nie nauczyciela matematyki. Nie przejmuj się jego opinią. Nie trać czasu na bezproduktywną dyskusję. Warto nauczyć się ignorować niektórych ludzi i czasami przytaknąć dla świętego spokoju. Później rób dalej swoje. Na tym można zakończyć temat matematyki. Serio. Ewentualnie warto wiedzieć, że musisz stosować więcej matematyki, jeśli chcesz pisać np. silnik do tworzenia gier. Rzeczy związane z fizyką itp. Jednak w wielu przypadkach nie jest ona dla programisty aż tak istotna. To co nauczyłeś się w szkole podstawowej i gimnazjum (czy tam w 8 klasach szkoły podstawowej, jeśli jesteś z rocznika starszego niż 86) w większości przypadków wystarczy aż nadto. Liczy się umiejętność logicznego myślenia, którą ćwiczysz z każdym kolejnym projektem i każdym rozwiązanym problemem Jak podchodziłem do kwestii szkoły/studiów U mnie ta kwestia była dosyć specyficzna. Koniec okresu gimnazjum/początek liceum zacząłem tworzyć strony www i zarabiać dzięki temu pierwsze pieniądze. Myślałem o studiach jak o miejscu, które pomoże mi w przyszłości znaleźć sensowną 38 / 147

39 pracę. Skoro sam organizuję sobie pracę (w czasach LO miałem pierwszą mikro-firmę pod skrzydłami Akademickich Inkubatorów Przedsiębiorczości), to dlaczego mam w takim razie studiować? Takie było moje myślenie jako licealista. Miałem zamiar nie iść na studia, ale za namową rodziców poszedłem na kompromis i zdecydowałem się skończyć inżyniera informatyki zaocznie. Z czasem żałuję decyzji kończenia studiów. Poznałem parę ciekawych ludzi (jedyny plus), ale po czasie uważam ilość poświęconego czasu (i pieniędzy) za zmarnowany. Gdybym dzisiaj ponownie miał 19 lat, to prawdopodobnie poszedłbym na rok (albo 1 semestr) dziennych studiów, by 39 / 147

40 zobaczyć czy to coś dla mnie i następnie po doświadczeniu tego pierwszego semestru bym podjął decyzję. Najprawdopodobniej bym zrezygnował z uczelni i spróbował załapać się gdzieś na praktyki, by podpatrzeć coś od osób, które faktycznie zajmują się tym czego chcę się nauczyć. Jednak jest to opinia z punktu widzenia osoby, która w dłuższej perspektywie chce prowadzić własną firmę, a nie chce pracować większość życia na etacie. Studia mają swoje zalety i w wielu przypadkach warto na nie iść Dlaczego moim zdaniem warto iść na studia (informatyczne) Rówieśnicy o podobnych zainteresowaniach. Nauka przychodzi łatwiej, jeśli otaczasz się osobami, które dążą do tego samego celu. Łatwo przez studia poznać wiele ciekawych osób, które mogą Cię zainspirować do tego, co fajnego można w życiu robić. Dlatego warto wybrać uczelnię, na którą większość osób chce się dostać, a nie jest to uczelnia na którą się po prostu dostali, bo na innych ich nie chcieli. Unikałbym też uczelni, na którą dużo osób chodzi i nie do końca wie dlaczego nie wiem co robić ze swoim życiem, więc na razie robię studia. :D Czyli: jeśli już studia, to jakaś konkretna uczelnia (na 40 / 147

41 której możesz poznać ambitnych i fajnych ludzi), a nie kolejna pseudo szkoła kręcąca biznes na nieporadnych dzieciach, których rodzice płacą za czesne, by ich syn/córka miały za parę lat papierek magistra. Lubisz pracę na etacie. To, że ja nie przepadam za dłuższą pracą na bezpiecznym etacie wcale nie znaczy, że etat jest zły. Jeśli jesteś typem człowieka, który lubi regularne godziny pracy, większe bezpieczeństwo i dobrze się czuje w świecie korporacyjnym, to studia mogą być bardzo przydatne. Jest wiele firm, w których formalnym wymogiem awansu jest wyższe wykształcenie. Oczywiście absolwenci studiów informatycznych zakładają firmy i mają się bardzo dobrze. Nie przejmujcie się moją subiektywną opinią, że studia są głównie dla etatowców. Jeśli zadbasz o to, by tytuł z uczelni szedł w parze z praktycznymi umiejętnościami (nabytymi w projektach z uczelni, czy projektach hobbistycznych), to wybierasz bezpieczną i dla wielu osób właściwą drogę. Nie daj sobie wmówić, że rzucenie studiów i samodzielna nauka w IT jest zawsze lepszym rozwiązaniem. Gdybyśmy wszyscy działali i myśleli tak samo, to ten świat byłby strasznie nudny. Potrzebujesz bodźca, który pomoże Ci się zmobilizować do nauki. Nawet jeśli masz naturę samouka, to 41 / 147

42 wiesz, że nie zawsze łatwo się zmobilizować, by coś zrobić. Dla wielu osób zbliżające się egzaminy to niezbędna motywacja. Potrzeba regularnej nauki do egzaminów może też Ci pomóc w wyrobieniu sobie dobrych nawyków. Studia, to nie szkoła zawodowa. Błędnie jest zakładać, że studia informatyczne mają Cię głównie przygotować do wejścia na rynek pracy. Jeśli chcesz się po prostu rozwinąć jako człowiek i nie zależy Ci na szybkim starcie w życie zawodowe, to studia mogą być świetnym okresem w życiu. Każdy ma inne priorytety i inaczej ukierunkowane ambicje należy o tym pamiętać zanim zaczniemy kogoś pouczać Dlaczego moim zdaniem nie warto iść na studia (informatyczne) Wiele rzeczy nie przyda Ci się w przyszłości. Jeśli jesteś osobą, która jest nastawiona na wiedzę praktyczną i szybko chce zacząć pracę w zawodzie, to studia mogą nie być dobrym wyborem. O ile część materiału może się w jakimś stopniu przydać, to większość materiału wyda Ci się pewnie 42 / 147

43 zbędna. Wyższa matematyka, elektrotechnika i wiele innych przedmiotów. Będzie to zaletą jeśli nastawiony jesteś na generalne rozszerzenie horyzontów, ale jeśli powoli wiesz co chcesz w życiu robić, to będzie to spore obciążenie i będziesz miał wrażenie, że lepiej spożytkowałbyś swój czas realizując się w jakimś projekcie pobocznym. Takie projekty poboczne, to kolejny powód: koszt alternatywny, którego nie widać. Kosztem alternatywnym jest wiele projektów, które nigdy nie powstaną przez poświęcony czas na studia. Nie nauczysz się wielu rzeczy, których mógłbyś się nauczyć przez inaczej zagospodarowany czas. Chcesz w przyszłości prowadzić swój biznes. Osoby, które widzą siebie w przyszłości jako przedsiębiorcę napotkają wiele frustracji na studiach. Możliwość praktyk, czy pracy (nawet za bardzo niską stawkę) w średniej lub dużej firmie może się okazać dla Ciebie dużo bardziej wartościowa. Nauczysz się nie tylko wiele spraw czysto technicznych, ale również jak wygląda sprawna (lub wręcz przeciwnie) organizacja pracy. Nie potrzebujesz specjalistycznego sprzętu. Mało jest takich kierunków programowanie), samodzielnie i jak gdzie nie informatyka możesz tak potrzebujesz 43 / 147 (a w wiele do szczególności nauczyć tego się żadnego

44 specjalistycznego sprzętu. Inaczej jak w przypadku lekarza, który nie może sobie (legalnie) ot tak pokroić zwłoki i zobaczyć jak wygląda człowiek od środka Krótko o belfrach Zdaję sobie sprawę, że można odnieść wrażenie, że mam jakiś uraz do nauczycieli i dlatego wyżej stawiam samodzielną naukę od tradycyjnej szkoły/uczelni. Nauczyciel, który czyta moje wypociny może poczuć się ciut urażony. Dlatego podkreślam, że uważam aktualny system nauczania za beznadziejny. Sami nauczyciele są w wielu przypadkach bardzo w porządku. Mają oni często związane ręce przez system, którego muszą się trzymać. Nauczyciele, których wspominam najlepiej, to ci, którzy realizowali tylko niezbędne minimum oficjalnego programu, a później uczyli tego, co faktycznie było ciekawe (i czasami nawet przydatne!). Po oficjalnych godzinach szkolnych nauczyciel bardzo często okazuje się znacznie sympatyczniejszy. Tłumaczy to też popularność korepetycji. 44 / 147

45 8. CV, rozmowy kwalifikacyjne i sam proces szukania pracy Czas na omówienie tego co warto mieć w CV, czego spodziewać się na rozmowach kwalifikacyjnych (jak do nich podchodzić) i wspomnieć na co warto zwrócić uwagę w samym procesie szukania pracy Co zawierało moje pierwsze CV przy pierwszej pracy programisty i dlaczego było do bani Co zawierało moje CV: Sporo tekstu o tym, że byłem freelancerem, który tworzył strony www i pozycjonował je w wyszukiwarkach. Listę stron www, które wykonałem. Cześć z nich nie była już dostępna w sieci, a te, które były, nie były za ambitne od strony technicznej. Wymieniłem miejsca gdzie moje projekty/strony zostały wymienione (np. Dziennik Zachodni, czy różne strony www) i komu strony zostały sprzedane. 45 / 147

46 Wymieniłem szczegóły na temat ruchu na stronach www, które stworzyłem. Umiejętności, które wymieniłem były bardzo ogólne: potrafię tworzyć strony www z wykorzystaniem html/css oraz php/mysql, programowanie obiektowe w javie i C# (to w Javie da się programować nieobiektowo? :D), znajomość baz danych i oczywiście: szybkie uczenie się (idealny punkt do wypisania, jeśli nie mamy się czym pochwalić). języki obce, wykształcenie (standard nie ma czego tu omawiać). Co w tym wszystkim było do bani? Na tyle dużo, że mogę to ładnie wypunktować. :) Gdy z jakimś CV aplikujesz na dane stanowisko, które wymaga x, y i z, to co w nim wypisujesz powinno być powiązane z tym stanowiskiem po cholerę wypisywałem jakieś strony www, jeśli aplikowałem na stanowisko Java Developera sam się sobie dziwię. Dużo lepiej by wglądał link do jakiegoś webserwisu, który napisało się w ramach nauki. Wspomniałem już o nieistotnych informacjach typu ile odwiedzin miały jakieś moje strony www (co byłoby w 46 / 147

47 sumie fajną informacją, ale gdybym ubiegał się na stanowisko w dziale marketingu) ważniejsza jest przejrzystość, którą przez takie zbędne informacje traciłem. Jakieś szczegóły zawsze można dołączyć na osobnym dokumencie lub dopowiedzieć w trakcie rozmowy. Samo CV powinno być krótkie i na temat. Było widać, że nie miałem za dużo rzeczy do wypisania (rzeczy związanych ze stanowiskiem, na które aplikowałem) i niepotrzebnie zaśmiecałem CV zbędnymi informacjami. Zamiast lać wodę o umiejętnościach, powinienem wypisać technologie, które znam dobrze, średnio i słabo. Krótko i na temat. Co powinienem zrobić mając mało doświadczenia, które mógłbym wpisać? Wypisać krótko parę technologi, których się uczyłem. Dać jakiś link do projektów, które wykonałem w ramach nauki i zaznaczyć w jakim kierunku planuję się rozwijać. Typowe CV studenta świeżaka zawiera wszystkie technologie, które ten student miał ma studiach, albo o których przeczytał wpis na Wikipedii. To, że miałeś laborkę z asemblera nie oznacza, że wpisujesz to w doświadczenie. Często pojawia 47 / 147

48 się tendencja, że im programista jest bardziej doświadczony, tym mniej rzeczy wypisuje w swoim CV Drugie CV jest poprawa, ale mogło być lepiej Z drugim CV poradziłem sobie ciut lepiej: wypisałem krótko gdzie pracowałem i na jakim stanowisku, wypisałem moje główne techniczne skille. Zamiast lać wodę tworzyłem strony www, które odwiedzały 3 osoby dziennie, napisałem Web Development: xhtml, CSS, JavaScript, Servlets/JSP, główne narzędzia/ide z których korzystałem w pracy. Krótko i na temat. Jedyne czego tu brakowało, to brak jakiegoś konta na githubie z projektami do wglądu. Mogłem też podzielić umiejętności techniczne na główne (które znam najlepiej) i to co znam średnio, czy liznąłem dopiero początki. Szczera samoocena wygląda znacznie lepiej od przydługiej listy mądrych słówek. 48 / 147

49 8.3. Jakbym dzisiaj przygotował CV Nie jestem ekspertem od pisania CV i pewnie wiele poradników internetowych będzie radziło tutaj trochę inaczej. Jednak na podstawie moich doświadczeń w aplikowaniu do pracy jako programista i jako przyszły potencjalny pracodawca radziłbym następujące rzeczy: Wypisanie 1-3 głównych technologii (unikamy przydługawej listy typowej dla CV studenta świeżaka). Przygotowanie konta na githubie z solidnie napisanym kodem źródłowy. Nie chodzi tutaj tyle o poziom skomplikowania projektu, co o jakość napisanego kodu. Testy jednostkowe (sensowne testy!) też zawsze dobrze wyglądają. Oprócz firm, w których pracowaliśmy, należy również wymienić stanowisko i krótki opis zakresu obowiązków. Jeśli jakiś projekt, przy którym pracowałeś poza pracą zawodową, nie znajduje się na githubie, to link do np. Google Play, Apple Store, czy strony projektu. Starałbym się pisać na tyle zwięźle, by zmieścić się na 1 stronie A4. Max to 2 strony. Najciekawsze informacje na początku. 49 / 147

50 Filmik dołączony do CV? Gdy aplikowałem do mojej drugiej pracy jako programista, nagrałem krótki filmik (10 minut), gdzie raz po angielsku, raz po niemiecku przedstawiłem szerzej to, co napisałem w CV. W zwykłej czarnej koszulce i jeansach ot luźno omówiłem szerzej moje CV i przy okazji pokazałem, że potrafię mówić w innych językach niż mój ojczysty. Prawie każda osoba, która zadzwoniła, pochwaliła ten pomysł. Warto się przełamać i spróbować czegoś podobnego. Filmik był zwykłym niepublicznym filmem na YT (czyli takim, który można uruchomić tylko mając bezpośredni link nie można go wyszukać w wyszukiwarce) Proces szukania pracy Gdy masz przygotowane CV pod stanowisko, które Cię interesuje (np. Android Developer) zaczyna się zabawa w zbieranie adresów . Postaraj się wygooglać parędziesiąt firm i ofert w Twojej okolicy, które zajmują się programowaniem i wyślij im Twoje CV i informację, że jesteś w trakcie szukania pracy. Nawet jeśli jakaś firma aktualnie nikogo nie szuka, to bardzo prawdopodobne, że znają kogoś, kto akurat 50 / 147

51 poszukuje pracowników i przekażą Twoje CV (o ile jest sensowne). Warto również (na początku) aplikować do firm z miast, w których nie masz zamiaru pracować. Dostaniesz parę telefonów więcej, przejdziesz kolejne rozmowy na Skype i oswoisz się z tym lepiej. Szybko zauważysz, że takie rozmowy są często bardzo podobne i nabierzesz w nich wprawy. Przecież zawsze możesz odmówić osobistego spotkania zawsze to kolejna rozmowa telefoniczna więcej, z której się czegoś nauczyłeś. Przejdźmy do samych rozmów Rozmowy kwalifikacyjne Rozmowy te są bardzo schematyczne. Dlaczego chcesz tam pracować i jak ich znalazłeś: jesteś 51 / 147

52 zainteresowany rozwojem w kierunku x/y i myślisz, że w ich firmie będzie taka możliwość. Co wiesz o tej firmie: warto przeczytać w jakich projektach brała udział firma, do której aplikujecie. Jeśli nie wiecie, to nie ma co ściemniać: wygooglaliście ich ofertę pracy i wysłaliście CV. Tyle. Teraz do istotnych rzeczy: Naucz się wypowiadać na temat projektów przy których pracowałeś. Jakie pojawiły się największe problemy, jakie technologie stosowałeś, wspomnij coś o narzędziach pracy. Zostaniesz zapytany na temat czegoś związanego z jakąś technologią w Twoim CV. Dlatego warto podzielić umiejętności na te, które znamy dobrze i słabo. Jeśli kiepsko orientujesz się w czym, co wymieniłeś jako dobrą znajomość, to szybko się spalisz. Staraj się być szczery i zaciekawiony stanowiskiem pracy. Jeśli czegoś nie wiesz, to przyznaj: nie stosowałem tego, nie mogę nic na temat tego powiedzieć. Jeśli pracodawca/rekruter powie coś więcej o firmie, to bądź ciekawy i zadawaj pytania: pytaj o wszystko co Cię ciekawi w tej firmie (o ile jest to jakoś związane z Twoim 52 / 147

53 stanowiskiem pracy), w końcu nie tylko Ty starasz się o pracę, ale przede wszystkim ONI starają się o dobrego pracownika. Jeśli idziesz na rozmowę osobistą, to nie bój się zapytać wcześniej o dresscode. Zazwyczaj możesz przyjść luźno ubrany, ale warto się doinformować Zbieraj doświadczenie w aplikowaniu i wyciągaj wnioski Im więcej rozmów przejdziesz, tym lepiej. Poznasz swoje braki, które możesz przecież nadrobić. Nikt Ci nie zabroni aplikować do tej samej firmy ponownie za parę miesięcy, czy tam rok. Jest to bardzo dobry test. Zamiast bezcelowo uczyć się czegoś nowego w domu, warto trochę poaplikować do różnych firm, by zobaczyć co nam idzie dobrze, a nad czym należy popracować Zadanie praktyczne Bardzo często dostaniesz do rozwiązania jakieś zadanie praktyczne lub jakiś test. Kolejny argument za tym, by aplikować trochę częściej: te testy są do siebie podobne i po paru razach 53 / 147

54 będziesz wiedział czego się spodziewać. Trochę o moich testach praktycznych. Raz był to przydługawy test z pytaniami zamkniętymi i otwartymi pracodawca oszczędza wtedy czas, bo nie musi poświęcać czasu pracownika na długą rozmowę sprawdzającą kandydata. Często nie liczyła się idealna odpowiedź, tylko fakt, że potrafisz kombinować i rozpracować dany problem. Warto porobić sobie parę testów praktycznych na Codility.com. Ten test nie jest w żadnym wypadku odzwierciedleniem naszej wiedzy: często albo potrafisz rozwiązać problem i masz 100%, albo nie potrafisz ruszyć z miejsca i masz 0% trochę sprowadza się to do szczęścia, ale jednak część pracodawców wysyła taki test. W ramach praktyki można wykonać tam za darmo parę testów. Część testów jest bardzo podobnych do zadań z również polecam tam zerkać i ćwiczyć szare komórki. W innym przypadku dostałem praktyczne zadanie. Dostałem maila o 9 rano i miałem czas jakoś do Dostałem link do webserwisu, miałem pobrać dane i wyświetlić je w aplikacji na telefonie. Dodatkowo miałem zaimplementować część danych na Google Maps Api. 54 / 147

55 WAŻNE: nie liczyło się aż tak bardzo, czy wykonasz 100% zadań, tylko jak je wykonasz. Dużo lepiej jest zrobić mniej, ale lepszej jakości, przemyślanego kodu, niż na siłę próbować się zmieścić w czasie ze wszystkim byle działało. Czasami będziesz musiał pobrać sobie jakiś projekt do modyfikacji, więc ważna jest umiejętność pracy z gitem. Znowu ten git jeśli masz tylko jedną rzecz zapamiętać z tej książki, to jest to: NAUCZ SIĘ STOSOWAĆ GITA. :D To niesamowite jak bardzo usprawnia on codzienną pracę. Już chyba wolałbym zrezygnować z kawy niż z gita. Zdecydowanie narzędzie numer jeden Przydatne portale Jeśli nie słyszałeś o portalach typu Goldenline.pl, Xing.com i LinkedIn.com, to powinieneś się nimi zainteresować. Dlaczego? Gdy masz na nich konto i w profilu informację o tym, że szukasz pracy jako programista, to ludzie z działu HR sami Cię znajdą. Już wielokrotnie się z tym spotkałem, że za ściągnięcie do pracy programisty dostaje się od 1000zł (w małych firmach), do 5000 euro (taka nagroda była za znalezienie programisty do firmy, w której pracowałem) i więcej. Poświęć godzinkę i załóż tam konto. Przyda się podczas 55 / 147

56 szukania pracy i późniejszej ewentualnej zmiany Podsumowanie Podsumujmy krótko ten rozdział: Przygotuj krótkie i zgrabne CV z radami, które wymieniłem. Jeśli chcesz się wyróżnić z szarej masy, to nagraj krótki filmik, w którym szerzej omawiasz swoje CV. Załóż konto na githubie, na które wrzucisz 2-3 w miarę czysto napisane projekty (jakość, nie ilość: lepiej wrzuć jeden, zamiast parę śmieciowych). Nie bój się aplikować. Aplikuj masowo i nabierz doświadczenia w rozmowach kwalifikacyjnych i testach praktycznych. Dla wielu ten rozdział, to może być odkrywanie Ameryki, ale zadziwia mnie jak dużo osób sobie z tym nie radzi 56 / 147

57 9. Dzień, organizacja i role w pracy. Agile, Scrum i inne mądre słówka. Praca programisty nie jest tania. Dlatego powstają różne procesy/metody pracy, by jego czas był wykorzystany w miarę efektywnie. Gdy pierwszy raz słyszałem o efektywnej organizacji pracy zespołu programistów, pomyślałem, że chodzi o to, by pracowali długo lub bardzo intensywnie (a najlepiej jedno i drugie). Jednak takie podejście prowadzi tylko do wypalenia i na dłuższą metę się nie sprawdza. Współczesna organizacja pracy w firmach IT polega głównie na tym, by programiści pracowali nad tym co ma najwyższy priorytet. Podejście takie skupia się na tym czego lepiej nie robić, niż to by robić możliwie dużo w krótkim czasie. By taki proces mógł działać, potrzebne są różne role w zespole. Postaram się je tutaj opisać, ale skupię głównie na roli programisty. 57 / 147

58 9.1. Agile, Scrum i inne mądre słówka To nie jest podręcznik na temat Scrumu.Nie jestem w nim ekspertem. Chciałbym tutaj tylko przybliżyć jak ja zrozumiałem tę metodę pracy: jak pracowałem według niej prawie 3 lata na etacie w różnych zespołach, jak stosuję agile w moim codziennym życiu: m. in. wykorzystałem scrum podczas pisania pracy inżynierskiej, czy podczas nauki do zdania certyfikatu oraclowego z Javy, jak zmieniło to moje podejście do własnych projektów i pracy na własną rękę. Big picture Obraz mówi więcej niż tysiąc słów. Dlatego wstawię dwa obrazki (hmm to tak jakbym napisał 2 tysiące słów: czas na przerwę w pisaniu :D). 58 / 147

59 Nie Agile 59 / 147

60 Agile Bardzo to uprościłem, ale na potrzeby tej książki nie będziesz więcej potrzebował. 60 / 147

61 Ważne byś odróżniał, że w jednej metodyce pracy planowany był cały projekt według sztywnej specyfikacji i osadzono deadline sztywny termin kiedy projekt ma być skończony. W drugim sposobie staramy się nakreślić jakie cele dla klienta ma spełniać produkt i wstępnie w krótkich iteracjach budujemy to, co w danym momencie uważamy za sensowne. Następnie bierzemy to, co zbudowaliśmy, konfrontujemy to z klientem i decydujemy, czy wprowadzamy zmiany, czy robimy dalej w tym samym kierunku Dlaczego lepiej pracować z podejściem agile'owym? W przypadku sztywnych wytycznych projektowych, gdzie produkt definiuje urzędnik, nie patrzy się, czy to co robimy ma jakikolwiek sens (przykład: informatyzacja ZUS-u, która nie działa i kosztowała więcej niż wysłanie łazika na Marsa), mamy często związane ręce i wymuszany jest pierwszy sposób pracy. 61 / 147

62 Natomiast w projektach, które muszą się sprawdzić na rynku drugie podejście jest zdecydowanie lepsze: wielu rzeczy nie można przewidzieć i decyzje można podjąć dopiero, gdy produkt nabierze kształtów po paru iteracjach, nie zmarnujemy tygodni/miesięcy/lat pracy zespołu, jeśli wcześniej zauważymy, że dana funkcjonalność jest niepotrzebna lub za mało istotna, bo np. w tym samym czasie możemy zrobić coś, co przyniesie lepsze efekty, szybciej się uczymy na błędach i wyciągamy wnioski. O ile nie chcesz zostać Scrum Masterem, to taka wiedza Ci na razie wystarczy. Przejdźmy teraz do tego, co jest dla Ciebie istotne jako developera. 62 / 147

63 9.3. Sprint Moment STOP! Dlaczego opisuję metodykę pracy, a nie samo programowanie, czy technologie? Przecież ma to ma być książka, która ma pomóc w ukierunkowaniu się, by znaleźć pierwszą pracę jako programista. Znajomość podstaw takich procesów pracy jest dla Ciebie niesamowicie Pracodawca przydatna docenia podczas osoby, które rozmowy wiedzą kwalifikacyjnej. jak pracować efektywnie. Dodatkowo pomoże Ci to w organizowaniu swojego procesu nauki, czy rozwoju własnych pierwszych projektów. Sprint To powtarzająca się iteracja. Najczęściej dwa tygodnie. Na jej początku planujemy co chcemy zrobić w tej iteracji i wyciągamy z backlogu (taka piwnica, w której nasz product owner Fritzl przechowuje różne user story/taski więcej o rolach takich jak product owner wkrótce) różne zadania, które możemy zrealizować w tej iteracji. Następnie zaczyna się wesołe tworzenie. W trakcie sprintu mamy parę stałych meetingów np. blacklog grooming, 63 / 147

64 podczas którego z product ownerem omawiamy planowane zadania i staramy się oszacować ile pracy wymaga dane zadanie. Pod koniec sprintu prezentuje się, to co zrealizowaliśmy klientowi, czy tam szefowi. Ładnie nazywa się to review. Możemy dzięki temu w krótkim czasie zebrać wartościowy feedback, który może zaowocuje już w następnym sprincie. Dobrze wiedzieć, że coś klientowi się nie podoba i zmienić to wcześnie, zamiast rozwijać to w złym kierunku, co nie? Na sam koniec takiej iteracji siadamy z zespołem do retrospektywy i decydujemy co możemy poprawić w następnym sprincie Role w takiej organizacji pracy Product Owner Czyli taki manager. On decyduje o kryteriach odbioru zadań: musi odebrać każdy ficzer zanim zostanie on uznany za gotowy. Pewnie znacie powiedzenie gdzie kucharek sześć no właśnie: tak samo tutaj musi istnieć jedna główna osoba, która decyduje o kierunku i kształcie produktu. Inaczej całość nieuchronnie dryfuje ku nijakości. 64 / 147

65 To on prowadzi główne rozmowy z zarządem/szefem na temat produktu. Dzięki temu developer ma wolną głowę i może koncentrować się na kolejnym zadaniu. O całokształt i finalną całość martwi się Product Owner. Decyduje w jakiej kolejności zostaną wykonane zadania, co aktualnie jest najważniejsze dla produktu, a co może zostać odłożone na później. Product Owner to też pierwsza osoba kontaktowa jeśli coś nie działa lub są jakieś pytania. Dba się w ten sposób o spokojną głowę developerów, by nikt nie przeszkadzał im w trakcie pracy. Unika się dzięki temu sytuacji, w której osoba z działu marketingu wpada do pokoju z pomysłem i zaburza pracę całemu zespołowi programistów: Product Owner przechwytuje taką osobę i prowadzi wszelkie rozmowy. Jest to osoba do kontaktu na zewnątrz, czy to z szefem firmy, czy do pytań inwestorów na temat produktu. Często jest on również odpowiedzialny za wszelkie kalkulacje potencjalnych zysków/kosztów danego działania. Dlatego sporym plusem dla takiej osoby jest sprawne poruszanie się w bazach danych. Niby powinien mieć odpowiednie narzędzia BI (business intelligence), które go w tym wyręczą ale w praktyce widziałem, że musiał często pisać zapytania SQL-owe, by sobie przygotować odpowiednie dane do analizy zazwyczaj bierze on sobie wtedy do pomocy osobę z zespołu, która najlepiej orientuje się w bazie 65 / 147

66 danych projektu. Scrum Master Dba oto, by wszystko sprawnie działało. By meetingi niepotrzebnie się nie przedłużały i by brały w nich udział osoby, które są potrzebne: po co ma tam ktoś niepotrzebnie siedzieć? Każda godzina to pieniądze. Obserwuje jak działają procesy między zespołami/osobami i stara się je usprawnić/wprowadzić nowe. Moderuje retrospektywę po sprincie, analizuje co można poprawić lub zmienić w aktualnie istniejących procesach. Spotkałem się z eksperymentem, gdzie rolę Scrum Mastera przejął developer z zespołu. Był on w 2/3 developerem, a w 1/3 Scrum Masterem. Na dłuższą metę pomysł został porzucony, ale przypomina to o ważnej zasadzie: nic nie jest tutaj sztywno narzucone. Należy eksperymentować i śledzić wyniki. Później po prostu pracować według tego, co się sprawdza, a to, co nie działa - zmieniamy. Developer Czyli osoba, która pracuje nad kodem źródłowym. Czasami w zespole jest również grafik/designer, ewentualnie grafika jest dostarczana z zewnątrz. W moim ostatnim zespole 66 / 147

67 akurat 100% to byli programiści + jeden tester (QA engineer), a designer był dzielony między zespołami wewnątrz firmy. Dąży się do tego, by jeden programista mógł docelowo pracować nad każdym elementem projektu: mógł nanieść poprawkę w webserwisie, coś pogrzebać w bazie danych, aplikacji mobilnej, czy frontendzie strony www. W praktyce każdy ma swoją specjalizację: np. ktoś w zespole jest głównie od androida, ale gdy zdarzy się sprint, gdzie 90% pracy to przebudowa czegoś serwerowego, to też stara się w miarę możliwości tam pomóc. Każdy ma specjalizację, ale dąży się do tego, by każdy miał przynajmniej podstawową wiedzę z innych elementów projektu. Inne role? Te 3 role wchodzą w przyjęty standard scrumowy. Jednak czasami wprowadza się coś małego i niestandardowego. Np. wprowadziliśmy kiedyś w zespole coś takiego jak Cookie Commissioner. Była to osoba, która co sprint zrobiła coś miłego dla zespołu. Kupiła ciastka, zorganizowała wspólny wypad integracyjny. Niby coś małego, a znacznie poprawiło atmosferę w zespole. To jedna taka ciekawostka, która przypomina, że całość jest elastyczna i można trochę pokombinować. Ważne byś mniej więcej wiedział czym są 3 główne role w scrumie. 67 / 147

68 9.5. Podsumujmy krótko czego się już nauczyłeś Znasz już powody, dla których nie warto zostać programistą. Jest to zawód podobny do wielu innych specjalistów. Wszędzie wymagana jest konsekwentna praca i nie jest to łatwa droga na skróty, na której przy okazji dobrze zarobisz. Czasami warto wiedzieć, kiedy odpuścić i próbować czegoś innego. jeśli już stwierdziłeś, że warto spróbować, albo jesteś już pewny, że to coś dla Ciebie, to kolejny rozdział wyjaśni nad czym powinieneś popracować, by znaleźć pierwszą pracę jako programista. Dowiedziałeś się, że matematyka nie jest niezbędna, a studia mogą się przydać tylko czasami. Potrafisz przygotować odpowiednie CV. Wiesz już sporo o organizacji pracy typu Agile/Scrum. Świetnie. Jedziemy dalej :) 68 / 147

69 10. Praktyczna same konkrety ścieżka rozwoju W rozdziale Do rzeczy: co powinieneś potrafić, by zacząć pracę jako programista? opisałem rzeczy, które powinieneś potrafić. Dodałem również informację jak i gdzie się tego nauczyć omówimy później : te później, to właśnie treść tego rozdziału. Zaczynamy Język Angielski Znajomość języka angielskiego w sporym stopniu wpływa na to, czy robisz szybkie postępy w nauce programowania. Większość materiałów/dokumentacji jest w tym języku. Nie będę teraz namawiał do żadnych intensywnych kursów językowych. Według mnie najważniejszy jest kontakt z językiem i korzystanie z niego. Tak jak radzę uczyć się programowania: robić projekty i uzupełniać braki w wiedzy, kiedy mamy taką potrzebę. Tak samo jest w przypadku wszystkiego innego. Kontakt z językiem Jak zwiększyć ilość kontaktu z językiem? Większość nie 69 / 147

70 ma okazji codziennie porozmawiać po angielsku, ale istnieje parę banalnych sztuczek: Zmiana języka w telefonie: ile dziennie korzystasz z Twojego telefonu? Parędziesiąt minut. Może czasami dobijemy do godziny. W skali miesiąca/roku uzbiera się sporo godzin. Jeśli nie jesteś ratownikiem medycznym, czy osobą na innym stanowisku, gdzie wolniejsze posługiwanie się telefonem może zdecydować o życiu i śmierci, to chyba nie jest to duże utrudnienie. Przestaw sobie język z wygodnego polskiego na angielski. Czasami nie będziesz wiedzieć, co znaczy dana funkcja, to sobie ją przetłumaczysz, albo na chwilę zmienisz na polski, by sprawdzić, co było napisane w tym miejscu i po paru tygodniach nabijesz sporo godzin kontaktu z językiem. Zastosuj metodę zmiany języka gdzie się tylko da. Na komputerze, w przeglądarce, w ustawieniach każdej konta grze(nawet Google, w w Gothicu!). Zyskujesz dzięki temu kolejne godziny kontaktu z językiem. Korzystasz z niego na co dzień w jakiś tam sposób i wchodzi do głowy, bez poświęcania dodatkowego czasu na lekcje. Początki mogą być trudne i możesz posługiwać się swoimi urządzeniami trochę wolniej, ale długofalowo to spory zysk. 70 / 147

71 Staraj się zastąpić lektora napisami. Kolejne godziny w miesiącu, które można jakoś wykorzystać. Gdy tylko masz wybór, to staraj się sięgać po napisy, zamiast po wersję z lektorem/dubbingiem. Najlepiej gdybyś od razu oglądał po angielsku, ale w końcu nie chcemy robić nic na siłę. Na początku częstsze wybieranie wersji z napisami to pierwszy dobry krok. Ważne by robić to regularnie i za parę lat będziesz lepiej osłuchany. Tak jak w przypadku wszystkiego: ważne by robić coś regularnie przez długi okres czasu, a nie intensywnie przez tydzień i znowu wrócić do starych złych nawyków. Podcasty. Koniecznie na temat, który Cię interesuje. Ja na przykład kocham grę Morrowind. Istnieje parę angielskojęzycznych podcastów, które skupiają się tylko na omawianiu świata gry, czy sztuczek jak można dostać szybciej jakiś zajebisty, jednoręczny topór. Nawet jeśli wszystkiego nie zrozumiesz, to warto podczas drogi do pracy/szkoły pobrać sobie jakiś podcast i posłuchać go zamiast muzyki. Wybranie odpowiednio interesującego tematu powinno ułatwić skupienie się na temacie. W swój rytuał czytania nowinek w sieci wpleć treść angielską. Dobrym pierwszym krokiem jest wybranie czegoś z reddita. Osobiście 71 / 147 na początek

72 polecam: To tyle. Nigdy nie potrafiłem uczyć się języka przez naukę słówek. Kontakt z językiem przebija wszystko. Najważniejsze, by robić te rzeczy regularnie i za parę lat będą widoczne efekty. Aaaa i jeszcze jedno. Jeśli chodzi o gramatykę. W przypadku angielskiego, który potrzebujesz do nauki programowania, to możesz mieć gramatykę gdzieś i się nią nie przejmować. Nigdy nie przejmowałem się gramatyką i radziłem sobie dzięki intuicji nabytej przez kontakt z językiem. Czy myślisz o polskiej gramatyce? No właśnie O ile nie jesteś polonistą (pozdrawiam polonistów, którzy to czytają! :D), którego irytuje masa błędów, które popełniam w tej książce, to pewnie też zbytnio Cię ona nie obchodzi Umiejętność szukania informacji Po pierwsze: szukaj po angielsku. Albo przynajmniej się staraj i ucz się z tego jak poprawia Cię wyszukiwarka. Po drugie: Warto znać parę przykładów, by mieć lepszy obraz tego, jak szukamy w przypadku programowania. 72 / 147

73 10.3. Dopisywanie example do szukanej rzeczy Załóżmy, że chcemy w naszym programie (pisanym w Javie) zastosować szukanie w tekście. Wiemy, że tekst to string, więc warto szukać praktycznego przykładu. Czyli: java string search example zaraz mamy fajną listę. 73 / 147

74 74 / 147

75 Dlaczego warto dodawać example? Może to kwestia moich osobistych upodobań, ale zawsze wolałem szukać w miarę krótkich i przejrzystych przykładów jak coś zrobić. Zobaczyć jak to działa, a ewentualną teorię doczytać sobie później. Myślę, że wiele osób ma podobnie. Widząc konkretny przykład uczymy się sprawniej niż przez samą teorię Nie bój się szukać (nawet prostych rzeczy) Kiedyś dawno, dawno temu. Gdy byłem młody (piękny) i głupi Myślałem kiedyś, że dobry programista, pisze wszystko z głowy. Że nie musi szukać w sieci rzeczy, którą już raz kiedyś zrobił. Można odnieść takie wrażenie, gdy widzi się starego wyjadacza, który siedzi w jakimś projekcie już parę lat i wiele rzeczy robił już milion razy. Ale prawda jest taka, że ważniejsze jest, by wiedzieć, że coś istnieje i można to w danym języku zrobić, a same szczegóły implementacji można sobie zawsze doszukać. Np. zapisywanie tekstu do pliku tekstowego: mniej więcej wiem co i jak, ale nie napisałbym tego teraz z palca. Ale w parę minut wyszukałbym co trzeba i sklecił coś na moje potrzeby. Strzelam, że winny jest nasz kiepski system edukacji. Nie 75 / 147

76 uczą tam jak się uczyć, jak szukać informacji i wykorzystać je w praktyce (nie mówiąc już o wykorzystaniu wiedzy, by stworzyć jakiś produkt, który sprawdzi się na rynku), tylko idzie się na łatwiznę. Uczymy się wiedzy na pamięć: łatwo dla nauczyciela, który przeczyta na głos coś, co ma zapisane w książce (albo najlepiej podyktuje to, by uczeń mógł to zapisać szczyt marnotrawienia czasu) i następnie wymaga, by uczeń na sprawdzianie wypisał część wiedzy na kartce. Nigdy nie rozumiałem, jaki kretyn mógł wymyślić taki system nauki. Ważne by pamiętać, że już nie jesteś w szkole. Masz wykorzystać wiedzę w praktyce, a nie nauczyć się formułek, by jakaś stara baba narysowała uśmiechnięte nazwiska. 76 / 147 słoneczko obok Twojego

77 10.5. Szukaj i nabieraj doświadczenia Wszelkie porady dotyczące szukania nie są tutaj aż tak istotne. Może warto znać parę sztuczek w Google, które zaraz krótko opiszę. W większości przypadków to kwestia doświadczenia. Skopiujesz część komunikatu błędu: zobaczysz, że wyniki nie są tym, czego szukasz. Skopiujesz część błędu i dodasz jakąś frazę np. error bla android + network problems i już znajdziesz coś więcej. Następnym razem spróbujesz jeszcze inaczej ważne by nie bać się samemu szukać rozwiązania, zanim zwrócimy się do jakiegoś kolegi (o ile mamy kogo zapytać np. będąc na stażu). Umiejętność sprawnego szukania to w ponad 90% kwestia doświadczenia i nabytej w ten sposób intuicji. Warto jednak znać parę sztuczek szukania w Google Krótki kurs zaawansowanego szukania w Google Istnieje masę sztuczek, które można wykorzystać w wyszukiwarce Google, ale postanowiłem wymienić 3 najważniejsze, które faktycznie stosuję w codziennej pracy. Szukanie konkretnego zlepku wyrazów za pomocą. 77 / 147

78 Np. szukanie pod frazą: java error, da nam inne wyniki niż java error, czyli fraza w. Szukane są wtedy wystąpienia całej połączonej frazy, a nie tylko wyniki z dwoma pojedynczymi frazami. Przydatne podczas szukania konkretnych komunikatów błędu. Site search, czyli szukanie na konkretnej stronie www/domenie. Szukanie w całej zawartości internetu może dać czasami śmieciowe wyniki. Warto wtedy ograniczyć szukanie do jakiejś konkretnej strony np. Stackoverflow.com, czy jakieś konkretne forum np. phpforum.com. Robimy to przez wpisanie: site: szukana fraza. Np. site:stackoverflow.com android arrayadapter. Wyrzucanie wyników, w których istnieje słowo, którego nie chcemy. Robimy to przez wymienienie tego słowa po myślniku/minusie:. Przykład: game development -java dostaniemy wtedy wyniki mówiące o tworzeniu gier, ale tylko na stronach, na których nie występuje słowo java. Może to być przydatne, gdy np. szukamy czegoś o JavaScripcie i wszędzie pojawiają się podpowiedzi, by wykorzystać jquery, którego akurat możemy w tym momencie nie chcieć. Wystarczy dodać do zapytania -jquery i problem z głowy. 78 / 147

79 10.7. Rozbijanie zadań na małe części i skupienie się na jednej rzeczy jednocześnie. Czas, w ciągu którego możemy w skupieniu nad czymś pracować jest dobrem ograniczonym. Umysł ludzki szybko się męczy i zniechęca, jeśli ma przed sobą zadanie, które wymaga wiele godzin/dni/miesięcy pracy. Dlatego należy nauczyć się rozbijać duże zadania na wiele mniejszych, by następnie krok po kroku je rozpracowywać. Istnieje parę prostych rzeczy, które możemy robić, by się wspomóc w tej trudnej walce Karteczki samoprzylepne popularne sticky notes Po co one? Przecież mogę sobie zrobić listę pojedynczych rzeczy i je krok po kroku rozpracowywać niby tak. Jednak odkąd zacząłem w pracy stosować kartki samoprzylepne praca stała się jakby lżejsza. Listę zadań często miałem przed sobą i jak na nią zerkałem, to pojawiało się przygnębienie, że jeszcze tak dużo muszę zrobić. W przypadku karteczek wygląda to trochę inaczej. Małe zadania można wypisać na karteczkach i mieć na swoim biurku tylko JEDNĄ 79 / 147

80 kartkę jednocześnie. Skupić się by zrobić jeden krok, następnie z satysfakcją zgnieść karteczkę i spróbować trafić do kosza. Widzimy wizualny efekt naszej pracy, co działa bardzo pozytywnie na naszą motywację. Podam przykład zadania, które można sobie sprawnie rozbić i nanieść na pojedyncze karteczki. Chcemy poćwiczyć robienie aplikacji na androida i planujemy aplikację, która pobiera dane z jakiegoś webserwisu. Zadanie można podzielić w następujący sposób (samo planowanie przez rozpisywanie takich zadań na karteczki jest swoją drogą świetnym sposobem, by przemyśleć to, co chcemy zrobić): Założenie projektu na naszym githubie (by móc to w przyszłości gdzieś pokazać, albo mieć po prostu nasz kod 80 / 147

81 gdzieś zapisany, by za parę miesięcy wrócić i zerknąć jak to wtedy zrobiliśmy). Stworzenie pustego projektu w naszym IDE + ewentualne skonfigurowanie środowiska pracy. Wybór webserwisu, z którego chcemy pobrać dane (sama decyzja to też praca umysłowa, którą musimy wykonać. Nasza praca to nie zawsze klepanie nowego kodu źródłowego). Stworzenie pierwszego, prostego UI w ramach prototypu (na razie nie przejmujemy się idealnym wyglądem jego dopracowanie to osobna karteczka). Napisanie kodu, który potrafi wysłać pierwsze zapytanie do webserwisu. Prezentacja wyników zapytania w ramach naszego UI. Obsługa błędów (co się stanie, jeśli np. webserwis zwróci błąd). Pierwszy refactor kodu. Poprawienie UI aplikacji. cokolwiek innego, co chcesz dalej zaimplementować. Mając taką listę zadań, możemy łatwiej przemóc się do pracy oo, nie mam teraz godziny czasu, ale te 20 minut które teraz mam wystarczą, by założyć projekt na githubie i stworzyć 81 / 147

82 pusty projekt w Android Studio/Eclipse zawsze jest to 20 minut, które później masz zaoszczędzone. Gdybyś nie miał zadania rozbitego, pewnie byś nie zaczął mając tylko 20 minut do zagospodarowania. Gdy wszystko jest w małych kroczkach, to już całość nie wygląda tak strasznie. W końcu każdy krok to od 10 minut, do 2h pracy (jeśli jakiś krok zajmuje więcej czasu, to powinieneś się postarać go rozbić o ile to oczywiście możliwe) Trello proste w obsłudze narzędzie do rozbijania zadań Istnieją różne narzędzia do organizacji pracy. Osobiście prawie codziennie korzystam z Trello. Dla małych zastosowań jest darmowe i pozwala bardzo fajnie porządkować małe i średnie projekty. W końcu nie chcesz zatonąć w morzu karteczek. Nie będę tutaj opisywał jak z niego korzystać, bo narzędzie jest bardzo intuicyjne i po paru minutach klikania powinieneś sobie poradzić. Powinieneś na razie tylko wiedzieć, 82 / 147

83 że warto założyć tam konto i trochę popróbować z testowymi projektami. To, że zarządzałeś jakimś swoim projektem w tego typu narzędziu, to dobre doświadczenie, o którym możesz wspomnieć na rozmowie kwalifikacyjnej Ćwiczenie skupiania się/wyciszania się krótko o medytacji możesz olać ten punkt Każdą rzecz można ćwiczyć. Tak samo możemy ćwiczyć umysł, by nie uciekał ciągle myślami w kierunków jednocześnie. Od niedawna zacząłem poświęcać 20 minut dziennie, by starać się nie myśleć. Ot próbować przez jakiś czas się wyciszyć i nie dopuszczać żadnej myśli. Nie wiem, czy to efekt placebo, ale zacząłem zauważać, że pracuję wydajniej i łatwiej jest mi się na czymś skupić. Istnieje masa poradników, jak można medytować ale staram się ograniczyć to do 3 reguł: Nie możesz wtedy leżeć (bo zaśniesz), tylko musisz siedzieć (obojętnie jak) lub stać. Starać się nie myśleć łatwo powiedziane. Należy pamiętać, że ćwiczymy tym procesem skupianie umysłu i sesja w ciągu której uda nam się nie myśleć przez / 147

84 sekund też jest udana. Ćwiczymy ten miesień i akceptujemy, że nie wytrzymamy za długo. Robimy to regularnie. Codziennie. To proces długofalowy. Lepiej próbować tak codziennie przez 5-10 minut (ustawiamy sobie timer) niż raz w tygodniu dłużej. Jeśli na to popatrzysz z boku, to jest to najprostsza czynność jaką może robić człowiek. Siedzieć w bezruchu, nie myśleć i ćwiczyć uspokajanie swojego umysłu. Możesz olać ten punkt, jeśli uważasz go za bezsensowny. Mi to pomaga i czuję dzięki temu poprawę w koncentracji. Osobiście polecam Napisanie (nawet bardzo małego) projektu od początku do końca Twoja ścieżka rozwoju powinna owocować małymi projektami. Przez pisanie takiego projektu od początku do końca, nauczysz się jak szybko coś może się rozrosnąć i że lepiej planować rozwój czegoś bardzo małymi krokami. Nie popadaj w pułapkę tworzenia 100 pojedynczych projektów, w których nie będzie nic oprócz przepisanego na ślepo kodu z 10 minutowego tutorialu. 84 / 147

85 Jeśli nie należysz do osób, które potrafią łatwo wymyślać przykładowe projekty, to postaram się parę zasugerować. Jednak zanim przejdziemy do listy projektów, po raz kolejny przypomnę o założeniu sobie konta na serwisie github/bitbucket, czy czymś podobnym. Niesamowicie ułatwia to organizację pracy i pozwala na łatwy wgląd do naszych starych projektów. Przed Tobą parę pomysłów na proste projekty. Od najprostszej wersji, po bardziej rozbudowane warianty. Pomysły są neutralne technologicznie. Można je wykonać w prawie każdym języku programowania Manager schroniska dla zwierząt Program, w którym dodajemy do bazy/usuwamy z bazy zwierzęta oraz sprawdzamy przepełnione, puste etc.). 85 / 147 stan schroniska (pełne,

86 Wariant I Bardzo prosty: Program konsolowy. Schronisko ma mieć określoną ilość miejsc. Możliwość dodania/usunięcia zwierzaka do/z listy zwierząt w schronisku (na razie lista nie musi być zapisywana do żadnej bazy danych, ani pliku tekstowego). Po wpisaniu status program ma wypisać aktualną listę zwierząt i wyrzucić komunikat, czy ilość zwierząt powoduje, że schronisko ma jeszcze miejsce, jest pełne lub jest przepełnione. Zaimplementuj logikę, która uniemożliwia dodanie zwierzaka, jeśli schronisko jest pełne. Wariant II to samo co wyżej plus: Zamiast programu konsolowego mamy proste UI Lista zwierząt jest zapisywana do pliku tekstowego lub bazy danych. Po wyłączeniu programu i ponownym odpaleniu ma zostać załadowany ostatni stan z bazy/pliku. Wariant III to co wyżej plus: Gdy schronisko ma mniej niż 5 wolnych miejsc wysyłany 86 / 147

87 jest informacyjny do osób pracujących w schronisku. Możliwość edycji poszczególnych zwierząt. Dodanie pól takich jak np. stan zdrowia, płeć itp. Wariant IV to co wyżej plus: Udostępnienie webserwisu, przez który można wyczytać aktualny status schroniska. Wariant V to co wyżej plus: Aplikacja mobilna (na dowolny system operacyjny), która korzysta z powyższego webserwisu. Zamiast aplikacji mobilnej może być to też strona www. Ważne by pobierała dane korzystając z napisanego przez nas webserwisu. Co można jeszcze dodać? Testy jednostkowe, które pokrywają najważniejszą funkcjonalność (nie martw się jeśli jeszcze nie znasz niektórych pojęć jak np. testy jednostkowe. Zostaną one później krótko omówione). Eksport statusu schroniska do pliku.csv. Generowanie dziennego raportu ze stanu schroniska do pliku.pdf, który zostanie wysłany na określonego maila 87 / 147

88 oraz dodany do jakiegoś archiwum. Możliwość dodawania zdjęć określonego zwierzaka przez aplikację mobilną (wymaga rozszerzenia webserwisu oraz aplikacji mobilnej). Jak widzisz, nawet taki prosty pomysł jak manager schroniska można całkiem poważnie rozbudować. Zachęcam do wymyślenia czegoś własnego pod kątem tego co Cię interesuje. Może ten przykład trochę Cię zainspirował Pierwsza gra Jeśli chcesz uczyć się programowania pod kątem tworzenia gier, to podaję prosty przykład na pierwszą grę. Wariant I Bardzo prosty: Okno z jakimś napisem (np. tytuł gry). Gracz (jakiś prosty kwadrat), którego poruszamy strzałkami w lewo, prawo, górę, dół. Prosta gra 2d z 88 / 147

89 widokiem z góry. Przeszkody, z którymi gracz może kolidować. Wariant II to co wyżej plus: Przeciwnik, który porusza się w losowym kierunku, odbija od ścian i krawędzi ekranu. Licznik liczący ile czasu spędziliśmy w grze. Pasek życia, po kolizji z przeciwnikiem się zmniejsza. Efekty dźwiękowe po kolizji z przeszkodą/przeciwnikiem. Ekran Game Over, gdy pasek życia spadnie do zera. Wariant III to co wyżej plus: Prosta sztuczna inteligencja przeciwnika. Nie zmierza on teraz w losowym kierunku, tylko szuka gracza. Możliwość strzelania w przeciwnika Wariant IV to co wyżej plus: Zapisywanie wyniku stanu gry do jakiegoś lokalnego pliku. Możliwość grania w 2 graczy na jednym komputerze (mogą się zwalczać lub walczyć razem z przeciwnikami). Możesz urozmaicić sztuczną inteligencję komputerowego przeciwnika. 89 / 147

90 Wariant V to co wyżej plus: Opcja 2 graczy przez sieć. Inne pomysły? Warto zerkać na: Znajdziemy tam różne zagadki programistyczne (od łatwych po trudne) i możemy poćwiczyć ich rozwiązywanie. Następnie w sposób podobny do powyższych wariantów możemy je rozbudować.. Zaczynamy od prostej aplikacji konsolowej, później dodajemy UI, zapisywanie danych, podpięcie webserwisu możliwości jest sporo. 90 / 147

91 Skonfigurowanie środowiska pod projekt Konfiguracja środowiska jest jednym z głównych powodów, przez które programowanie może zniechęcić na początku. O ile w przypadku tworzenia stron www, nauce javascriptu (dlatego też.js jest często polecany jako pierwszy język bardzo łatwo zacząć) konfiguracja to jedynie przeglądarka i prosty notatnik (czy notatnik++), to w przypadku czegoś trochę bardziej rozbudowanego jak np. android, Ruby on Rails, czy Java EE konfiguracja może wydawać się przytłaczająca. Dlatego warto to parę razy zrobić, by nabrać trochę wprawy. Co zazwyczaj zawiera taka konfiguracja środowiska? Instalacja IDE. Doinstalowanie technologii wymaganych przez projekt 91 / 147

92 (np. możliwość kompilowania przez naszą maszynę Ruby, Javy, Pythona etc.). Konfiguracja i podpięcie pod projekt lokalnej bazy danych. W przypadku pracy w firmie: udostępnienie różnych praw, by Twój komputer mógł łączyć się z jakimś zabezpieczonym serwerem testowym. wiele różnych drobnostek, na które na pierwszy rzut oka trudno wpaść. Oto parę przykładowych rzeczy, które możesz poszukać w sieci i spróbować lokalnie skonfigurować: Aplikacja na androida, która korzysta z Google Maps. Hello World webserwisu z wykorzystaniem Javy, Eclipse lub IntelliJ, TomCata i Springa. Podpowiedź: pogooglaj pod frazą: java tomcat web service spring example. Lub spróbuj odpalić prosty webserwis w dowolnej innej technologii, którą sobie wyszukasz. Skompiluj najprostszą możliwą grę z wykorzystaniem różnych możliwych technologii: cocos2d-x, libgdx, Ogre3D, Unity pod androida, Unreal Engine, Allegro (biblioteka, nie serwis aukcyjny) i C++, Allegro.js, cokolwiek innego co wygooglasz z technologii do tworzenia gier. 92 / 147

93 Aplikacja okienkowa napisana w dowolnym języku, która będzie korzystała z lokalnej bazy danych. Odpal przykładowe hello world z wykorzystaniem dowolnego freamworka do PHP i postaraj się podpiąć lokalną bazę danych. mam nadzieję, że łapiesz. Przywykniesz do tego, że czasami pojawiają się różne problemy i musisz dużo szukać w Google, ale z każdym kolejnym rozwiązanym konfliktem będziesz miał w tym więcej doświadczenia. Warto pamiętać, że te problemy z konfiguracją pojawiają się PRAWIE ZAWSZE. Ciągle pojawiają mi się błędy, gdy podpinam AdMoba (reklamy mobilne) do iosowej wersji mojej gry napisanej w libgdx. Musisz do tego przywyknąć i nie dołować się niepotrzebnie, gdy zamiast programować poświęcisz znowu prawie godzinę na rozwiązaniu jakiegoś głupiego błędu z IDE. Wszyscy przez to przechodzą. 93 / 147

94 Rzeczy, w których powinieneś się orientować: podstawy baz danych (generalnie zapisywanie i czytanie danych), technologie webowe, protokoły komunikacyjne, programowanie obiektowe, testy i webserwisy (tworzenie i używanie). Zazwyczaj będziesz potrzebował pogłębienia konkretnego obszaru wiedzy. Z reszty wystarczy się orientować w podstawach, by wiedzieć jak szukać i wiedzieć o czym mówi kolega obok, który specjalizuje się w innej działce. Przy okazji przypominam, że należy traktować tę książkę jak drogowskaz co należy w praktyce potrafić, by aplikować do pierwszej pracy jako programista (i odnaleźć się w takim miejscu pracy), a nie zawiera szczegółów na temat samej implementacji. Jak coś zrobić, można bez problemu znaleźć sieci. 94 / 147

95 Pliki z danymi, zapisywanie i czytanie danych CSV Bardzo często spotykam się z danymi zapisanymi w formacie.csv, czyli w formacie popularnie znanym jako excelowy, czy tabelkowy. Prosty przykład to: ID, Imie, Nazwisko 1, Jan, Nowak 2, Tomasz, Tomecki Pewnie możesz sobie łatwo wyobrazić jak z takiego pliku powstaje tabelka w Excelu. Powinieneś spróbować zrobić jakiś prosty projekt, w którym odczytasz dane z takiego pliku, edytujesz je, albo tworzysz całkowicie nowy plik z jakimś stanem programu. Podpowiedź: szukaj pod reading writing csv example + technologia: java, python, php etc. 95 / 147

96 TXT Zwykły plik tekstowy. Możesz spróbować odczytać z niego dane i zapisać stan programu do takiego pliku. Nie jest on zbyt często wykorzystywany w większych projektach (przynajmniej ja się nie spotkałem), ale to najprostszy przykład pliku, z którym warto sobie poćwiczyć. PDF Do pdf-a exportujemy dane, by mieć je w czytelnej formie, gotowe do wysłania jako np. ładny załącznik maila. Mało kiedy z niego czytamy dane (nie spotkałem się z tym, ale właśnie doczytałem, że jest to możliwe). Bez problemu wyszukasz narzędzia/biblioteki, które ułatwiają eksportowanie danych jako pdf w Twojej technologii. HTML Czyli w formie strony www, którą można odczytać za pomocą dowolnej przeglądarki internetowej. Dobrym przykładem tak wygenerowanych plików są wszelkiego rodzaju raporty. Umiejętność czytania (parsowania) takich plików to potężne 96 / 147

97 narzędzie. Dzięki temu będziesz mógł wykorzystać w swoim programie dane pobrane z różnych stron www. Podpowiedź: szukaj jak to zrobić pod zapytaniem parsing html + Twój język programowania Java/Python/Ruby/Php + example Bazy danych Z bazami danych wiąże się wiele zawodów. Jednak dla Ciebie istotne jest na razie tylko parę podstaw. Powinieneś: Potrafić założyć bazę danych z różnymi tabelami Dodawać dane do bazy Edytować dane w bazie Usuwać dane z bazy Potrafić podpiąć taką bazę danych pod technologię z której korzystasz. Jeśli raz uda Ci się to zrobić z DOWOLNĄ bazą danych w DOWOLNEJ technologii, to powinieneś sobie poradzić również w każdej innej. Kwestia doczytania paru szczegółów i poświęcenie paru godzin na próby i błędy. 97 / 147

98 Powinieneś już wiedzieć, jak wyszukać taką informację java/python/ruby database example. Istnieje milion rzeczy, których możesz się jeszcze nauczyć o bazach danych, ale na początek zacznij od tego, co wyżej napisałem. Ważne byś takie dodawanie, edytowanie, usuwanie potrafił robić z poziomu programu, który właśnie piszesz, a nie tylko bezpośrednimi zapytaniami na bazie Podstawowe technologie webowe Html, CSS i JavaScript (z ewentualnym wsparciem ze strony jquery lub AngularJS) proste w nauce i bardzo pomocne. Nie wyobrażam sobie, by jakiś programista nie wiedział jak stworzyć najprostszą stronę www za pomocą html-a, css-a i jakiejś małej sztuczki w javascripcie. Jest to szczególnie pomocne, by testować sobie jakiś prosty front end naszego oprogramowania. 98 / 147

99 HTML W jakim stopniu powinieneś go opanować? Wystarczy, że wiesz czym jest sekcja HEAD, BODY, jak tworzy się linki do innych stron, jakieś podstawy prezentacyjne (pogrubienie tekstu, podkreślenie), czym jest paragraf, div i jak zrobić tabelkę do prezentacji danych resztę sobie doczytasz w ramach potrzeb. W jeden dzień ogarniesz o co w tym chodzi i stworzysz pierwszą prostą stronę www. To serio mega proste. CSS HTML jest od struktury dokumentu, a Css opisuje jak ten dokument ma wyglądać. Dzięki temu sam dokument HTML zyskuje na przejrzystości, bo całość (albo przynajmniej większość) informacji na temat wyglądu dokumentu jest w osobnym pliku.css. Poszukaj sobie czegoś pod frazą css crash course, by zorientować się jak to działa w połączeniu z html-em. Tak ja wszędzie: na bieżąco szukasz tego co potrzebujesz, a na razie postaraj się tylko zrozumieć, jak to działa nie ma sensu intensywnie się uczyć Css-a, jeśli nie masz zamiaru profesjonalnie tworzyć stron www, czy być ekspertem od 99 / 147

100 front-endu. JavaScript / jquery By coś dynamicznie zmieniać na stronie www wykorzystuje się JavaScript. Nie ma on nic wspólnego z Javą, zbieżność nazw wynika z tego, że powstały w podobnym okresie czasu i chciano w celach marketingowych podpiąć się pod hype Javy Jest to bardzo potężne narzędzie, w którym możesz tworzyć zaawansowane gry. Jednak dla Ciebie na razie ważne będzie by: Wiedzieć jak zamieścić jakiś.js skrypt na stronie www. Zerknąć na dowolny javascript crash course. Spróbować wykorzystać jakiś istniejący webserwis za pomocą jquery naprawdę fajne doświadczenie i pomaga ogarnąć big picture wokół tego wszystkiego. 100 / 147

101 Protokoły komunikacyjne Najwięcej będziesz miał prawdopodobnie do czynienia z HTTP i HTTPS. Możesz sobie zobaczyć parę filmików na YouTube na ich temat, poczytać teorię jeśli chcesz jednak najważniejsze, by spróbować wykorzystać je w praktyce: Szukaj jak to zrobić pod frazą http request example + java/c#/python/android etc. Spróbuj zaimplementować parę przykładowych requestów w swoim programie. Jeśli jesteś ambitny, to możesz skierować te zapytania ( request to zapytanie) na swój własny serwer, na którym masz zamieszczony np. jakiś swój webserwis. 101 / 147

102 FTP Protokół do transferu plików z Twojego komputera (czy komputera klienta) na serwer i odwrotnie. Zazwyczaj użytkownik potrzebuje swój login i hasło, by mieć dostęp do takiego serwera. Osobiście w pracy (programując) wykorzystywałem przez 95% czasu komunikację po Http/Https, więc jeśli masz ograniczony czas, to głównie na nim powinieneś się skupić, jednak zawsze warto przerobić jakiś przykład z protokołem FTP, by widzieć jakie mamy dzięki niemu możliwości. Szukaj pod: java/c#/php + FTP example. Przykładem programu, który korzysta z takiego protokołu jest np. popularny Total Commander. POP i SMTP Post Office Protocol i Simple Mail Transfer Protocol protokóły do poczty elektronicznej. 102 / 147

103 Korzystając z nich możesz pisać programy pocztowe (no shit Sherlock), wszelką funkcjonalność wokół wysyłania/odbierania poczty elektronicznej. Nie podam tym razem przykładu jak szukać materiałów na ten temat. Powinieneś już widzieć. :) W ramach nauki możesz napisać program do odbierania maili. To świetny przykład do nauki programowania aplikacji mobilnych. Aplikacja do odbierania maili, to świetny kandydat do projektu do CV na młodszego android developera Programowanie obiektowe Programowanie obiektowe to dziwny stwór na początku kompletnie mnie odrzucało i nauka wydawała się bardzo męcząca. Po jakimś czasie przeskoczył mi w głowie jakiś przełącznik i nagle stało się to fajne i oczywiste i nie wyobrażam sobie programowania nieobiektowego. Postaram się odtworzyć proces myślowy, który sprawił, że wreszcie to zrozumiałem. Pamiętam, że często irytowało mnie mylenie obiektu z klasą. Jakoś nie mogłem tego logicznie przyporządkować do niczego w 103 / 147 mojej głowie. Jeśli raz

104 przeczytałem czym to się różni, pamiętałem to przez chwilę, ale za parę dni znowu zacząłem mylić pojęcia klasy i obiektu. Nie pamiętam dokładnie gdzie przeczytałem, czy słyszałem to porównanie, ale wtedy zaświeciła mi się jakaś lampka. Przedstawię to na podstawie czołgu. Bo czołgi są zajebiste. Widzisz ten plan czołgu? Nie jest to faktyczny OBIEKT. To plan na stworzenie takiego obiektu! Klasa, to taki plan. Jak stworzyć obiekt, ale nie jest to sam fizyczny obiekt. Boooooom! Pamiętam, że po takim porównaniu na zawsze zostało w mojej głowie te porównanie i już nigdy tego nie zapomniałem. 104 / 147

105 Należy więc pamiętać, że to co piszemy (klasy), to plany obiektów, które później możemy w jakiś sposób zbudować w programie. Nie będę teraz pisał kolejnego kursu programowania obiektowego. Kluczem do nauki jest praktyka. Możesz poczytać trochę teorii, ale najlepiej uczyć się zawsze na przykładach. Nie ma magicznego sposobu. Niestety. Rób swoje projekty -> pokazuj kod -> czytaj kod innych osób -> pisz kolejny projekt. To wszystko kwestia doświadczenia. W jednym z poprzednich rozdziałów wymieniłem, jakie pojęcia związane z programowaniem obiektowym powinieneś dobrze znać, by móc komunikować się z innymi programistami, ale wymienię je jeszcze raz: obiekt, klasa, klasa abstrakcyjna, interfejs, konstruktor, dziedziczenie, kompozycja, metoda, wzorzec projektowy. Powinieneś to potrafić stosować w praktyce, a nie tylko 105 / 147

106 wyjaśnić pojęcia. Jeśli jeszcze tego nie potrafisz, to wiesz za co się musisz zabrać. Zdecydowanie powinieneś intuicyjnie wiedzieć coś na temat każdego z tych punków Web serwisy Jak zaczynałem w pierwszej pracy jako programista, to nigdy o czymś takim jak Web Serwis nie słyszałem. Głupi ja. Tzn. pewnie, że wiedziałem, że istnieje coś z taką funkcjonalnością jaką ma web serwis, ale jakoś nie umiałem przyporządkować tej nazwy do funkcjonalności. Dlatego zacznę od prostego na chłopski rozum wyjaśnienia czym jest Web Serwis. To usługa sieciowa: tyle, że jest to usługa dla programisty, napisanego przez niego oprogramowania, a nie dla człowieka. Usługą dla człowieka byłoby wejść na stronę www, graficzne wyświetlenie zawartości i zapewnienie możliwości korzystania z portalu. W przypadku usługi sieciowej (web serwisu) jest to pewien adres (URL) w sieci, za pomocą którego możemy korzystać z jakiejś usługi (np. pobranie, edycja, usunięcie danych). Najlepiej to zilustrować. 106 / 147

107 Na co zwrócić uwagę: aplikacja na telefonie, która korzysta z usługi sieciowej (web serwisu) na serwerze, otrzymuje dane w formacie neutralnym technologicznie (zazwyczaj json lub xml) i może je w dowolny sposób przetworzyć. Zamiast aplikacji na telefonie możemy wstawić cokolwiek. Aplikację konsolową, lodówkę, maszynkę do kawy z wifi mieliśmy taką w pracy, ale odłączyli nam tę funkcjonalność, 107 / 147

108 bo bali się, że za dużo namieszamy :(. Co powinieneś potrafić i czego spodziewać się w pracy? Korzystania z Web Serwisów (czyli pisanie aplikacji klienckiej jak ten telefon na powyższej grafice. Jest on klientem serwera, który zapewnia usługę sieciową). Pisanie usługi. Czyli budujesz funkcjonalność na serwerze, z której będą mogli korzystać klienci: telefony, lodówki i wszystko co można zaprogramować. Oto co możesz sobie wyszukać, by poćwiczyć to na przykładzie: rest service client java/c#/android/python example lub web service client java/c#/android/python example by napisać prostą przykładową aplikację klienta, która korzysta z usługi sieciowej. Ważne byś szukał przykładu napisania klienta (client) usługi sieciowej, a nie pisanie samej usługi, która moim zdaniem jest trudniejsza do zrozumienia. Gdy zrozumiesz jak działa klient, to warto spróbować napisać samą usługę. Jest to bardzo szeroki temat, ale na początek wyszukaj sobie rest service example + coś z technologii, którą chcesz poćwiczyć spring, java, c#. Ważne, by zacząć na maksymalnie prostych przykładach, 108 / 147

109 które możesz w miarę samodzielnie modyfikować. Np. w przypadku klienta, wystarczy, że napisze aplikację, która pobiera aktualną pogodę. Gdy piszesz usługę, to wystarczy zwrócenie twardo zakodowanej liczby. Później może jakichś prostych danych pobranych z bazy. Istnieje świetny kanał na YouTube, który tłumaczy usługi sieciowe: Java Brains. Więcej polecanych materiałów znajdziesz w rozdziale Skąd się uczyć? czyli lista polecanych stron/materiałów Testy jednostkowe O co chodzi z testami jednostkowymi? Pewnie obiło Ci się już o uszy, że istnieje coś takiego jak pisanie testów. Na samym początku nie zawracałbym sobie tym głowy, bo i tak już jesteś przytłoczony nadmiarem informacji. Ważne, byś na razie wiedział: Projekt zawierający testy jest uważany za projekt z lepszej jakości kodem. Testy pokazują swoją wartość długofalowo informują nas, że popsuła się jakaś stara funkcjonalność bez 109 / 147

110 konieczności jej ręcznego przetestowania. Ich pisanie często zajmuje drugie tyle, co pisanie właściwego kodu, przez co wydaje się, że robimy wolniejsze postępy. Jednak w perspektywie dużego (wieloletniego) projektu jest to warte poświęconego czasu. Istnieje coś takiego jak TDD (Test-driven development), czyli proces tworzenia oprogramowania, w którym najpierw pisze się testy, a później implementację. Nie polecam tego dla juniora bardzo łatwo się zniechęcisz. Warto się tym zainteresować, gdy masz już trochę doświadczenia. Na razie wystarczy Ci wiedza, że coś takiego istnieje. Warto znać pojęcie code coverage, czyli ile procent naszego kodu ma pokrycie w testach. Pisanie testów to spory nakład pracy, więc jeśli się na to decydujemy, to powinniśmy świadomie zdecydować gdzie są one najbardziej potrzebne. W idealnym świecie z nieskończoną ilością czasu wszystko by było pokryte testami, jednak w rzeczywistości projektów budżety są ograniczone i nie można w nieskończoność rozwijać projektu w piwnicy. Jak szukać prostych przykładów do nauki pisania testów? 110 / 147

111 Unit test example + technologia: java, C#, javascript, android Parsowanie danych json i xml Do rzeczy: parsowanie to przetworzenie danych z neutralnego technologicznie formatu (zazwyczaj json lub xml) w nasz lokalny format danych. Weźmy przykład prostego xml-a: <klienci> <klient id= 1 > <imie>jan</imie> <nazwisko>kowalski</nazwisko> </klient> <klient id= 2 > <imie>tomasz</imie> <nazwisko>tomecki</nazwisko> </klient> 111 / 147

112 </klienci> Parsowanie takiego xml-a, to pobranie go przez nasz program i przekształcenie tych danych w nasze lokale obiekty. W tym przypadku będzie to lista klientów, w której znajdują się obiekty Klient z polami: id, imię i nazwisko. Proste, prawda? By spróbować przykładów z technologią Twojego wyboru poszukaj: xml parsing example + technologia json parsing example + technologia Na początku wydaje się to męczące, ale z czasem przywykniesz, że parsowanie danych to standardowe zadanie, które wykonujesz bardzo często Praca z narzędziem kontroli wersji: np. git. By móc się sprawnie komunikować w zespole, albo byś czuł się mniej zagubiony wśród pojęć związanych z gitem. Oto lista najważniejszych uproszczony sposób pojęć wytłumaczonych (szczegóły 112 / 147 możesz w bardzo doczytać w

113 dokumentacji i zrozumiesz o co dokładnie chodzi podczas stosowania gita w praktyce w żadnym wypadku nie traktuj poniższych informacji jak oficjalne definicje!): clone pobranie/sklonowanie projektu na nasz dysk do jakiegoś folderu. branch gałąź projektu. Projekt ma rożne rozgałęzienia, by móc swobodnie pracować nad nowa funkcjonalnością w zespole (lub by samemu sobie lepiej zorganizować pracę). checkout zmiana branchu, gałęzi wewnątrz projektu. plik.gitignore plik, w którym podane są typy plików lub konkretne pliki, które git ignoruje. Dzięki temu repozytorium (miejsce, w którym przechowujemy pliki) jest bardziej przejrzyste. commit wprowadzenie, zapisanie zmiany w lokalnym repozytorium (ważne: na zewnętrznym serwerze zmiana będzie dopiero widoczna po wykonaniu push-a). push wysłanie zakommitowanych zmian na serwer. pull pobranie zmian z serwera (np. kolega coś wrzucił i chcemy to pobrać, to robimy to przez pull ). merg mergowanie rozwiązywanie konfliktów w plikach: taki konflikt powstaje, gdy np. 2 programistów 113 / 147

114 wykonało zmianę w tej samej linii kodu i git nie jest sam w stanie rozstrzygnąć co powinno być w danym miejscu. Podczas całej książki mówię o tym, by wrzucać swoje projekty/postępy na Githuba/Bitbucket, czy w inne podobne miejsce To właśnie nauka gita -> przez praktykę i korzystanie z niego. Bardzo polecam zaopatrzyć się w Source Tree świetny program do wizualnej pracy z gitem. Oprócz samego Source Tree warto doinstalować sobie DiffMerge -> świetne narzędzie do rozwiązywania konfliktów po mergowaniu. Czas na praktyczny przykład tego, co powinieneś zrobić, by poczuć się pewniej w pracy z gitem: Wybierz dowolny projekt, który masz już na githubie (lub stwórz nowy prosty projekt, jeśli nie masz tam żadnego projektu) i pobierz go na innym komputerze (ostatecznie pobierz go w innym miejscu na dysku, jeśli nie masz dostępu do innego komputera). Stwórz na tym innym komputerze osobny branch pobranego projektu. Jeśli nie wiesz jak to zrobić, to poszukaj git making a 114 / 147

115 branch lub git source tree making a branch. Wprowadź drobne zmiany wewnątrz branchu. Następnie wykonaj commit i push. Na pierwszym komputerze zrób checkout tego nowego branchu i spróbuj go wmergować w Twój ostatni stan projektu. Na bieżąco szukaj w internecie, jeśli nie potrafisz wykonać jakiegoś z tych punktów. Jeśli uda Ci się wykonać wszystkie kroki, to świetnie! Masz już pierwsze wrażenie jak wygląda praca w grupie korzystającej z gita. W idealnym przypadku postaraj się z kimś robić projekt i korzystać z gita. Przez rozwiązywanie napotkanych problemów sporo się nauczycie Usprawnianie pracy w IDE, czy innym środowisku. Bardzo często słyszałem od osób, które prowadzą rozmowy z kandydatem na programistę w firmie, że bardzo dobre wrażenie zrobiło na nich to, jak sprawnie ktoś poruszał się po IDE 115 / 147

116 (czy w dowolnym innym narzędziu jego codziennej pracy). Nie chodzi tutaj o ślepo wyuczone skróty klawiszowe, dzięki którym nie potrzebowali oni korzystać z myszki po prostu płynność i efektywność pracy takiego człowieka. Jak coś takiego osiągnąć? Po pierwsze: jest to proces długofalowy i nie osiągniesz tego po jakimś kursie, czy artykule. Jest to proces wyłapywania czynności, które często wykonujemy i drobne usprawnienie, dzięki któremu zyskujemy parę sekund. Praktyczny przykład: piszę tego ebooka/książkę w przeglądarce w Wordpresie. Ostatnie dni najwięcej czasu spędzam w przeglądarce pisząc kolejne zdania i robiąc mniejszy/większy research w sieci. Bardzo często zmieniam tab (zakładkę) z Wordpresem na inny (Ctrl + Tab) i wpisuję coś w adres (przejście do sekcji wpisywania adresu to Ctrl + L). Dzięki temu nie odrywam dwóch rąk od klawiatury (nie muszę sięgać po myszkę) i przez to pracuję sprawniej. Dodatkowo kupiłem sobie klawiaturę, która ma po prawej wbudowany touch pad potrzebuję coś szybko przesunąć/zaznaczyć -> korzystam z touchpada. Po myszkę sięgam dopiero, gdy potrzebuję więcej precyzji np. w obróbce graficznej jakiegoś obrazka. To kwestia przyzwyczajenia i pewnie wiele osób teraz bluzga, że lubię 116 / 147

117 korzystać z touchpada (np. kocham touchpada na macu kompletnie nie potrzebuję na nim myszki), ale zauważyłem, że ja dzięki niemu sprawniej pracuję. Znalezienie sposobu jak Ty skutecznie pracujesz, to Twoje zadanie. W każdy miejscu powinieneś szukać jakiegoś drobnego usprawnienia w swojej pracy. W sposobie w jaki korzystasz z narzędzi. Załóżmy, że zrobisz co miesiąc jedną zmianę, przez którą pracujesz 1% wydajniej. Po roku pracujesz na tyle wydajniej, że w miesiąc wykonujesz 10% więcej pracy, niż w ten sam miesiąc rok temu. Oto parę przykładowych rzeczy, które uznaję za sensowne w pracy w IDE. Skrót klawiszowy danej czynności w Twoim IDE sam sobie bez problemu wyszukasz: Call Hierarchy gdzie metoda jest wywoływana. Quick Outline pokazuje listę metod/pól w klasie, w których możemy szukać. Refactor metody / method refactor zmiana nazwy 117 / 147

118 metody/argumentów we wszystkich miejscach w projekcie. Open Resource wyszukanie, którą klasę, lub który zasób (np. plik.xml) otworzyć. Quick fix popularne np. w Eclipse Ctrl + 1, które pozwala np. na szybkie przypisanie wyniku wyrażania do zmiennej lokalnej lub pozwala na szybki dostęp do paru innych popularnych akcji. Przesunięcie linii kodu w górę/dół. Szybkie usunięcie linii kodu. Zakomentowanie linii kodu i wiele innych. Ważne jest, by próbować wprowadzić u siebie nawyk korzystania z jednego takiego triku jednocześnie. Gdy spróbujesz wprowadzić parę jednocześnie, to w praktyce nie będziesz stosował żadnego. Zawsze możesz podpytać kolegów, jakie skróty/usprawnienia oni najczęściej stosują w projekcie. 118 / 147

119 Podsumowanie Za Tobą dużo materiału. Jeśli przeczytałeś całość ze zrozumieniem i wykonałeś parę ćwiczeń, to powinien Ci się przed oczami powoli rysować jakiś ogólny obraz pracy programisty. Mam nadzieję, że ułatwi Ci to zlokalizować w jakich punktach masz braki, a z czym sobie radzisz. W kolejnym rozdziale postaram się opisać parę dobrych miejsc, z których można się uczyć programowania. 119 / 147

120 11. Skąd się uczyć? lista polecanych stron/materiałów W sieci istnieje masa materiałów, które obszernie opisują różne języki programowania. Problem pojawia się, gdy chcemy znaleźć coś, co uczy w sposób przystępny. Łatwo odesłać kogoś do oficjalnej dokumentacji, ale prawda jest taka, że pomaga ona komuś, kto ma już doświadczenie. Jeśli osobie zielonej w programowaniu rzucimy samą dokumentację, to najprawdopodobniej tylko się zniechęci. Ten rozdział ma pomóc w znalezieniu przystępnych materiałów do samodzielnej nauki. Są to materiały, które osobiście polecam dlatego też nie polecę materiałów do wszystkich języków programowania, a tylko te, z którymi sam miałem do czynienia Najlepszy start w programowanie świetna (i darmowa!) książka Istnieje język programowania, do którego nie musimy specjalnie nic konfigurować. Wystarczy prosty edytor tekstowy. Oto JavaScript. 120 / 147

121 11.2. Eloquent JavaScript Marijn Haverbeke Moim zdaniem jeden z najlepszych możliwych wstępów do programowania. Tym bardziej cieszy fakt, że książkę można za darmo czytać w sieci: / 147

122 Dlaczego książkę można czytać za darmo w sieci? Wszystko kosztuje: książka powstała dzięki liście sponsorów: sama fundacja Mozilla dała na ten cel $ potrzeba lepszej rekomendacji? Start w Javie Uważam, że zaczynanie z książką jest trochę męczące. Zawsze wolałem widzieć jak ktoś coś robi w IDE i następnie zrobić u mnie to samo. Dlatego na start polecam mój ulubiony kanał YouTube uczący programowania: Cave of Programming John Purcell Podziwiam wkład pracy jaki autor włożył w swój kanał. Posiada on również płatne kursy na Udemy, które są warte swojej ceny. 122 / 147

123 Co znajdziecie w jego darmowych materiałach? Java dla początkujących Java Collections Framework (kolekcje) Wielowątkowość w Javie Wzorce projektowe w Javie C++ dla początkujących (tego kursu nie oglądałem) Wstępy do jego płatnych kursów (Android, Swing, Spring) Co znajdziecie w jego płatnych materiałach premium? Kurs Androida Kurs Java Swing (aplikacje desktopowe w Javie) Kurs Java z wykorzystaniem Springa Java z Servletami i JSP (tworzenie stron w Javie) Kurs Perl 5 Czas na mój drugi ulubiony kanał na YT Derek Banas Kanał właściwie równie dobry jak Cave of Programming może jedynie ciut bardziej chaotyczny. Trochę brakuje mi tego usystematyzowania jak w przypadku kanału Johna, jednak jest to zdecydowanie jeden z topowych programowania. 123 / 147 kanałów do nauki

124 Oprócz programowania Derek uczy również gotowania niskokalorycznych dań. ;) Co do programowania, to na kanale znajdziecie następujące materiały: Kurs Javy Android Objective C PHP XML JavaScript Python SQL / SQL Lite / Mongo DB (bazy danych) WordPress Programowanie Obiektowe Ajax 124 / 147

125 NodeJS CSS Ruby on Rails JQuery Web Serwisy w PHP C GIT i pewnie trochę pominąłem To skarbnica wiedzy. Jednak należy te kursy traktować jako wstęp do samodzielnej nauki. Programowanie to przede wszystkim pisanie kodu źródłowego i samodzielne rozwiązywanie problemów. Żeby pisać, trzeba pisać nie popadaj w pułapkę ślepego przepisywania tutoriali. Postaraj się po paru tutorialach zastosować swoją wiedzą w prostym projekcie! KONIECZNIE! PHP Academy Kolejny świetny kanał YT: / 147

126 Od podstawie podstaw wielu PHP, przez praktycznych naukę frameworków przykładów. na Niesamowicie wartościowy kanał Krótkie i przyjemne wprowadzenie w Ruby (po polsku) Jeśli masz zamiar zainteresować się Ruby, to ten link jest świetny. Ruby w 20 minut: Dobra książka do C++ Przerabiałem częściowo następującą książkę i szczerze polecam: C++ Primer Plus. Polecam książkę jako solidne usystematyzowanie wiedzy. Osobiście nie lubię od takiej książki zaczynać: zawsze wolałem zobaczyć na filmie jak wszystko działa w akcji, a dopiero później przejść do książki. To moje podejście i powinieneś sam testować, 126 / 147

127 co działa w Twoim przypadku Najlepsze źródło informacji o nowinkach w androidzie Android Weekly Coś, co czytałem swojego czasu regularnie: Android Weekly. Świetny newsletter z linkami do najlepszych artykułów na temat androida. To wszystko? Istnieje wiele innych źródeł, ale postanowiłem wymienić tylko te, z których osobiście skorzystałem i mogę je z czystym sumieniem polecić. Mógłbym rozszerzyć listę przez proste googlanie najbardziej polecanych książek, ale po co? Lepiej wymienić mniej źródeł, z których faktycznie skorzystacie, niż pochwalić się długą listą, którą i tak większość z Was by zignorowała. Ale to prawie wszystko jest po angielsku 127 / 147

128 W jednej części książki mówiłem o tym, że język angielski to najważniejsza umiejętność u programisty. Bez niego uczysz się wolniej, mniej efektywnie i sporo tracisz na każdym kroku. Im wcześniej zaczniesz próbować korzystać z książek po angielsku, tym lepiej dla Ciebie. 128 / 147

129 12. Jak wygląda typowy tydzień pracy programisty? Początkowo chciałem nazwać tę część typowy dzień programisty, ale stwierdziłem, że typowy tydzień będzie lepszym pomysłem niż typowy dzień. Chciałbym Ci w ten sposób trochę rozjaśnić jakie problemy się pojawiają, jak się je rozwiązuje i dlaczego nie ma się na wszystko wpływu. Opisanie tutaj typowego tygodnia ma na celu zobrazowanie Ci realiów takiej pracy i przybliżenie paru codziennych problemów Planowanie, estymacja, meetingi Planowanie i estymacja (szacowanie jaki nakład pracy jest potrzebny na jakieś zadanie) zawsze muszą mieć miejsce. Zależnie od tego w jakim miejscu pracujecie i z jakim projektem macie do czynienia, może to wyglądać trochę inaczej: w Scrumie planowanie następnego sprintu (1, 2 lub 3 następne tygodnie pracy) odbywa się w pierwszy dzień sprintu, więc bardzo prawdopodobne, że co drugi poniedziałek spędzicie pół dnia na 129 / 147

130 planowanie co dalej w projekcie. Pół dnia to też dużo powiedziane: czasami może trwać to godzinę, dwie godziny. Wszystko zależy od stanu projektu. Jako programista będziesz wtedy rozbijał różne zadania na mniejsze kawałki, które można dzień po dniu wykonać. W trakcie tygodnia również mają miejsce meetingi do omawiania technicznej strony różnych zadań. Przyjmuje się, że jeśli programista 6 z 8 godzin może pracować nad kodem, to jest dobrze bardzo dobrze! 100% tygodnia roboczego praktycznie nigdy nie spędza się na programowaniu. W innych sposobach organizacji pracy również ma miejsce planowanie. Nie ominiesz tego, nawet jeśli bardzo tego 130 / 147

131 nie lubisz. Śmiało można założyć, że 1 dzień w tygodniu pracy programisty to planowanie/meetingi i inne sprawy organizacyjne. Dobrze jeśli jest to tylko jeden dzień codzienność bywa frustrująca Coś nagle nie działa i nie masz na to wpływu Gdy pracujesz w zespole osób, które dodatkowo współpracują z innymi zespołami, to zaczyna się budować wiele zależności. Łatwo wtedy o to, by coś przestało działać jak należy i nie masz na to wpływu. Zaczyna się wtedy chodzenie po zespołach i pytanie o sytuację. Zazwyczaj u wszystkich wszystko działa i sprawa nie jest taka banalna. Dobrym przykładem może być mock (taka atrapa danych/funkcjonalności, z której się korzysta póki coś nie jest do końca zaimplementowane), którego dostarczył nam kiedyś zespół BI. Tym mockiem były symulowane dane, które miał nam zwrócić webserwis. Przy okazji: warto byś poszukał czym są mocki/mockowanie w praktyce. Googlaj pod np. 131 / 147

132 mocking a web service java/c# mocking etc. Pod dostarczoną strukturę danych przygotowaliśmy dynamiczne UI. Po sprincie wszystko było cacy. Po tygodniu okazało się, że jeden z developerów zespołu BI nie dogadał się z drugim i zaczęliśmy dostawać dane o innej strukturze niż ta w mocku. W efekcie musieliśmy ponownie przysiąść do funkcjonalności, która była właściwie gotowa i odebrana przez product ownera ( Odebrana funkcjonalność to taka, która ma już otwartą drogę do nowej publicznej wersji produktu). Irytująca sytuacja, ale z czasem można przywyknąć. Zawsze zdarzy się moment, w którym coś nie będzie działało nie z Twojej winy i nie możesz za dużo z tym zrobić. Kwestia tylko kiedy. Podobnie zdarzy się, że komuś coś nie będzie działało przez Twój błąd. To też tylko kwestia czasu. Każdy człowiek popełnia błędy. Pamiętaj, by zawsze szukać rozwiązania, a nie winnego też kiedyś będziesz tym, który popsuł Zależności ciąg dalszy Zależności nie występują tylko wewnątrz zespołu/firmy. 132 / 147

133 Czasami (właściwie to aż za często ) korzysta się w projekcie z różnych zewnętrznych bibliotek. Wszystko jest super: mamy bibliotekę, która rozwiązuje jakiś problem i oszczędzamy dzięki niej wiele czasu, bo nie musimy czegoś sami implementować problem pojawia się, gdy technologia ulegnie zmianie (np. Android bardzo szybko się rozwija) i w nowych wersjach systemu pojawiają się błędy w działaniu oprogramowania. Miałem taki przypadek, gdy biblioteka do automatyzacji testów robolectric zaczęła sprawiać problemy na naszym serwerze testowym z nową wersją androida. Wymieniliśmy ją (bibliotekę robolectric) na inną i musieliśmy sporo przez to pozmieniać, ale było to konieczne, bo nie było pewności jak długo ta biblioteka będzie wspierana przez twórców co stanie się przy kolejnej nowej wersji i braku wsparcia? No właśnie :D Musisz się z tym liczyć podczas codziennej pracy w każdym typowym tygodniu może się pojawić taki problem. Czasami rozwiązanie okazuje się proste i traci się tylko parę godzin, ale widziałem przypadki, gdy brak dalszego wsparcia jakiejś zewnętrznej biblioteki kosztował tydzień programisty. Co warto z tego zapamiętać: Jeśli korzystasz z zewnętrznych bibliotek, to dbaj o 133 / 147 pracy

134 to, by były to zależności z solidnego źródła. Np. w przypadku Androida biblioteki firmy Square są bardzo solidne i godne zaufania Bugfixing / debugging szukanie i rozwiązywanie błędów Istnieje takie pojęcie jak Bug Sprint, czyli okres czasu, gdzie zajmujemy się tylko łataniem błędów. Mam nadzieję, że nie będziesz musiał za często w czymś takim uczestniczyć, bo jest to często bardzo męczące. Naprawieniem błędów będziesz się zajmował często. Trudno o tydzień, w którym tego nie będzie. Jak taka praca nad bugami zazwyczaj wygląda? Prawdopodobnie firma będzie posiadała jakiś system do zarządzania ticketami (np. Jira) i będziesz mógł sobie wybrać jakiś błąd do naprawy lub ktoś Ci konkretny błąd 134 / 147

135 przydzieli. W takim tickecie znajdziesz informacje na temat zgłoszonego błędu. Czasami zdarza się zgłoszenie, które nie jest bugiem, lecz błędem przy obsłudze (bo ktoś nie został właściwie przeszkolony, by korzystać z czegoś, albo jest leniwy lub zwyczajnie głupi). Jeśli dochodzisz do wniosku, że jest to faktyczny bug, to przechodzisz do szukania przyczyny. Dobra diagnoza, to już połowa sukcesu. Szukasz rozwiązania korzystając ze swojej wiedzy, doświadczenia i Googla. Implementujesz poprawkę i oddajesz ticket do przetestowania przez testera. Czasami problem jest marginalny i dosyć skomplikowany. Nakład pracy jest na tyle duży, a występuje na tyle rzadko, że świadomie decyduje się go nie naprawiać. Wtedy zamyka się takie zadanie jako Won t fix. Generalnie powinno się pracować tak, by bugi naprawiać na bieżąco i nie zaczynać nowej funkcjonalności, aż zdecydowana większość błędów nie zostanie naprawiona. Jednak w praktyce różnie z tym bywa :) 135 / 147

136 12.5. Czasami wszystko idzie gładko! Chyba trochę za bardzo straszę czytelników tym wszystkim. Jeśli wszystko jest w firmie dobrze zorganizowane, to czasami mija tydzień, podczas którego wszystko idzie gładko (i nawet kończymy robić coś przed zaplanowanym na to czasem!). Gdy masz już trochę więcej doświadczenia, to tygodnie zaczynają zlatywać na rzeczach, które już wiele razy robiłeś. Ewentualnie trafia się coś nowego, co jednak dzięki doświadczeniu sprawnie rozwiązujesz. Z jednej strony masz wtedy komfortową sytuację, bo jest mniej stresu (i to w całkiem fajnej i nieźle płatnej pracy), ale z drugiej strony cierpi wtedy Twój rozwój i zaczynasz się nudzić. Tygodnie, w których wszystko idzie jak po maśle, bywają po prostu nudne jednak wielu osobom to pasuje. Programista to w końcu praca jak każda inna, a nie żadne zajęcie dla nadludzi, jak to czasami część frustratów przedstawia Nauka w pracy Nikt nie jest wszystkowiedzący: w świecie szybkiego rozwoju nowych technologi częścią Twojej pracy jest nauka nauka w pracy. Nikt nie będzie od Ciebie wymagał, byś 136 / 147

137 obowiązkowo uczył się rzeczy po godzinach, a w pracy tylko implementował. Jeśli tak jest, to pomyśl nad zmianą firmy. W typowym tygodniu pojawią się reserach taski, gdzie będziesz musiał sporo poczytać i douczyć się różnych nowych rzeczy. Czasami będzie luźniejszy czas w projekcie/firmie, gdy np. coś nie jest na tyle opracowane przez ludzi od produktu, że programista ma trochę luzu i będziesz mógł zagospodarować czas przez poduczenie się w X, czy Y. Taki stan rzeczy raportuje się wtedy jako samodoskonalenie/nauka technologii etc. Tzn. jeśli musisz jakoś raportować. Wiele firm od tego odchodzi, bo to marnotrawienie czasu raportującego i osoby, które taki raport kontroluje (o ile ktokolwiek to robi ). Generalnie często spotyka się podejście, że albo ufa się pracownikowi, albo się z takim człowiekiem nie pracuje. Często u mnie bywało, że parę dni pracy mogłem poświęcić na naukę i pracę nad prototypem jakiegoś rozwiązania. To zdecydowanie najlepsza część tej pracy. Jednak na takie zaufanie trzeba sobie zapracować. Jeśli dasz się poznać jako solidna i kompetentna osoba, to zdziwisz się ile wolności możesz dostać wewnątrz firmy, by testować różne rozwiązania i poświęcać czas na reserach. Długofalowo takie coś się po prostu dla firmy opłaca. 137 / 147

138 12.7. Krótkie podsumowanie typowego tygodnia Podsumowanie: z czego składa się tydzień programisty: Przygotuj się na sporą dawkę meetingów, na których wiele tematów nie będzie bezpośrednio związane z tym, co robisz w projekcie. Pojawią się problemy z zewnątrz: ktoś coś popsuje, albo Ty coś popsujesz: szukaj rozwiązania, a nie winnego. Część pracy sobie ułatwisz przez gotowe biblioteki. Jednak korzystaj z nich rozważnie, bo mogą zacząć sprawiać problemy. Naprawienie błędów (bugfixing) to prawie codzienność: czasem zgłoszony błąd nie jest błędem, a czasami błąd jest na tyle marginalny, że nie jest wart potencjalnego nakładu pracy. Bywa i tak, że idzie gładko! Wkrada się wtedy nuda, ale zatęsknisz za tą nudą, gdy coś się poważnie popsuje. Część czasu w pracy to nauka. Nauka, za którą Ci płacą. Każdy tydzień to mieszanka powyższych punktów. Implementacja funkcjonalności, naprawienie tego co się popsuło, 138 / 147

139 ciągła nauka i nieskończona seria meetingów. Koniec końców jest podobnie jak w wielu innych zawodach nie oczekuj tutaj cudów i implementowania zawsze samych ciekawych rzeczy. 139 / 147

140 13. Jesteś gotowy do pierwszej pracy? Pytania Jako ostatni rozdział przygotowałem listę pytań, na które warto sobie odpowiedzieć, zamiast wysyłać do mnie maila z pytaniem czy jestem już gotowy, by aplikować do pierwszej pracy jako programista?. Do każdego pytania dodałem też przykładową odpowiedź. Jesteś w stanie zrozumieć angielskojęzyczną dokumentację dowolnej biblioteki? Odp: Tak, do wielu małych projektów podpinałem różne biblioteki, które wykorzystałem po przeczytaniu dokumentacji. Czy intuicyjnie wiesz, czego szukać, jeśli musisz zaimplementować coś, z czym nie miałeś wcześniej styczności? Odp: Tak. Zazwyczaj szukam prostych, praktycznych przykładów, czytam kod i później w razie potrzeby doczytam teorię, którą lepiej rozumiem po styczności z przykładem. Czy potrafisz samodzielnie organizować swoją pracę, by pracować efektywnie? 140 / 147

141 Odp: Tak. Zanim zacznę pisać kod źródłowy, rozpisuję sobie całość z grubsza na papierze i rozbijam na mniejsze kroki. Gdy nie wiem co dalej, staram się poszukać rozwiązania w sieci i gdy nie znajdę nic sensownego, wtedy pytam kolegów. Czy napisałeś jakiś projekt do końca, by można krótko omówić, przedstawić jakieś problemy, które się pojawiły etc.? Odp: Tak, napisałem wykorzystałem aplikację technologie mobilną, pozwalające w której ponownie wykorzystać kod źródłowy pod różne systemy operacyjne. Największym problemem była konfiguracja xcode pod ios i połączenie tego z pluginem w Eclipse (plugin w Eclipse korzystał z lokalnych plików, które wygenerowało xcode). Podczas projektu stosowałem narzędzia do kontroli wersji (git) i mam dzięki temu sporo praktycznego doświadczenia z Gitem. Przy okazji wyjaśnię, bo możesz nie wiedzieć czym jest plugin/wtyczka, to dodatek do oprogramowania. Możesz np. zainstalować wtyczkę, do Twojego IDE, by wewnątrz IDE korzystać z Git-a. Czy zapisywałeś/czytałeś dane z/do jakiegoś typu plików? 141 / 147

142 Odp: Tak, pisałem aplikację, która pobiera dane z plików.csv i generuje raporty w formacie pdf. Czy masz doświadczenie w pracy z bazą danych? Odp: Tak, pisałem już parę aplikacji webowych, które korzystały z bazy MySQL. Potrafię poruszać się w bazie danych, ale nie jest to dziedzina (bazy danych), w której się specjalizuję. Czy masz jakieś doświadczenia z technologiami webowymi? Odp: Tak, stworzyłem parę prostych stron www oraz wykorzystywałem jquery do pobierania danych z webserwisów. Czy znasz najważniejsze protokoły sieciowe i czy stosowałeś któryś z nich? Odp: Tak, pisałem aplikacje na Androida, które korzystały z webserwisów wykorzystując protokół HTTP. Jak z programowaniem obiektowym? Wiesz czym różni się np. (w przypadku Javy) interfejs od klasy abstrakcyjnej? Odp: Stosowałem już programowanie obiektowe w praktyce. Odnośnie pytania o interfejs i klasę abstrakcyjną: w interfejsach nie mamy ciał metod (które 142 / 147

143 mogą, ale nie muszą być obecne w klasie abstrakcyjnej), klasa abstrakcyjna może implementować wiele interfejsów, ale dziedziczyć tylko jedną klasę abstrakcyjną (w Javie, w C++ można dziedziczyć po wielu klasach). Na miejsce pytania z interfejsem i klasą abstrakcyjną możesz poszukać sobie w sieci dowolne pytania związane z obiektowością i programowaniem obiektowym w języku, który wybrałeś. Czy pisałeś własny lub korzystałeś z webserwisu? Odp: Jedno i drugie: napisałem prosty webserwis, który pobiera dane z bazy danych i napisałem aplikację mobilną, która korzysta z tego webserwisu. Wiesz czym są testy jednostkowe? Odp: Tak, podnoszą one długofalowo jakość kodu. Pozwalają wykryć, czy kod jest kiepskiej jakości jeśli trudno napisać testy pod dany kod, to znak, że mógł zostać lepiej przemyślany. Potrafisz korzystać z danych dostarczonych w formacie json lub xml? Odp: Tak, webserwisy, które dostarczały mi dane, dostarczały mi dane w formacie xml i musiałem je 143 / 147

144 samodzielnie parsować. Czy korzystałeś kiedyś z narzędzi do kontroli wersji? Odp: Tak, we wszystkich projektach (również w tych pisanych w ramach nauki) stosowałem Gita. Oto lista do projektów na Githubie. W jakim IDE sprawnie się poruszasz? Odp: Eclipse oraz IntelliJ. Spędziłem w nich sporo godzin i stosuję skróty usprawniające moją pracę Podsumowanie Jeśli potrafisz sobie szczerze odpowiedzieć na powyższe pytania, to powinieneś być gotowy, by zacząć poszukiwania pierwszej pracy jako programista. Podchodź do rekrutacji jak do nauki: z każdą rozmową dowiesz się więcej (czego szukają na stanowisku, które Cię interesuje itp.) i pozwoli to lepiej ukierunkować Twoją naukę w przypadku niepowodzenia. Znacznie lepiej jest chodzić na rozmowy za wcześnie i dowiedzieć się czego mamy się douczyć, niż zacząć chodzić za późno i zmarnować parę miesięcy na naukę czegoś bezcelowego. 144 / 147

145 Wiem, że to brzmi jak straszny banał typu cytat Paulo Coelho, ale sam zmarnowałem tak sporo czasu i żałuję, że nie zacząłem wcześniej chodzić na rozmowy kwalifikacyjne. 145 / 147

146 14. Co dalej? Parę słów na koniec. Mam nadzieję, że nie zanudziłem Cię na śmierć i wyniosłeś coś z tej książki. Pamiętam, że zawsze jak kupowałem książkę, to zaczynałem od czytania zakończenia książki. Ciekawe czy oprócz mnie też ktoś tak robi Co dalej? Jeśli wszystko o czym wspomniałem jest dla Ciebie powoli zrozumiałe i zrobiłeś parę projektów w ramach nauki, to możesz zacząć bawić się w rekrutację do różnych firm. Tylko w ten sposób skonfrontujesz się z rzeczywistością i dostaniesz informacje, co było nie tak i będziesz wiedział czego się poduczyć. Zawsze możesz spróbować ponownie za parę miesięcy, czy pół roku. Bez paniki. Ostatecznie może zdecydujesz, że to nie jest praca dla Ciebie. Jest wielu programistów, którzy programują tylko w ramach hobby i profitują z takimi umiejętnościami w innych zawodach. Czas poświęcony na sensowne poszerzanie swoich horyzontów nigdy nie jest czasem zmarnowanym. Jeśli przeczytałeś całość od deski do deski, to podeślij mi 146 / 147

147 krótką wiadomość z opinią na Facebooku, Twitterze lub na maila: Matt@JavaDevMatt.pl. Albo na jakiejkolwiek platformie, która jest aktualnie popularna w końcu 10 lat temu (2006 aktualnie jak to piszę jest 2016) popularny był MySpace, a wiemy jak skończył. Ewentualnie podeślij jakiegoś zmutowanego gołębia pocztowego, jeśli nadszedł czas apokalipsy, a Ty jakimś cudem czytasz tę treść na swoim Pip-Boyu. Jeśli gołębia nie zjedzą mutanty, to postaram się odpisać. 147 / 147