PAWEŁ STREJCZEK

Kwestie związane z rozpoczęciem nauki programowania są ostatnimi czasy niezwykle popularne w polskiej blogosferze IT i generalnie nie ma w tym nic dziwnego. W dzisiejszych czasach zawód programisty obrósł w wiele mitów. Mainstream-owe media wprost kreują programistów na kastę bogaczy, stawiając w jednym rzędzie z lekarzami, prawnikami itp. (LEKKI OFFTOP: żeby się przekonać ile w tym prawdy, polecam popatrzyć np. ile samochodów klasy premium zobaczymy pod hotelem, w którym odbywa się sympozjum lekarskie lub spotkanie dużej firmy z branży farmaceutycznej, a ile w miejscu gdzie odbywa się konferencja programistyczna). Wielu chce więc zostać programistami zostać, bo przecież fajnie posiedzieć przy dobrym kompie w klimatyzowanym biurze i za poklikanie i postukanie w klawiaturę skosić gruby hajs. Jakieś ziarnko prawdy w tym jest, ale tylko ziarnko.

Nie o mitach będzie jednak dzisiaj a o podejściu do nauki programowania.

Na początek – o moich początkach 🙂

Kiedy ja zaczynałem przygodę z programowaniem (będąc nastolatkiem, a nawet wcześniej) – istniała w zasadzie jedna droga.  Po zdobyciu upragnionej, dobrej książki do programowania w danym języku (co często było wtedy ekstremalnie trudne) i jej przewertowaniu trzeba było razem z nią zasiąść do klawiatury i metodą prób i błędów próbować coś stworzyć. Alternatywnie, w wydawanych wtedy czasopismach takich jak np. Bajtek, można było znaleźć wydrukowane listingi programów i gier, które należało skrzętnie „przeklepać” i ucieszyć się że działa, lub też spędzić godziny analizując znak po znaku, gdzie zrobiło się błąd. Później można było się bawić w modyfikacje pewnych fragmentów kodu obserwując jakie zmiany udało się uzyskać i próbować zrozumieć czemu stało się tak, a nie inaczej. Wybór dostępnych języków też był znacznie mniejszy. Poza BASIC-iem, było C a dla hardkorowców Assembler.

Jak ja się uczyłem ? Dokładnie tak jak opisałem powyżej. Podstawy podstaw w Basic-u pokazał mi Tato (który też przyniósł do domu pierwsze ZX Spectrum) ale przyznam szczerze, że w czasach ZX Spectrum interesowałem się tylko graniem w gry. Pierwszym językiem, który opanowałem dość dobrze był QBasic. Być może niektórzy z Was pamiętają, że nieco okrojona wersja tego języka była dostępna (wraz z prostym IDE) jako integralna część MSDos od wersji bodajże 5.0. Co ważniejsze, do QBasica dołączone były dwie proste gry (Gorillas – w której byliśmy gorylem stojącym na dachu wieżowca, i za pomocą banana, któremu nadawaliśmy kąt i prędkość mieliśmy „ubić” drugiego goryla, oraz Nibbles – który był po prostu grą Snake) wraz z kodem źródłowym. Bardzo dużo czasu spędziłem grzebiąc w kodzie tych gier modyfikując je na różne sposoby. Ponieważ w IDE QBasica dostępny był bardzo dobry Help, szybko udało mi się stworzyć swoje pierwsze proste programy i jakieś gry tekstowe.

Potem przyszedł czas na Pascala i C, ale było już dużo łatwiej. Po wcześniejszych doświadczeniach z Basic-iem nie miałem problemu ze zrozumieniem czym jest zmienna, pętla czy instrukcje warunkowe. QBasic był też na tyle zaawansowanym dialektem Basica, że posiadał możliwość tworzenia funkcji. Zrozumiałem więc też stosunkowo łatwo, jak wygląda sprawa organizacji kodu w programowaniu proceduralnym i nie miałem większych problemów z zastosowaniem tego w innych językach.

Potem był Turbo Pascal for Windows (tak tak, było takie dziwadło), Delphi, C++ i Visual C++ z MFC, PHP, C# itp. itd. Języków uczę się nadal. W tej chwili np. wróciłem do Ruby i ROR, które lekko „liznąłem” w okolicach 2006 roku, a który okazuje się całkiem fajnym rozwiązaniem i zabawa z nim daje mi dużo frajdy. Rozwijam też wiedzę z zakresu Javascript – pamiętam doskonale, gdy był to język do tworzenia głupich animacji na prostych stronach i przez wiele lat traktowałem go bardzo po macoszemu. Zainteresowałem się też mocno chmurą publiczną.

Jak jest dzisiaj ?

Z jednej strony można by powiedzieć, że bajka. Dostępne jest multum literatury fachowej dla mniej i bardziej zaawansowanych. Mamy internet – nieprzebraną kopalnię informacji w postaci blogów, for internetowych i innych stackoverflow-ów. Można skorzystać z kursów online (video, czy tekstowych) lub zapisać się na kurs albo warsztaty „na żywo”. Dostępne są również różnego rodzaju bootcamp-y. Są też intensywne, kilkumiesięczne szkolenia w szkołach programowania. W końcu mamy też strony takie jak codecademy czy freecodecamp, gdzie uczymy się w sposób interaktywny.

Czy jest łatwiej ? No niestety moim zdaniem nie jest. Tak jak kiedyś cierpieliśmy na duży niedosyt jakichkolwiek materiałów i każdą zdobytą książkę, czy egzemplarz czasopisma traktowaliśmy niemal jak relikwię – tak dzisiaj mamy przesyt wszystkiego. Pytanie tylko, czy przeklikanie się przez kurs interaktywny, oglądnięcie kilku godzin kursu video czy nawet udział w intensywnym szkoleniu, gdzie jesteśmy prowadzeni za rękę, zrobi z nas programistę ? Chyba jednak nie do końca …

Konia z rzędem, temu który oglądnie jeden, dwa kursy o programowaniu w Javie aplikacji Androidowych, a potem usiądzie do pustego IDE i strzeli od ręki fajną aplikację.

Wiele dzisiaj się mówi o dobrych praktykach programowania, o testach, o wzorcach. I tak – jest to ważna i potrzebna wiedza – ale nie na początku nauki. Na początku lepiej o tym wszystkim nie wiedzieć nic (poza tym, że coś takiego istnieje).

Programowanie jest umiejętnością, a nie wiedzą encyklopedyczną. Jazdy na łyżwach nie nauczymy się z książki. Trzeba wejść na lód, wywalić się wiele razy, poobserwować innych, czasem posłuchać co inni podpowiedzą i najpierw nauczyć się jeździć dookoła lodowiska blisko bandy, a dopiero po nabraniu pewności siebie próbować przekładanki. Nie inaczej jest z programowaniem.

Jakie miałbym rady dla początkujących ?

Cóż … mówi się, że z racją jest jak z d..ą, każdy ma swoją. Poniżej kilka moich rad, które sprawdziły się (lub sprawdzają nadal) u mnie i które pewnie sam chciałbym usłyszeć gdybym dzisiaj startował z nauką programowania od zera. Apeluję jednak do nie traktowania ich Ex Cathedra. To co działa u mnie, nie koniecznie musi działać u Ciebie. Ostatecznie „one man’s cure is another man’s poison„.

Dobra. Jadziem.

1. Znajdź motywację. I nie, kasa to nie jest dobra motywacja. Zanim osiągniesz poziom, w którym będziesz mógł pobierać opłaty za swoją pracę i ktoś będzie chciał Cię zatrudnić minie całkiem sporo czasu. Ja uczyłem się programowania bo chciałem pisać gry. Dzisiaj uczę się dalej pod kątem moich własnych projektów, które chcę realizować. Owszem, czasem trzeba (a nawet jest bardzo wskazane) pogłębiać wiedzę pracując nad projektem klienta lub pracodawcy, ale dzisiaj rozmawiamy o początkach nauki. Silna motywacja jest bardzo potrzebna – zdobywanie jakiejkolwiek umiejętności wymaga wytrwałości i cierpliwości
2. Wybierz język jaki chcesz. Podoba Ci się Javascript bo jest popularny i wszechstronny ? – pisz w Javascript. Podoba Ci się Python bo kolega programuje w Python-ie ? – Pisz w Pythonie. Chcesz tworzyć gry w Unity a tam używa się C# ? – pisz w C#. Na tym etapie język nie ma większego znaczenia. Po osiągnięciu pewnego poziomu doświadczenia nauka każdego kolejnego języka jest szybsza i prostsza.
3. Rozważnie dobieraj materiały. Na początku nie potrzebujesz 5000-stronicowej książki ani 30-godzinnego kursu za pierdyliard złotych. Po ich przerobieniu nie będziesz wiedział dużo więcej niż wiesz teraz a portfel będzie sporo chudszy. Usiądziesz do klawiatury a w głowie pojawi się pustka. Poszukaj czegoś, co pozwoli poznać Ci kompletne podstawy języka, który wybrałeś. Książki i kursy traktuj encyklopedycznie, nie czytaj i nie oglądaj od deski do deski. Zaglądaj, gdy brakuje Ci wiedzy jak coś zrobić.
4. Samodzielnie wymyślaj projekty, które chcesz realizować i od razu stawiaj sobie poprzeczkę wysoko. Z jednej strony pozwala to utrzymać motywację (piszemy co chcemy), z drugiej wymaga od nas dużo główkowania i wykonywania research-u – podstawowych umiejętności programisty. Napisałeś już „Hello World” i program wyświetlający wpisane wcześniej w konsoli imię i nazwisko ? To napisz teraz oldschoolowe, tekstowe RPG. Nauczysz się czegoś o instrukcjach warunkowych, pętlach … a może teksty wyświetlane graczowi będziesz chciał np. przechowywać na dysku w plikach tekstowych ? Tyle przydatnej wiedzy, a jednocześnie powstanie Twoja własna fajna gra.
5. Kończ projekty, pisz działający kod. Tego będą od Ciebie kiedyś wymagać klienci lub pracodawca. Chcesz pracować nad własnym produktem ? Super ! Ale nie sprzedasz nikomu czegoś co nie działa (tzn. sprzedać to może sprzedasz, ale g..noburza, która się potem może rozpętać nie jest tego warta). Poza tym, każdy skończony własny projekt to +10 do motywacji do dalszego działania i coś czym możemy się pochwalić przed innymi.
6. Zanim zapytasz – próbuj sam. Wiedza zdobyta przez doświadczenie zostaje w głowie na zawsze. Jak skopiujesz kawałek kodu ze stackoverflow, albo jak kolega napisze kawałek kodu za Ciebie to nie zdobędziesz żadnego doświadczenia. Pytaj jeżeli jesteś w kropce i nie wiesz jak ruszyć dalej – kto pyta nie błądzi.
7.  TDD, SOLID, DDD, BDD. Widziałeś/łaś gdzieś te skróty, ale nie wiesz co oznaczają ? To się nimi nie przejmuj. Na to przyjdzie jeszcze czas. Szkoda tracić czas na czytanie o zasadach SOLID, jeżeli nie wiesz jak działa pętla albo nie wiesz czym różni się klasa od obiektu. Ty póki co pisz kod, który będzie działał.
8. Testy jednostkowe i kontrola wersji. No oczywiście trzeba mieć o tym pojęcie, szczególnie jeżeli aplikujemy do pracy. Ale Ty się tym teraz nie przejmuj. Nie da się zrobić 5-rzeczy na raz i na nic jest Ci dobra znajomość Git-a, jeżeli nie masz co wrzucić do repozytorium. Podstawy Git-a warto oczywiście opanować już na początku, ale spokojnie wystarczy tylko zrozumimeć z grubsza jak to działa i skorzystać z jakiegoś okienkowego klienta.
9. Pochwal się tym co zrobiłeś. Wklej screena na Facebooku albo Twitterze. Napisz co zrobiłeś. Jeżeli posiadasz konto na githubie – wrzuć tam swój kod. Napewno część znajomych będzie Ci kibicować, a to kolejne +10 do motywacji.
10. Po przerobieniu kawałka kursu, przeczytaniu kawałka książki i kilkunastu godzinach walki z kodem czujesz się znudzony, zrezygnowany i żygać Ci się chce jak patrzysz na swoje IDE ? Może programowanie nie jest dla Ciebie. Nie ma żadnego wstydu w tym, żeby odpuścić i zająć się czymś innym. Wbrew temu co lansują teraz media – nie każdy musi umieć programować.

I to pewnie tyle. Zdaje sobie sprawę, że część tych punktów jest może nieco kontrowersyjna, starałem się jednak postawić w sytuacji osoby „zielonej” jeżeli chodzi o programowanie. Często spotyka się pytania różnych początkujących na forach dyskusyjnych pod tytułem „Jak zacząć”, „Jaki język” itp. I bardzo często w odpowiedzi znajdziemy: „Koniecznie naucz się Javascript i HTML i CSS i C# i Java no i musisz się nauczyć pisać testy, bo bez testów to ani rusz, no i stosuj TDD i koniecznie musisz od razu znać zasady SOLID i musisz używać Git-a, nawet jeżeli piszesz swoje projekty szkoleniowe – i koniecznie używaj Git-a tylko z konsoli”. I to nie jest moim zdaniem dobra droga dla początkującego, tylko plan nauki rozpisany na kilka lat, który powoduje totalny mętlik w głowie – a przecież nie o to chodzi.

Zainteresowanym zawodem programisty polecam też książkę Macieja Aniserowicza „Zawód programista”. Jest tam sporo fajnych informacji, z którymi warto się zapoznać jeżeli planujemy programować zawodowo.

Podkarpacka konferencja RzemiosłoIT odbyła się 26 maja 2018 już po raz drugi i po raz drugi miałem przyjemność brać w niej udział.

W zeszłym roku zebrałem garść wrażeń i opisałem je na blogu. W tym roku nie będzie inaczej.

Podkarpacki Park Naukowo-Techniczny po raz drugi ugościł uczestników konferencji. Wybór miejsca, przynajmniej z mojego punktu widzenia, jest doskonały. Bardzo dobre połączenie z autostradą i duży parking są zdecydowanie atutem z punktu widzenia zmotoryzowanych. Organizacja konferencji w sobotę ma zapewne swoje plusy i minusy, jednak z mojego punktu widzenia ułatwia to mocno wpisanie jej dużo wcześniej w kalendarz – raczej na pewno nie koliduje wtedy z obowiązkami zawodowymi.

Od strony logistycznej konferencja zorganizowana była równie dobrze jak w zeszłym roku – chłopaki i dziewczyny z Rzeszowa wszystko dopinają na ostatni guzik 🙂

PRELEKCJE

Keynote tym razem należał do Macieja Aniserowicza, osoby której chyba nikomu w światku IT przedstawiać nie trzeba. Po raz pierwszy widziałem Macieja na żywo na scenie i czułem się troszkę jakbym oglądał jego vlog-a live – ten sam fajny bezpośredni język i szczerość (taką mam przynajmniej nadzieję 🙂 ). Sama treść prezentacji „Szczęśliwy programista? Kluczowe wskazówki do udanej kariery w IT” zawierała bardzo dużo treści, które można przeczytać w książkach Maćka lub posłuchać/pooglądać na Jego vlogu. Na żywo jednak, podbudowane ładunkiem emocjonalnym treści związane z wypaleniem zawodowym i jego skutkami, jak i problemami natury psychologicznej, z którymi trzeba się czasami zmierzyć nabierają „ciężaru” obok którego trudno jest przejść obojętnie. Prezentacja „zjadła mnie” na tyle, że nie zrobiłem sobie nawet fotki Maćka na scenie a i zmusiła do pewnych przemyśleń, które odkładałem do tej pory skrzętnie na później.

Mariusz Gil w prezentacji „Thinking in Events” zaprezentował tematykę związaną ze zdarzeniami w kontekście Event Storming. Bardzo ciekawa prezentacja, sporo technicznego mięcha popartego fajnym przykładem, w którym udział brali również uczestnicy konferencji generując zdarzenia w aplikacji Mariusza. To bardzo ciekawa tematyka i będę się ją starał w mniejszym lub większym stopniu w najbliżyszm czasie eksplorować.

Następnie dokonany został podział prezentacji na dwie sale i siłą rzeczy nie udało mi się być na wszystkich. Mam nadzieję, że oglądnę prezentacje na których nie byłem na kanale RzemiosłoIT w późniejszym czasie. Póki co, dostępny jest tam zapis streamu z konferencji.

Jarosław Pałka zrezygnował z tematu „Sagi, strumienie, reaktywność i inne buzzwordy” deklarowanego w Agendzie, na rzecz zupełnie nowego tematu „Why we are all doomed” :). Była to premiera tej prezentacji. Jarek jest na tyle doświadczonym prelegentem, łapiącym świetny kontakt  z publicznością, że nie dało się odczuć że prezentacja jest „świeża” – pełna profeska. Cała prezentacja to taka duża refleksja, na temat tego jak daleko jesteśmy od „blachy” pisząc kod w językach wysokiego poziomu uruchamianych przez mniej lub bardziej zaawansowane wirtualne maszyny i środowiska uruchomieniowe. Kiedyś sam miałem trochę podobnych przemyśleń, jak wiele zależy tak naprawdę nie od nas a od autorów narzędzia czy środowiska, z którego korzystamy – Jarek bardzo fajnie zebrał to w całość i bardzo przekonująco przedstawił. Ja zaczynałem swoją przygotę z programowaniem od ZX Spectrum a potem z Pascalem i C, więc pewne rzeczy ciągle mam z „tyłu głowy”, ale zdaję sobie sprawę, że dla ludzi którzy przygodę rozpoczęli np. od PHP i siedzą ciągle w webdevelopmencie kwestie związane z zarządzaniem pamięcią mogą być nieco abstrakcyjne.

Lighting talks, które odbywały się w jednej z sal jako kolejne i w których wziąłem udział nie były do końca tym czego się spodziewałem. Myślałem, że będą to krótkie wystąpienia ale bardziej związane z samą tematyką konferencji – software craftmanship. Prezentacje dotyczyły jednak 3 rzeszowskich startup-ów. Najbardziej zainteresował mnie startup AIRDURANCE. Bardzo ciekawa konstrukcja dronów – latających skrzydeł – pionowego startu o dość sporych możliwościach. Projekt rozwijany jest w inkubatorze Samsunga. Życzę chłopakom jak najlepiej – bo projekt jest naprawdę bardzo ciekawy i może znaleźć szerokie zastosowanie. Swoje prezentacje przedstawili również przedstawiciele startupów CinematicVR oraz ExtraINHotel.

Szymon Warda przedstawił bardzo ciekawe case study optymalizacji kosztów uruchomienia systemu o dość proste architekturze na Azure w prezentacji zatytułowanej „Azure for less than one dollar a day”. Krok po kroku, przedstawiał różne metody optymalizacji funkcjonalności wymaganych w projekcie tak, aby osiągnąć tytułowego niecałego dolara dziennie za funkcjonujące rozwiązanie. Tematyka chmury nie jest mi obca, po dwóch kursach w szkolachmury i trochę zabawy na własną rękę coś na ten temat wiem. Zaskoczyło mnie jednak to, że często bardziej finansowo opłaca się skorzystać w Azure z usług starszych, oferowanych od dawna, bo w pewnych przypadkach okazują się tańsze przy zachowaniu nadal wymaganych przez projekt funkcjonalności.

Konferencja miała się zakończyć prezentacją Jakuba Mrugalskiego. Jakub jednak nie dojechał i zamiast ostatniej prezentacji zorganizowano panel dyskusyjny poświęcony fuck-upom na produkcji :). W panelu wzięli udział: Jarek Pałka, Mariusz Gil, Konrad Kaplita i Michał Sondej. Jarek moderował całą dyskusję i przy okazji dostarczył chyba najwięcej różnego rodzaju fuckupowych smaczków :). Jest coś takiego w naszej naturze, że lubimy posłuchać jak to bardzo się innym czasem nie udaje … Panel wyszedł świetnie i był jednym z fajniejszych fragmentów konferencji.

PODSUMOWANIE

Gdybym miał porównać tą konferencję do zeszłorocznej to pod każdym względem było tak samo dobrze, jeżeli nie lepiej. Żałuję tylko, że prezentacje Jarka Pałki i Piotra Stapp-a oraz prezentacje Konrada Kaplity i Szymona Wardy odbywały się w tym samym czasie. Mam nadzieję to jednak nadrobić oglądając nagrania.

Było świetnie i z niecierpliwością czekam już na kolejną edycję w przyszłym roku.