W temacie mitów i błędów w pracy programisty powstało już wiele artykułów i nagrań, ale podejrzewam, że ten temat nigdy nie zostanie wyczerpany.

Ciekawie opisał to JavaDevMatt i wielu innych autorów, ale myślę, że warto tutaj dorzucić swoje 3 grosze i zebrać to wszystko w całość.

Ten artykuł piszę też dla samego siebie. Będąc programistą bardzo łatwo wpaść w głupie nawyki typu „ten kod musi być idealny”.

 

Kod ma działać poprawnie, ma być szybki i dobrze zorganizowany, żeby każdy, kto będzie z nim pracował, miał ułatwione zadanie i nie musiał się zastanawiać „co tu się k… dzieje”.

Perfekcjonizm w tej branży polecam włożyć między bajki. Długofalowo powoduje on więcej problemów niż daje korzyści. Done is better than perfect.

 

Mogłoby się wydawać, że ja – autor – już to wszystko wiem, ale i tak czasami zdarza mi się siedzieć zbyt długo nad problemem czy szukać idealnego rozwiązania, nawet gdy to aktualne jest w porządku.

Zapraszam więc do mitów i błędów, które mogą popełniać programiści (i ogólnie wszystkie osoby związane z kodem) na każdym szczeblu kariery.

Zaznaczę jeszcze, że jest to artykuł UNIWERSALNY, a programista programiście nie równy. Zapraszam też do ciekawej dyskusji, która powstała na Wykopie.

 

Mit 1. „Nauczę się raz i to wystarczy”

Jeśli chcesz pracować z takim podejściem, to najlepiej będzie zmienić branżę. Zawód programisty to niekończąca się opowieść pełna nowych języków, technologii i wyzwań.

W IT, szczególnie we Front Endzie, nie da się nauczyć jakiejś technologii raz, a potem korzystać z tego przez rok, bez zaglądania do dokumentacji. Zbyt szybko to wszystko się zmienia.

Mamy teraz wielki bum na JavaScript i wszelkie narzędzia z nim związane.

W pracy możesz 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.

Frameworki technologie JavaScript

Jest tego dużo i szybko się to zmienia, co dla niektórych może być frustrujące. Jednego dnia poznajesz jakiś framework, a za miesiąc wychodzą 2 kolejne.

Ta branża już tak ma i tego nie zmienisz. Warto więc mieć odpowiednie podejście i uczyć się regularnie. Lepiej rozłożyć naukę na mniejsze części, ale robić to systematycznie, żeby uniknąć potem przytłoczenia nowymi technologiami.

W taki sposób buduje się nawyk, który jest dużo lepszy od tzw. motywacji, która jest w dzisiejszych czasach tak mocno pompowana przez różnych „guru” rozwoju osobistego. Motywacja może i jest pomocna, ale na początku.

Motyw + akcja = dlaczego chcesz to zrobić?

Znajdź sobie jakiś konkretny powód, a organizm sam da Ci motywację. To właśnie takie proste. Nie musisz wciskać sobie do głowy formułek typu „zawsze i wszędzie możesz wszystko”.

Motywacja jest krótkotrwała, a dopiero nawyk sprawi, że będziesz wytrwale działać (na automacie), rozłożysz problem na części i choćby rozwiązanie go miało zająć Ci miesiąc, to i tak to zrobisz.

 

Mit 2. „Jestem zdany tylko na siebie i nikt mi nie pomoże”

W przypadku freelancingu może tak być, bo jako jedyny wykonawca albo masz kogoś do pomocy albo radzisz sobie sam (nie wliczając wiedzy z Google i Stack Overflow). Jednak będąc na etacie lub po prostu pracując w jakiejś firmie na miejscu (możesz przecież rozliczać się B2B) jesteś członkiem zespołu.

Nikt nie jest idealny, ale można bardzo dobrze współpracować w zespole, w którym każdy się uzupełnia. Jeden lubi JavaScript, drugi WordPressa, a trzeci zajmuje się Back Endem i serwerami.

Często zakres tej wiedzy jest tak szeroki, że prawdopodobnie w Twoim zespole jest już osoba, która albo poradziła sobie z Twoim problemem, albo przynajmniej wie jak się do niego zabrać.

Wystarczy zapytać.

 

Mit 3. „Nie jestem wystarczająco dobry, żeby…”

…poprosić o podwyżkę, dostać awans, zacząć poznawać nową technologię – wpisz tutaj cokolwiek.

Chodzi o porównywanie się z innymi ludźmi. To może sprawić, że będziesz czuł się albo lepszy, albo gorszy. Podejrzewam, że częściej jednak to drugie.

Bez względu na to, co podpowiada Ci głowa, praktycznie zawsze jest tak, że jesteś lepszy niż Ci się wydaje, a wszystkie te złe myśli nie mają sensu.

Wyobraź sobie, że programista z 10-letnim stażem nagle wkręci 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 może tydzień.

Szkoda czasu na takie zamartwianie, lepiej skupić się na pozytywnych aspektach tego zawodu.

Nawet osoby początkujące mają spore szanse na znalezienie ciekawej pracy, bo rynek rozwija się w takim tempie, że cały czas mamy niedobór specjalistów. Nie musisz być nie wiadomo jakim „wyjadaczem”, bo na tych najniższych stanowiskach (na przykładzie Front End Developera) zazwyczaj wystarczy średnia znajomość HTML i CSS oraz podstawy JavaScriptu.

W CV warto też pokazać kilka wykonanych projektów, nawet tych „do szuflady”. Liczy się doświadczenie, więc nie możesz siedzieć na tyłku i czekać, ale raczej… programować, tworzyć własne projekty i składać CV :)

Zresztą, szacuje się, że do 2020 roku będzie brakowało ok. 1 miliona programistów na rynku. Szkoda tego nie wykorzystać!

 

Mit 4. (początkujący) „Muszę znać dobrze matematykę, a najlepiej skończyć studia informatyczne…”

…żeby cokolwiek znaczyć w tej branży.

Kolejny mit, tak samo jak mit informatyka, który siedzi w koszuli w kratkę, pije litrami Coca-Colę, mieszka w piwnicy i myje się raz na tydzień.

Wszystko zależy od tego, gdzie i z kim pracujesz, jakie jest Twoje stanowisko. W „typowej pracy” większość czasu spędzisz na pisaniu kodu, zamiast na rozgryzaniu funkcji matematycznych, a w zdecydowanej większości przypadków wystarczą Ci podstawy matematyki.

W momencie gdy będziesz chciał wykonać jakieś skomplikowane obliczenia czy narysować sobie diagram – wystarczy pobrać jedną z setek gotowych bibliotek, które zrobią to za Ciebie.

Sytuacja wygląda inaczej, gdy Twoje stanowisko będzie wymagało zaawansowanej matematyki czy fizyki, ale nawet tutaj jest dużo gotowych rozwiązań, które wystarczy wykorzystać w projekcie.

 

Mit 5. „Muszę wszystko zapamiętać”

Ze szkoły pewnie wiesz, że zapamiętywanie na siłę nic nie daje. To jedna z tych cudownych metod, których używają nauczyciele w wielce rozwiniętych szkołach i uniwersytetach na całym świecie.

Jestem zdania, że jedną z pierwszych lekcji zaraz po przyjściu do szkoły powinno być to, jak efektywnie się uczyć, zamiast na siłę zapamiętywać coś, co w ogóle nas nie interesuje.

Uczenie się na pamięć – przynajmniej dla mnie – kompletnie się nie sprawdziło.

Debugowanie JavaScript błędy

Podczas pisania kodu i tworzenia różnych projektów – zbierasz doświadczenie.

Jednym z efektów ubocznych nabierania doświadczenia jest to, że w jakiś sposób, samoistnie, zapamiętujesz różne elementy języka. Nie ma więc żadnego sensu zapamiętywanie tego wszystkiego na siłę, a ja polecam tworzenie własnych projektów, w których oprócz pisania kodu będziesz też widział rezultaty swojej pracy.

To tyle – pisz kod, a cała reszta (zapamiętywanie składni, płynność, myślenie w języku) „zapamięta się” sama.

 

Mit 6. „Pisanie kodu jest proste”

Gdyby było, to projekty nie miałyby opóźnień i nie kosztowałyby masę czasu i pieniędzy.

Zwykły Kowalski i tak będzie zdziwiony, że taka „mała strona” potrzebowała zespołu programistów, pół roku pracy i setek tysięcy zł budżetu. Programista natomiast będzie zdziwiony, że w ogóle udało się ten projekt ukończyć :)

Można powiedzieć, że programowanie staje się prostsze wraz z nowym doświadczeniem. Pomyłki, błędy i problemy to naturalna część naszej pracy, bo tylko w taki sposób można nauczyć się czegoś nowego.

 

A teraz czas na często spotykane błędy.

Błąd 1. Nie dbasz o jakość własnego kodu

Twój kod to Twoja wizytówka. Jeśli tworzysz kolejny projekt „do szuflady” – można jeszcze przymknąć oko, ale w większych projektach spójny kod ma dość duże znaczenie.

Warto dbać m.in. o odpowiednie formatowanie, pisać niezbędne komentarze i dzielić aplikację na oddzielne moduły. Może są to wyświechtane frazesy, ale jednak ludzie często o tym nie pamiętają.

Ostatnio, gdy przygotowywałem stronę dla klienta na bazie szablonu kupionego na ThemeForest, autor zastosował 3 różne sposoby formatowania selektorów w Sass, 80% właściwości ułożył jedna pod drugą bez żadnego odstępu (co było kompletnie nieczytelne), a w losowych miejscach wrzucał po 8 linijek pustego miejsca jako odstęp. O JavaScripcie nie wspomnę…

Jednym ze sposobów na ujednolicenie kodu jest stosowanie tzw. style guides.

Jeśli działasz we Front Endzie, zapoznaj się m.in. z JavaScript Style Guide od Airbnb. Znajdziesz tam cały zestaw dobrych praktyk pisania i organizacji kodu (w tym przypadku JavaScript) wraz z wyjaśnieniem dlaczego tak, a nie inaczej.

Jeżeli każda osoba z 10-osobowego zespołu będzie dbała o to, by kod całej aplikacji wyglądał tak, jakby pisał go jeden człowiek, to całość automatycznie jest prostsza do zrozumienia i dużo wygodniej się na tym pracuje. Dużo częściej będziesz czytać kod, niż go pisać.

Pamiętaj: nikt nie lubi kodu, który wygląda jak spaghetti.

 

Błąd 2. Nie planujesz projektów

Dość duży błąd, który wielokrotnie odczułem na swojej skórze.

Mówi się, że 10 minut planowania może zaoszczędzić godzinę działania (czasem spotyka się też inne proporcje czasowe).

Programista JavaScript - pisanie kodu

Bardzo dużo w tym prawdy, bo gdy masz wypisane czarno na białym co musisz zrobić, wtedy nie błądzisz myślami, tylko możesz zabierać się do pracy i „odhaczać” kolejne zadania na liście to-do.

Małe projekty nie wymagają aż tak dużego planowania, ale i tak warto to zrobić. Dzisiejszy typowy projekt w JavaScripcie to sporo dołączanych bibliotek i modułów, a do tego zadania, które często są wyzwaniem.

Taki plan możesz zrobić na zwykłej kartce lub wykorzystać narzędzia typu Trello. Każdy duży projekt da się rozbić na wiele mniejszych kroków, a dzięki temu unikniesz sytuacji, gdzie nie możesz się za coś zabrać, bo projekt jest tak duży, że Cię to przytłacza.

Plan projektu to też zaplanowanie odpowiednich narzędzi, które chcesz wykorzystać, np. bibliotek czy frameworków.

Masz wielki artykuł do napisania? Teraz napisz tylko spis treści. Za moment dodasz nagłówki i dopiszesz trochę tekstu. Na końcu złączysz to wszystko w całość i uporządkujesz.

Wiesz, w jaki sposób powstawał ten artykuł? Na początku sprawdziłem o czym pisali już inni autorzy i wypisałem to wszystko. Potem pomyślałem co mógłbym do tego dodać i rozwinąć.  Następnie stworzyłem spis treści i nagłówki błędów oraz mitów pracy programisty. Dopiero potem, gdy miałem już strukturę (i dzięki niej wiedziałem o czym pisać) przeszedłem do pisania.

Cały ten artykuł to wg WordPressa 23 zapisane wersje. Gdybym miał to zrobić „na jeden raz” – odpuściłbym sobie.

Klikając na „Zapisz” jest takie fajne uczucie, że już coś zrobiłeś i jesteś coraz bliżej celu :)

 

Błąd 3. Staranie się być „idealnym” i wymyślanie koła na nowo

Perfekcjonizm to jedna z tych rzeczy, które najmocniej spowolniły moją naukę. Nigdy więcej!

Bardzo łatwo wpaść w pułapkę, gdzie siedzisz przy kolejnym tutorialu i czytasz jaki ten nowy framework jest świetny i niezastąpiony, 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 wcięcie tabulatorem czy może używać 3 spacji, po prostu dopasuj sobie narzędzia do Twojej pracy.

Wiem, że jest tego dużo (szczególnie w świecie Front Endu), ale dla klienta lub pracodawcy liczą się wyniki, a nie idealny kod.

Jeżeli do tego zaczniesz wymyślać wszystkie rozwiązania na nowo, zamiast znaleźć je na Google lub Stack Overflow w ciągu 2 minut, to dostaniesz wypowiedzenie szybciej niż pojawiłeś się w firmie.

Oczywiście nie można tutaj przesadzać i opierać całego kodu swojego projektu na Stack Overflow, bez zrozumienia jak krok po kroku to działa. Google i SO to kopalnia wiedzy, która będzie dobrym doradcą i podpowie Ci rozwiązania problemów, na które ktoś już dawno znalazł odpowiedź i popełnił błędy za Ciebie.

Dostajesz więc (często) sprawdzonego gotowca. Tylko od Ciebie zależy czy zrobisz kopiuj-wklej, czy może poświęcisz chwilę, by zrozumieć jak to działa.

„Done is better than perfect” to zdanie, które jakiś czas temu wydrukowałem i powiesiłem sobie na ścianie. Lepiej żeby coś miało 10 błędów i działało, niż 10 świetnych pomysłów, których nigdy nie zrealizowałeś.

Przy tworzeniu projektów pomocne może być tworzenie MVP (Minimum Viable Product), czyli produktu, który posiada minimum funkcji, ale już działa.

Warto też ustalić sobie granicę, przy której możesz zwolnić z projektem. Zawsze można coś zmienić, pytanie tylko czy warto inwestować w to czas, który jest ograniczony.

Przy okazji, boisz się, że Twój kod nie jest idealny? Wrzuć go na GitHuba. Każdy kiedyś zaczynał, ale na GitHubie Twój kod jest jawny, więc możesz dostać wartościowe informacje od bardziej doświadczonych developerów. Wtedy sam przekonasz się, że nie ma kodu idealnego, bo każdy problem można rozwiązać na wiele sposobów, a przy okazji nauczysz się czegoś nowego.

 

Błąd 4. Nieumiejętne debugowanie kodu

Dzisiaj mamy na tyle rozbudowane narzędzia w przeglądarkach, że używanie alert() i console.log() (w JavaScripcie) jest bardzo męczące przy większych aplikacjach.

To nie jest też najlepsza metoda z tego powodu, że możesz zapomnieć o wyrzuceniu tych poleceń, a one powędrują na publiczny serwer.

Niestety nie mogę tego znaleźć, ale chciałem w tym miejscu wstawić screenshota, na którym widać, że na jednej ze stron dużych marek (bodajże McDonald’s) programiści chcieli na szybko przetestować kod i zrobili tzw. „dupa debugging”.

Czyli zamiast korzystać z nowoczesnych narzędzi do debugowania w przeglądarkach (zazwyczaj klawisz F12) , wypisywali w konsoli komunikaty typu „dupa1”, „dupa2”, żeby prześledzić zachowanie kodu. Nic złego by się nie stało, gdyby nie zobaczyły tego setki osób, bo cały kod trafił na serwer ;)

Korzystając z przeglądarkowego debuggera jesteś w stanie krok po kroku prześledzić jak działa aplikacja, w jakiej kolejności wywoływane są funkcje, jakie są wartości zmiennych itd. A to wszystko bez wykorzystywania alertów.

Przeczytaj więcej o Chrome DevTools

Google Chrome developer tools

 

Błąd 5. Brak testów i systemu kontroli wersji

Testy automatyczne nie muszą być przydatne przy każdym projekcie i nie każdy chce je tworzyć. Jednak w miarę jak projekt się rozrasta, mogą oszczędzić Ci masę czasu i szybko poinformować o ewentualnych błędach. Wystarczy, że developer wrzuci nowy kod i chwilę później dostanie informację, czy każda część aplikacji nadal działa poprawnie.

System kontroli wersji (najpopularniejszy jest Git) powinien być obowiązkowy w momencie, gdy tworzymy coś większego niż „mały projekt do szuflady”.

Jeszcze do niedawna nienawidziłem Gita za to, jak w wielu momentach jest skomplikowany i nieintuicyjny, ale możliwość śledzenia swojego kodu, podział na branche czy szybka integracja kodu, nad którym pracuje cały zespół – obok tego nie da się przejść obojętnie.

 

Błąd 6. Bycie zbyt dużym pasjonatem i brak odpoczynku

Jestem pasjonatem i czasami tego żałuję. „Godzinka pracy” może zmienić się w kilkanaście tylko dlatego, że wyszła jakaś nowa fajna technologia lub robię ciekawy projekt.

Nie ważne jak ciekawa jest branża, w której pracujesz – to jest tylko zawód, jak każdy inny i trzeba mieć do niego zdrowy dystans, bo w innym wypadku można szybko się wypalić.

Ja przez pewien czas nie mogłem złapać takiego dystansu i po kilku maratonach kodowania miałem serdecznie dosyć tego zawodu. Próbowałem różnych wyjazdów (np. do Santiago de  Compostela czy do Norwegii), a okazało się, że zamiast uciekać od tej branży, wystarczy regularnie odpoczywać.

Zdrowie zawsze numerem 1!

Zbyt długa praca daje kompletnie odwrotne rezultaty. Produktywność spada, a czas i tak leci. Długofalowo najlepszym rozwiązaniem jest – jak zawsze – balans między pracą i odpoczynkiem.

Co z tego, że potrafię siedzieć z pasją przez kilkanaście godzin dziennie przez kilka dni, skoro cały następny tydzień nie będę mógł 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 małe zmiany, jak zwykłe przestawienie biurka albo zmiana miejsca pracy potrafią zmienić nasze nastawienie.

Mówiłem też trochę o tym w swoim pierwszym Vlogu o odpoczynku.

 

Podsumowanie

Im więcej człowiek zdobywa doświadczenia, tym bardziej zauważa część z tych głupot, które miał w głowie.

Bycie programistą to nie jest zawód idealny (taki nie istnieje), ale mając odpowiednie podejście możemy sprawić, że praca nad kodem  będzie całkiem przyjemna i pozwoli nam się rozwijać.

Z minimalną dawką stresu, który oczywiście zawsze gdzieś tam jest, ale zazwyczaj pozytywnie motywuje.

Przeczytaj też...

12 mitów i błędów spotykanych w pracy programisty
Ocena: 4.7 - 38 głosów

Jakub Jurkian

Od ponad 11 lat jestem programistą-pasjonatem, a strony (i wszystko co z nimi związane) tworzę od 6 lat. Jestem też autorem kursów wideo - od 2013 roku prowadzę kanał na YouTube i tego bloga. Zaczynałem od pisania artykułów dla jednego z czołowych polskich portali IT - benchmark.pl. Prywatnie od 10 lat jestem związany z kulturą hip-hop (głównie taniec breakdance).

11 komentarzy

as27 maja 2017, 00:04

Uczenie się na pamięć nie przynosi zadowalających efektów (czyli szybko i trwale) powyżej wieku licealnego. Pamięciówki niesamowicie zwiększają rozdzielczość u małych dzieci, jeśli tego nie ćwiczyliśmy za gówniaka, to w wieku +20 lat jest to bardzo trudne i wymagające naprawdę wiele wysiłku.

Odpowiedz

Johnny27 maja 2017, 10:10

Niestety studia tudzież jakakolwiek normalna edukacja informatyczna (porządny kurs z podstaw informatyki, inżynierii oprogramowania, standardowych prostych algorytmów, architektur oprogramowania) ma niestety duże znaczenie. Oczywiście nie jest to zero jedynkowe, że jak ktoś nie był na studiach to nie może być dobrym programistą i odwrotnie, że jak ktoś był to na bank jest dobry. Ale niestety wbrew wszelkim motywacyjnym blogpostom, artykułom jak zacząć programowanie i co to wystarczy, żeby programować widać sporą różnicę między osobą która interesuje się programowaniem i była na studiach, a osobą która intersuje się programowaniem ale nie była na studiach. Proste algorytmy, generalnie sposób myślenia, koncepcje, architektury przychodzą naturalnie jak się o nich słyszało, widziało przykłady, nawet stare. Często mają taką tzw. „suchą i zupełnie nieprzydatną wiedzę” jak to mówi większość studentów, da się szybko rozpoznać błędy w architekturze, które później mogą być trudne do naprawy. Da się tego nauczyć, i da się programować, ale każdy kto chce faktycznie dobrze programować, może zacząć od kursów, kodowania i uczenia się na żywioł, ale niestety kiedyś wypadałoby nauczyć się tych nudnych dla większości, ale podstaw, bo to naprawdę pomaga i różnica jest znaczna.

Nie można ofcoz porównywać ludzi którzy poszli na IT na studia, bo w IT dobrze płacą ;-) oni zawsze będą marudzić, że uczyli ich nieprzydatnych bzdur, oni zmarnowali tylko czas.

Natomaist co to MVP, jest jeden prosty haczyk w tym podejściu. Wielokrotnie MVP zostaje awansowany do nowego produktu. Niestety celem MVP jest albo zacząć zarabiać, albo pokazać coś co działa i można to zrobić w dowolnej technologii. Najlepiej takiej, która najszybciej da dobry wynik i najlepiej docelowej w której ma byc finalny duzy system. Niestety często okazuje się, że technologia MVP nie nadaje się do finalnego dużego systemu… albo wprowadzane, są uproszczenia które tak naprawde później trzeba wywalić i napisać poprawnie, pod dużą architekturę, bo charakter MVP i koncowego produktu jest inny.

Z tym związany jest imho bardziej poważny problem programistów. Przywiązują się do swojego kodu. Nie potrafią czasami czegoś po prostu wywalić, mimo, że wszystko wskazuje na to, że trzeba to zrobić inaczej. Później powstają takie 100 razy refaktorowane kalafiory, które koniec końców i tak nie rozwiązują problemu, bo wówczas problem najczęściej leży w błędnej decyzji projektowej/architekturze. No ale niestety jak nie ma się podstaw związanych z architekturą, to programista tego nie zauważy i będzie brnął w to i brnął. Wtedy nic tylko liczyć na dobrego architekta… o ile jest… a nie że jest tylko PM, który się na tym nie zna.

Odpowiedz

LSO27 maja 2017, 13:33

Na tych najniższych stanowiskach: frontend developer… Przestałem czytać, więcej pokory chłopcze.

Odpowiedz

    Jakub Jurkian27 maja 2017, 14:21

    Już poprawiłem. Miało to brzmieć jak: „na tych najniższych stanowiskach, na przykładzie Front End Developera”

    Odpowiedz

anonimowy7 czerwca 2017, 19:24

Świetny wpis!
Zaczynam śledzić Twój blog :)

Odpowiedz

    Jakub Jurkian7 czerwca 2017, 23:05

    Zapraszam więc :)
    Kilka artykułów już na horyzoncie, ale przeszkodą jest jak zawsze – czas.

    Odpowiedz

altara14 czerwca 2017, 16:01

Bardzo dobry artykuł. Optymistyczny, motywuje do programowania. Ilustracja do mitu 5 trochę drastyczna- takich programistów jeszcze nie spotkałam. Na pewno zapiszę się na Twoje kursy, bo warto!

Odpowiedz

    Jakub Jurkian14 czerwca 2017, 19:26

    Dzięki Ola.
    Ilustracja – może lekko tak. Choć co do zapamiętywania, to jeszcze czasem takie myśli przelecą mi przez głowę, ale już rzadko. To po prostu nie działa i liczy się doświadczenie, wtedy mózg zapamiętuje „z automatu”.

    Zapraszam na kursy, premiera odświeżonego Webmastera Krok Po Kroku już nie długo, będę wysyłał powiadomienie emailem.

    Odpowiedz

Zoska3 lipca 2017, 11:25

Dobrze napisane, ciekawy tekst.

Odpowiedz

Wroclawianka23 sierpnia 2017, 10:53

Bład 3 i 6 to o mnie.
„Jeszcze nie jestem gotowa” -> przeczytam moze jeszcze jedną książkę/stronke/…
„jeszcze chwila/godzinka… tylko to naprawie i ide do domu” a potem mam dość roboty, że nie mam ochoty do niej wracać.

Odpowiedz

    Jakub Jurkian23 sierpnia 2017, 10:57

    Czasami każdy tak ma, aktualnie poznaję Redux i też nie wiem od czego zacząć.
    Więc rzeczywiście nie jestem gotowy :)

    Wiesz co jest najlepsze?
    Szacuję, że w 90% przypadków gdy już ZACZĄŁEM, to nagle wszystko stało się proste. Wystarczyła jedna decyzja: koniec teorii, czas to w końcu zrobić.

    Odpowiedz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*