12 mitw i bdw

spotykanych w pracy
programisty
W temacie mitw i bdw w pracy programisty powstao ju wiele artykuw i nagra, ale
podejrzewam, e ten temat nigdy nie zostanie wyczerpany.
Ciekawie opisa to JavaDevMatt i wielu innych autorw, ale myl, e warto tutaj dorzuci swoje 3
grosze i zebra to wszystko w cao.
Ten artyku pisz te dla samego siebie. Bdc programist bardzo atwo wpa w gupie
nawyki typu ten kod musi by idealny.
Kod ma dziaa poprawnie, ma by szybki i dobrze zorganizowany, eby kady, kto bdzie z nim
pracowa, mia uatwione zadanie i nie musia si zastanawia co tu si k dzieje.
Perfekcjonizm w tej brany polecam woy midzy bajki. Dugofalowo powoduje on wicej
problemw ni daje korzyci. Done is better than perfect.

Mogoby si wydawa, e ja autor ju to wszystko wiem, ale i tak czasami zdarza mi si

siedzie zbyt dugo nad problemem czy szuka idealnego rozwizania, nawet gdy to aktualne jest
w porzdku.
Zapraszam wic do mitw i bdw, ktre mog popenia programici na kadym szczeblu
kariery.

Mit 1. Naucz si raz i to wystarczy

Jeli chcesz pracowa z takim podejciem, to najlepiej bdzie zmieni bran. Zawd programisty
to niekoczca si opowie pena nowych jzykw, technologii i wyzwa.
W IT nie da si nauczy jakiej technologii raz, a potem korzysta z tego przez rok, bez
zagldania do dokumentacji. Zbyt szybko to wszystko si zmienia.
W samym Front Endzie mamy teraz wielki bum na JavaScript i wszelkie narzdzia z nim
zwizane.
W pracy moesz wykorzystywa podstawy JavaScriptu, frameworki JS (np. React, Vue, Angular),
preprocesory CSS (np. Sass, Less), frameworki CSS (np. Bootstrap, Foundation), automatyzacj
zada (Grunt, Gulp), bundlery (Browserify, Webpack) itd.Lubi to
Jest tego duo i szybko si to zmienia, co dla niektrych moe by frustrujce. Jednego dnia
poznajesz jaki framework, a za miesic wychodz 2 kolejne.
Ta brana ju tak ma i tego nie zmienisz. Warto wic mie odpowiednie podejcie i uczy si
regularnie. Lepiej rozoy nauk na mniejsze czci, ale robi to systematycznie, eby unikn
potem przytoczenia nowymi technologiami.
W taki sposb buduje si nawyk, ktry jest duo lepszy od tzw. motywacji, ktra jest w
dzisiejszych czasach tak mocno pompowana przez rnych guru rozwoju osobistego. Motywacja
moe i jest pomocna, ale na pocztku.
Motyw + akcja = dlaczego chcesz to zrobi?
Znajd sobie jaki konkretny powd, a organizm sam da Ci motywacj. To takie proste. Nie
musisz wciska sobie do gowy formuek typu zawsze i wszdzie moesz wszystko.
Motywacja jest krtkotrwaa, a dopiero nawyk sprawi, e bdziesz wytrwale dziaa (na
automacie), rozoysz problem na czci i choby rozwizanie go miao zaj Ci miesic, to i tak
to zrobisz.

Mit 2. Jestem zdany tylko na siebie i nikt mi

nie pomoe
W przypadku freelancingu moe tak by, ale bdc na etacie (lub po prostu pracujc w jakiej
firmie na miejscu) jeste czonkiem zespou.
Nikt nie jest idealny, ale mona bardzo dobrze wsppracowa w zespole, w ktrym kady si
uzupenia. Jeden lubi JavaScript, drugi WordPressa, a trzeci zajmuje si Back Endem i serwerami.
Czsto zakres tej wiedzy jest tak szeroki, e prawdopodobnie w Twoim zespole jest ju osoba,
ktra albo poradzia sobie z Twoim problemem, albo przynajmniej wie jak si do niego zabra.
Wystarczy zapyta.

Mit 3. Nie jestem wystarczajco dobry,

eby
poprosi o podwyk, dosta awans, zacz poznawa now technologi wpisz tutaj
cokolwiek.
Chodzi o porwnywanie si z innymi ludmi. To moe sprawi, e bdziesz czu si albo lepszy,
albo gorszy. Podejrzewam, e czciej jednak to drugie.
Bez wzgldu na to, co podpowiada Ci gowa, praktycznie zawsze jest tak, e jeste lepszy ni Ci
si wydaje, a wszystkie te ze myli nie maj sensu.
Wyobra sobie, e programista z 10-letnim staem nagle wkrci sobie, e ja nie nadaj si na
to stanowisko, bo nie znam technologii X. Kompletnie zapomina o tym, e przez 10 lat pracy
zrobi mas innych, trudniejszych rzeczy, a nauka tej technologii zajmie mu moe tydzie.
Szkoda czasu na takie zamartwianie, lepiej skupi si na pozytywnych aspektach tego zawodu.
Kady, nawet pocztkujcy ma spore szanse na znalezienie ciekawej pracy, bo rynek rozwija si
w takim tempie, e cay czas mamy niedobr specjalistw. Liczy si dowiadczenie, wic nie
moesz siedzie na tyku i czeka, ale raczej programowa, tworzy wasne projekty i skada
CV :)
Zreszt, szacuje si, e do 2020 roku bdzie brakowao ok. 1 miliona programistw na
rynku. Szkoda tego nie wykorzysta!

Mit 4. (pocztkujcy) Musz zna dobrze

matematyk, a najlepiej skoczy studia
informatyczne
eby cokolwiek znaczy w tej brany.
Kolejny mit, tak samo jak mit informatyka, ktry siedzi w koszuli w kratk, pije litrami Coca-Col,
mieszka w piwnicy i myje si raz na tydzie.
Wszystko zaley od tego, gdzie i z kim pracujesz. W typowej pracy wikszo czasu spdzisz
na pisaniu kodu, zamiast na rozgryzaniu funkcji matematycznych, bo w zdecydowanej
wikszoci przypadkw wystarcz Ci podstawy matematyki.
W momencie gdy bdziesz chcia wykona jakie skomplikowane obliczenia czy narysowa sobie
diagram wystarczy pobra jedn z setek gotowych bibliotek, ktre zrobi to za Ciebie.
Sytuacja wyglda inaczej, gdy Twoje stanowisko bdzie wymagao zaawansowanej matematyki
czy fizyki, ale nawet tutaj jest duo gotowych rozwiza, ktre wystarczy wykorzysta w
projekcie.

Mit 5. Musz wszystko zapamita

Ze szkoy pewnie wiesz, e zapamitywanie na si nic nie daje. To jedna z tych cudownych
metod, ktrych uywaj nauczyciele w wielce rozwinitych szkoach i uniwersytetach na caym
wiecie.
Jestem zdania, e jedn z pierwszych lekcji zaraz po przyjciu do szkoy powinno by to, jak
efektywnie si uczy, zamiast na si zapamitywa co, co w ogle nas nie interesuje.
Uczenie si na pami przynajmniej dla mnie kompletnie si nie sprawdzio.

Podczas pisania kodu i tworzenia rnych projektw zbierasz dowiadczenie.

Jednym z efektw ubocznych nabierania dowiadczenia jest to, e w jaki sposb, samoistnie,
zapamitujesz rne elementy jzyka. Nie ma wic adnego sensu zapamitywanie tego
wszystkiego na si, a ja polecam tworzenie wasnych projektw, w ktrych oprcz pisania kodu
bdziesz te widzia rezultaty swojej pracy.
To tyle pisz kod, a caa reszta (zapamitywanie skadni, pynno, mylenie w jzyku)
zapamita si sama.
Mit 6. Pisanie kodu jest proste
Gdyby byo, to projekty nie miayby opnie i nie kosztowayby mas czasu i pienidzy.
Zwyky Kowalski i tak bdzie zdziwiony, e taka maa strona potrzebowaa zespou
programistw, p roku pracy i setek tysicy z budetu. Programista natomiast bdzie zdziwiony,
e w ogle udao si ten projekt ukoczy :)
Mona powiedzie, e programowanie staje si prostsze wraz z nowym dowiadczeniem.
Pomyki, bdy i problemy to naturalna cz naszej pracy, bo tylko w taki sposb mona nauczy
si czego nowego.

A teraz czas na czsto spotykane bdy.

Bd 1. Nie dbasz o jako wasnego kodu

Twj kod to Twoja wizytwka. Jeli tworzysz kolejny projekt do szuflady mona jeszcze
przymkn oko, ale w wikszych projektach spjny kod ma do due znaczenie.
Warto dba m.in. o odpowiednie formatowanie, pisa niezbdne komentarze i dzieli aplikacj na
oddzielne moduy
Jednym ze sposobw na ujednolicenie kodu jest stosowanie tzw. style guides.
Jeli dziaasz we Front Endzie, zapoznaj si m.in. z JavaScript Style Guide od Airbnb.
Znajdziesz tam cay zestaw dobrych praktyk pisania i organizacji kodu (w tym przypadku
JavaScript) wraz z wyjanieniem dlaczego tak, a nie inaczej.
Jeeli kada osoba z 10-osobowego zespou bdzie dbaa o to, by kod caej aplikacji wyglda tak,
jakby pisa go jeden czowiek, to cao automatycznie jest prostsza do zrozumienia i duo
wygodniej si na tym pracuje. Duo czciej bdziesz czyta kod, ni go pisa.
Pamitaj: nikt nie lubi kodu, ktry wyglda jak spaghetti.

Bd 2. Nie planujesz projektw

Do duy bd, ktry wielokrotnie odczuem na swojej skrze.
Mwi si, e 10 minut planowania moe zaoszczdzi godzin dziaania (czasem spotyka si te
inne proporcje czasowe).
Bardzo duo w tym prawdy, bo gdy masz wypisane czarno na biaym co musisz zrobi, wtedy nie
bdzisz mylami, tylko moesz zabiera si do pracy i odhacza kolejne zadania na licie to-do.
Mae projekty nie wymagaj a tak duego planowania, ale i tak warto to zrobi. Dzisiejszy typowy
projekt w JavaScripcie to sporo doczanych bibliotek i moduw, a do tego zadania,
ktre czsto s wyzwaniem.
Taki plan moesz zrobi na zwykej kartce lub wykorzysta narzdzia typu Trello. Kady duy
projekt da si rozbi na wiele mniejszych krokw, a dziki temu unikniesz sytuacji, gdzie nie
moesz si za co zabra, bo projekt jest tak duy, e Ci to przytacza.
Plan projektu to te zaplanowanie odpowiednich narzdzi, ktre chcesz wykorzysta, np. bibliotek
czy frameworkw.
Masz wielki artyku do napisania? Teraz napisz tylko spis treci. Za moment dodasz nagwki i
dopiszesz troch tekstu. Na kocu zczysz to wszystko w cao i uporzdkujesz.
Wiesz, w jaki sposb powstawa ten artyku? Na pocztku sprawdziem o czym pisali ju inni
autorzy i wypisaem to wszystko. Potem pomylaem co mgbym do tego doda i
rozwin. Nastpnie stworzyem spis treci i nagwki bdw oraz mitw pracy programisty.
Dopiero potem, gdy miaem ju struktur (i dziki niej wiedziaem o czym pisa) przeszedem do
pisania.
Cay ten artyku to wg WordPressa 23 zapisane wersje. Gdybym mia to zrobi na jeden raz
odpucibym sobie.
Klikajc na Zapisz jest takie fajne uczucie, e ju co zrobie i jeste coraz bliej celu :)

Bd 3. Staranie si by idealnym i
wymylanie koa na nowo
Perfekcjonizm to jedna z tych rzeczy, ktre najmocniej spowolniy moj nauk. Nigdy wicej!
Bardzo atwo wpa w puapk, gdzie siedzisz przy kolejnym tutorialu i czytasz jaki ten nowy
framework jest wietny i niezastpiony, a potem zamiast bra si za kodowanie, czytasz
dalej
A potem i tak nie kodujesz, bo przecie jeszcze trzeba wybra nowy edytor kodu, nowy motyw,
nowe wtyczki i najlepiej jeszcze zmieni system operacyjny. Byle tylko nie napisa ani jednej
linijki, bo nie jestem jeszcze gotowy.
Zamiast zastanawia si czy stosowa w edytorze wcicie tabulatorem czy moe uywa 3 spacji,
po prostu dopasuj sobie narzdzia do Twojej pracy.
Wiem, e jest tego duo (szczeglnie w wiecie Front Endu), ale dla klienta lub pracodawcy licz
si wyniki, a nie idealny kod.
Jeeli do tego zaczniesz wymyla wszystkie rozwizania na nowo, zamiast znale je na Google
lub StackOverflow w cigu 2 minut, to dostaniesz wypowiedzenie szybciej ni pojawie si w
firmie.
Done is better than perfect to zdanie, ktre jaki czas temu wydrukowaem i powiesiem sobie
na cianie. Lepiej eby co miao 10 bdw i dziaao, ni 10 wietnych pomysw, ktrych nigdy
nie zrealizowae.
Przy tworzeniu projektw pomocne moe by tworzenie MVP (Minimum Viable Product), czyli
produktu, ktry posiada minimum funkcji, ale ju dziaa.
Warto te ustali sobie granic, przy ktrej moesz zwolni z projektem. Zawsze mona co
zmieni, pytanie tylko czy warto inwestowa w to czas, ktry jest ograniczony.
Przy okazji, boisz si, e Twj kod nie jest idealny? Wrzu go na GitHuba. Kady kiedy
zaczyna, ale na GitHubie Twj kod jest jawny, wic moesz dosta wartociowe informacje od
bardziej dowiadczonych developerw. Wtedy sam przekonasz si, e nie ma kodu idealnego, bo
kady problem mona rozwiza na wiele sposobw, a przy okazji nauczysz si czego nowego.

Bd 4. Nieumiejtne debugowanie kodu

Dzisiaj mamy na tyle rozbudowane narzdzia w przegldarkach, e uywanie alert() i
console.log() (w JavaScripcie) jest bardzo mczce przy wikszych aplikacjach.
To nie jest te najlepsza metoda z tego powodu, e moesz zapomnie o wyrzuceniu tych
polece, a one powdruj na publiczny serwer.
Niestety nie mog tego znale, ale chciaem w tym miejscu wstawi screenshota, na ktrym
wida, e na jednej ze stron duych marek (bodaje McDonalds) programici chcieli na szybko
przetestowa kod i zrobili tzw. dupa debugging.
Czyli zamiast korzysta z nowoczesnych narzdzi do debugowania w
przegldarkach (zazwyczaj klawisz F12) , wypisywali w konsoli komunikaty typu dupa1,
dupa2, eby przeledzi zachowanie kodu. Nic zego by si nie stao, gdyby nie zobaczyy tego
setki osb, bo cay kod trafi na serwer ;)
Korzystajc z przegldarkowego debuggera jeste w stanie krok po kroku przeledzi jak dziaa
aplikacja, w jakiej kolejnoci wywoywane s funkcje, jakie s wartoci zmiennych itd. A to
wszystko bez wykorzystywania alertw.
Przeczytaj wicej o Chrome DevTools

Bd 5. Brak testw i systemu kontroli wersji

Testy automatyczne nie musz by przydatne przy kadym projekcie i nie kady chce je tworzy.
Jednak w miar jak projekt si rozrasta, mog oszczdzi Ci mas czasu i szybko poinformowa o
ewentualnych bdach. Wystarczy, e developer wrzuci nowy kod i chwil pniej dostanie
informacj, czy kada cz aplikacji nadal dziaa poprawnie.
System kontroli wersji (najpopularniejszy jest Git) powinien by obowizkowy w momencie, gdy
tworzymy co wikszego ni may projekt do szuflady.
Jeszcze do niedawna nienawidziem Gita za to, jak w wielu momentach jest skomplikowany i
nieintuicyjny, ale moliwo ledzenia swojego kodu, podzia na branche czy szybka integracja
kodu, nad ktrym pracuje cay zesp obok tego nie da si przej obojtnie.
Bd 6. Bycie zbyt duym pasjonatem i brak
odpoczynku
Jestem pasjonatem i czasami tego auj. Godzinka pracy moe zmieni si w kilkanacie
tylko dlatego, e wysza jaka nowa fajna technologia lub robi ciekawy projekt.
Nie wane jak ciekawa jest brana, w ktrej pracujesz to jest tylko zawd, jak kady inny i trzeba
mie do niego zdrowy dystans, bo w innym wypadku mona szybko si wypali.
Ja przez pewien czas nie mogem zapa takiego dystansu i po kilku maratonach kodowania
miaem serdecznie dosy tego zawodu. Prbowaem rnych wyjazdw (np. do Santiago
de Compostela czy do Norwegii), a okazao si, e zamiast ucieka od tej brany, wystarczy
regularnie odpoczywa.
Zdrowie zawsze numerem 1!
Zbyt duga praca daje kompletnie odwrotne rezultaty. Produktywno spada, a czas i tak leci.
Dugofalowo najlepszym rozwizaniem jest jak zawsze balans midzy prac i odpoczynkiem.
Co z tego, e potrafi siedzie z pasj przez kilkanacie godzin dziennie przez kilka dni, skoro
cay nastpny tydzie nie bd mg ju patrze na kod
Czasem warto po prostu wyluzowa i wyjecha w Bieszczady chocia na chwil. Warto te
od czasu do czasu zmieni rodowisko. Nawet tak mae zmiany, jak zwyke przestawienie biurka
albo zmiana miejsca pracy potrafi zmieni nasze nastawienie.
Mwiem te troch o tym w swoim pierwszym Vlogu o odpoczynku.

Podsumowanie
Im wicej czowiek zdobywa dowiadczenia, tym bardziej zauwaa cz z tych gupot, ktre mia
w gowie.
Bycie programist to nie jest zawd idealny (taki nie istnieje), ale majc odpowiednie podejcie
moemy sprawi, e praca nad kodem bdzie cakiem przyjemna i pozwoli nam si rozwija.
Z minimaln dawk stresu, ktry oczywicie zawsze gdzie tam jest, ale zazwyczaj
pozytywnie motywuje.