JavaDevMatt.pl – Mateusz Kupilas

Programista, przedsiębiorca, gamedev, bloger.

Najczęstsze błędy w nauce programowania

Postaram się wypunktować 5 rzeczy, które chciałbym przeczytać jako licealista, który ma ochotę uczyć się programowania. Niestety na mnie już trochę za późno, ale mam nadzieję, że Wy skorzystacie. 🙂

1. Just- in-time learning

programmer-1-288950-mJeśli chciałbym byś zapamiętał tylko jedną rzecz, to było by to właśnie to: just-in-time learning. O co tu chodzi?

Chodzi oto , by efektywnie wykorzystać swój czas i uczyć się czegoś dopiero, gdy faktycznie musimy to wykorzystać. Niby proste, oczywiste, ale obserwowałem to u siebie tyyyyyle razy… natrafiłem na tutorial jak napisać swój webserwis w php i następnie napisać aplikację na androida, która z niego korzysta. Super. Tylko nigdy nie wykorzystałem tego dotąd w praktyce. Akurat w pracy mamy osoby od serwerów i to one dostarczają nam webserwisy i nikt nie wpada na pomysł, by pisać je w php. Albo bawię się z sql lite, chociaż w pracy nigdy nie miałem potrzeby z tego korzystać.

Nie chodzi oto, że zrobiłem coś złego: nie ma nic złego w tym, by eksperymentować z technologiami. Jednak warto poświęcać  większość naszego czasu na osiągnięcie określonego celu. Eksperymenty swoją drogą, ale niech nie zajmują one większości Twojego czasu.

Co z tego, że przerobiłeś 10 losowych, może i ciekawych tutoriali, skoro efekt jest taki, że masz na dysku jakiś przykładowy kod źródłowy, który najczęściej bezmyślnie przepisałeś?

Ucz się z jakimś celem w głowie: chcę napisać aplikację, która robi a, b, c i d. Następnie naucz się jak zastosować a, b, c i d w kontekście Twojej aplikacji. Efekt? Masz gotowy projekt, który możesz gdzieś pokazać.

Jaki jest efekt, jeśli uczymy się czegoś bez określonego celu? Tak jak wyżej wspomniany sql lite: kiedyś coś tam napisałem, bo myślałem, że muszę znać każdy aspekt androida. Efekt jest taki, że już nic z tego nie pamiętam, nie zastosowałem tego w żadnym konkretnym projekcie i by ponownie wykorzystać sql list  musiałbym się i tak zerknąć do materiałów dla początkujących. Czas, który kiedyś temu poświęciłem jest w dużym stopniu zmarnowany.

Pytanie: dlaczego uczyłem się rzeczy, których nigdy nie zastosowałem? Myślę, że bałem się, że pytanie o sql lite pojawi się na rozmowie kwalifikacyjnej i źle wypadnę. Bzdura! Lepiej mieć możliwość przestawić jakiś projekt, w którym wykorzystałeś x, y, z i zrobiłeś z tego jakiś fajny projekt, niż pokazać… zlepek tutoriali i szczotkową wiedzę, która po nich pozostała. Nikt, nigdy nie będzie oczekiwał, że będziesz posiadał wiedzę z wszystkich elementów jakiejś platformy jak np. androida. Jeśli byłeś w stanie nauczyć się a, b i c, to d, e i f również nie sprawi Ci problemu.

Kolega senior developer przez długi czas nie korzystał z fragmentów w androidzie. Po prostu pracował przy aplikacji, która została napisana jakiś czas temu, wspierała do androida 2.1. Jak zaczęliśmy pracować nad nowszą wersją aplikacji zaczął ogarniać fragmenty, po drodze popełnił parę błędów, ale koniec końców nauczył się z nich korzystać GDY MIAŁ TAKĄ POTRZEBĘ.

To była najważniejsza kwestia tego wpisu. Najczęstszy problem, który nęka większość młodych/początkujących programistów. Przerobili X tutoriali, ale nie potrafią sklecić żadnego sensownego projektu.

Bardzo prosty przykład co możecie zrobić: postawcie sobie za cel stworzenie czegoś w miarę małego i rozbijcie funkcjonalność na punkty.

Weźmy za przykład program, który liczy ile czasu spędziłeś nad jakimś zadaniem. Załóżmy, że chcemy by było to aplikacja desktopowa. Poszczególne przykładowe punkty to:

  • Wyświetlenie okna z tytułem programu – naucz się w technologii, którą sobie wybrałeś (nie ma znaczenie czy java, czy c#, czy python – ważna jest nauka podchodzenia problemu i szukania informacji) jak wyświetlić okno z tytułem Twojego programu.
  • Naucz się jak zamieścić na tym oknie button i pole tekstowe.
  • Naucz się jak pobierać dane, które wpisałeś do pola tekstowego.
  • Naucz się reagować na kliknięcie na button.
  • Naucz się jak odliczać czas w Twoim programie (coś timeropodobnego).
  • Spraw, by po naciśnięciu na button zaczął być odliczany czas i pobrana została nazwa zadania z pola tekstowego.
  • Drugi button niech zapisuje czas, który upłynął. Może to być lista obiektów z polami na nazwę zadania w formie stringa i czas w int.
  • Trzeci button, który eksportuje zapisane dane do jakiegoś pliku… np. do excela. Poszukaj tutoriala jak generować w Twojej wybranej technologii dane do plików .csv, a nastepnie zastosuj Twoją nową wiedzę, przez dodanie takiej funkcjonalności do programu.

Mam nadzieję, że łapiecie o co tu chodzi. Stawiaj sobie cel -> ucz się, by ten cel zrealizować. Eksperymenty i testowanie technologii też są fajne, ale niech nie zajmuje to większości Twojego czasu.

 

2. Uczenie się API na pamięć…

Kiedyś myślałem, że doświadczony zawsze wszystko pisze “z palca”. Nigdy nie musi zaglądać jak coś zrobić, bo jest już taki zajebisty.

Naprawdę tak myślałem. 😉

Prawda jest taka, że im ktoś bardziej doświadczony, tym po prostu lepiej korzysta z dokumentacji i wiedzy dostępnej w sieci. Oczywiście, jeśli dużo korzysta w danym projekcie z czegoś powtarzalnego, to może się wydawać, że pewne rzeczy pisze “z palca”. Jednak prawda jest taka, że gdy odłoży projekt i będzie musiał wrócić do niego za parę miesięcy, to będzie zerkał “jak to zostało zrobione”.

Sam tak długo nie miałem potrzeby wykorzystywać z serializacji w Javie, że musiałbym trochę o niej poczytać zanim ponownie zacznę ją wykorzystywać w projekcie. Nie popadajcie w pułapkę ucznia się rzeczy na pamięć. W sumie ten punkt znowu rozbija się o just-in-time learning z punktu pierwszego.

Pamiętam ze studiów, jak musieliśmy napisać w notatniku łączenie z bazą danych w php: bez internetu,  czy dokumentacji. Niestety tacy nauczyciele, na których czasami trafiłem bardzo zniechęcali do programowania. Sami nigdy nie pracowali jako programista i było im prostu wygodnie sprawdzić, czy uczeń nauczył się na pamięć jednego słusznego sposobu rozwiązania problemu, który był przedstawiony na ćwiczeniach/wykładzie.

3. Za długo siedzisz nad problemem

Jeśli siedzisz ponad godzinę/dwie nad jednym problemem, to marnujesz czas. Programowanie to nie praca fizyczna, gdzie przenosisz cegiełki z punktu A do B i ilość poświęconego czasu ma się często nijak do efektów Twojej pracy.

Każdy czasami tak ma, że ma jakąś blokadę i nie potrafi rozgryźć danego problemu. Dlatego w biurach, gdzie pracują pracownicy umysłowi często wstawia się piłkarzyki, xboxy, czy inne zabawki. Nie dlatego, że pracodawca chce być ‘fajny”, tylko dlatego, bo to się po prostu opłaca. Programista potrzebuje czasami odejść od kodu źródłowego i zająć głowę czymś innym, by koniec końców rozwiązać kolejny problem.

Sam często łapię się na tym, że 2 godziny wieczorem nie potrafią czegoś rozgryźć… a rano, podchodząc “na świeżo” do problemu, rozwiązuję go w 20 minut.

Wniosek: jeśli za długo nad czymś siedzisz i masz wrażenie, że czas Ci ucieka: zajmij się czymś innym. Wyjdź na półgodzinny spacer, albo zabierz się za inne zadanie projektu. Ważne by głowa mogła odpocząć od problemu, który powodował blokadę. Następnie wróć do problemu: jest bardzo prawdopodobne, że tym razem inaczej podejdziesz do rozwiązania.

Nie warto siedzieć godzinami i być sfrustrowanym. Odpocznij chwilę od problemu. Krótka pogawędka z kolegą na temat problemu również czyni cuda.

Może opisałem tę kwestię bardziej pod kątem pracy programisty, a nie typowo nauki, jednak pomysł pozostaje ten sam. Jeśli nie rozumiesz danego wzorca projektowego, to siedzenie kolejnej godziny nie pomoże. Odpocznij i wróć do problemu później.

4. Done is better than perfect

Kolejna pułapka, w którą łatwo wpaść. Dążenie do perfekcjonizmu, przez który nigdy nie kończy się żadnego projektu.

Sam kiedyś myślałem, że w każdej firmie IT programiści rozwiązują zadania w najlepszy możliwy sposób (naiwny ja 😉 ) i robienie czegoś “gorzej” jest nieakceptowalne.

Bzdury! W projekcie istnieje pewien czynnik, który powoduje, że zawsze idzie się na kompromisy: czas.

Chociaż często przyznaje się, że warto by poświęcić tutaj chwilę na refactoring, to jednak nie robi się tego, bo np. wersja beta musi zostać jutro opublikowana. Nikt nie jest z tego powodu zadowolony, ale realia często są takie, że programista jest zmuszony oddać kod, z którego nie jest w pełni zadowolony.

Część funkcjonalności zostaje wycięta, by zdarzyć z produktem na jakieś zbliżające się tragi.

Ucz się stawiać priorytety. Czasu zawsze będzie “za mało”.  Sztuką jest stawianie odpowiednich priorytetów. Nigdy nie nauczysz się wszystkiego. Zdecyduj co jest Ci aktualnie najbardziej potrzebne i tego się ucz. Fajnie by było, jeśli Twój projekt by generował po zakończeniu pracy jakiś wypasiony raport w formie pdf-a z piertrylionem wykresów. Jednak jeśli czas na to nie pozwala, to świadomie zdecyduje, że kompromisem jest to i to. To bardzo ważna umiejętność. Może jest to istotniejsza umiejętność dla managera projektu, ale programista, która potrafi dobrze dobierać priorytety też jest w cenie.

Sam miałem podczas dnia próbnego w firmie za dużą ilość zadań. Nikt nie oczekiwał, że zrobię wszystko. Chciano po prostu sprawdzić jak sobie z tym poradzę i czy wykonam te, które moim zdaniem mają największy priorytet.

5. Krytyka – im więcej, tym lepiej dla Ciebie. Nie bój się popełniać błędów.

Nie bój się popełniać błędów. Pokazuj swój kod. Opisuj jak chciałeś rozwiązać problem i poproś, by ktoś go skrytykował.

Nic nie powoduje takiego wzrostu tempa nauki, jak konstruktywna krytyka.

Jeśli wrzucasz swój kod na publiczne fora internetowe, to zawsze znajdzie się grupa sfrustrowanych kretynów, którzy nic konkretnego nie doradzą, tylko określą Twój kod jako gówno i stwierdzą, że lepiej jakbyś jednak sobie darował. Na szczęście większość ludzi jednak postara się Ci pomóc. Możesz odnieść odwrotne wrażenie, bo jednak tacy życiowi frustraci najgłośniej krzyczą. Koniec końców musisz się nauczyć to akceptować. Nie karm ich po prostu. Odpisuj tylko tym, którzy napisali coś wartościowego.

Dopóki nie skorzystałem z Internetu, nie wiedziałem, że na świecie jest tylu idiotów

– Stanisław Lem


13 thoughts on “Najczęstsze błędy w nauce programowania

  • kvsanagi napisał(a):

    Hej, powiedz mi, czy ucząc się z tego kursu: http://cpp0x.pl/kursy/Kurs-C++/1 , nie popełniam 1 błędu?

    • bcdev napisał(a):

      Kurs który podałeś dotyczy absolutnych podstaw. Są tam wytłumaczone zagadnienia, które każdy zaawansowany programista zna i używa. Analogicznie do arytmetyki w matematyce, która się przydaje zawsze.
      Punkt nr 1 dotyczy rzeczy bardziej zaawansowanych, które mogą, ale nie muszą się przydać. Tak jak nie każdy potrzebuje znać całkowanie.

      Tak więc ucząc się z tego kursu nie popełniasz błędu nr 1. Wszystko z w.w. kursu kiedyś ci się przyda, nawet jeżeli będziesz kiedyś programował w czymś innym niż C++.

  • Kokes napisał(a):

    Zgadzam się z większości twoich rad.

    1. Nie ma sensu się uczyć czegoś, jeżeli tego nie używaż. Dobrze jest jednak poczytać o technologiach/bibliotekach, ponieważ jeżeli będziesz musiał coś zaimplementować to musisz wiedzieć jaka jest najodpowiedniejsza technologia.

    2. Jeżeli używasz API przed dlugi okres czasu, to podstawowe klasy/metody już siedzią w twojej głowie.

    3. Jeżeli długo siedzisz nad jakimś problemem, to najlepiej jest zmienić zadanie. Rozwiązywanie zagadek najlepiej wychodzi rano jak kolega zauważył 🙂

    4. Wszystko jest zależne jak projekt został wyceniony i kiedy jest deadline. Polityka firmy w której pracujesz też jest ważna. Kilka razy miałem wrażenie, że projekt nie powinien być live, ale niestety z powodu deadlinu i innych projektów został oddany klientowi. Wraca do programisty jak bumerang 🙂 W tym przypadku firma w której pracujesz traci najwiecej..

    5. Ja osobiście wolę się uczyć na kogoś błędach 🙂

  • Filip napisał(a):

    Z większością się zgadzam, ale moim zdaniem dobrze jest chociaż pobieżnie zapoznawać się z różnymi technologiami, aby uniknąć “wyważania otwartych drzwi”. Miałem w swojej pracy wielokrotnie sytuację, że pisałem funkcje, które już wcześniej ktoś zaprogramował w jakiejś bibliotece. Także moim zdaniem, nie trzeba wszystkiego znać na pamięć, ale dobrze jest przynajmniej “świadomie” zdawać sprawę, że takie coś istnieje :).

  • rekul napisał(a):

    Sama prawda. Ostatnio byłem na rozmowie kwalifikacyjnej, która polegała na programowaniu, uwaga, na kartce… Opis zadania na 3/4 kartki A4 i programuj człowieku. Rozwaliło mnie to. Kolejne zadanie, kod przedstawiający dość niskopoziomowe połączenie z bazą danych i dlaczego coś tam jest nieoptymalne. Mówię, że korzystam z ORMów i raczej nie miałem potrzeby takiego łączenia się z bazą. W odpowiedzi dostałem – dziękujemy, brakuje Panu doświadczenia 😉 Co sądzisz o takim podejściu pracodawców? 🙂

  • Pirx napisał(a):

    brak jednej z podstawowych rzeczy: jakość kodu i dokumentacji.

    jeśli wyprodukujesz nieczytelny (spaghetti) kod, bez komentarzy i dokumentacji to cała robotę można sobie w dupę włożyć.

  • Pawel napisał(a):

    Dzięki za wartościowe rady. Dla kogoś kto zaczyna jak najbardziej będą przydatne. Dla kogoś z doświadczeniem – pewnie mniej bo już sobie takie metody sam wypracował. Mimo wszystko, muszę Ci pogratulować, bo fajnie napisane a w komentarzach zawsze się znajdą narzekacze.

  • mimE napisał(a):

    Programuję już od kilku dobrych lat, znam C/C++, Javę, a teraz jestem w trakcie tworzenia projektu w Objective-C na iOSa. Przez całą moją przygodę z pisaniem nie poznałem żadnych narzędzi/sposobów, które pomogłyby mi w rozpoczęciu pracy w zespole (nie wliczając pracy z BitBucketem w XCodzie – dopiero zaczynam). Masz jakieś rady od czego mogę zacząć i co będzie użyteczne/potrzebne?

  • Jakub napisał(a):

    Zapewne spotkałeś sie w swojej karierze z książką “Symfonia C++ Jerzego Grębosza”. Jeśli nie to w skrócie jest to cegla gdzie są opisane wszystkie aspekty c++ bardzo dokładnie. I tutaj pada moje pytanie – czy początkującemu programiscie (w sumie to nawet nie programiście) dobre jest zaczynanie od takich cegieł? Przeczytałem około 200 stron, dopiero jestem na tablicach, a napisałem mniej niż 10 prostych programów. Czy nie jest to bezczelne łamanie zasady pierwszej? Czy mozesz mi nieco poradzić co powinienem zrobic?

  • Jakub Jurkian napisał(a):

    Dzięki Mateusz za konkretny artykuł!
    Co jakiś czas do niego wracam, żeby pamiętać “nie ciśnij tak mocno, to nie musi być idealne”.

    Masakra… ile czasu zmarnowałem na siedzenie długimi godzinami nad jakimś bugiem (działałem w JavaScripcie). A wystarczyło zadać odpowiednie pytanie dla Googla albo Stack Overflow i – przede wszystkim – nauczyć się debugować kod.

    Dodałem do tego swoje 3 grosze i powstał z tego artykuł na 2000 słów.
    https://jakubjurkian.pl/mity-bledy-praca-programisty/

    Może komuś będzie przydatny.

  • nauczyciel_pl napisał(a):

    “Pamiętam ze studiów, jak musieliśmy napisać w notatniku łączenie z bazą danych w php: bez internetu, czy dokumentacji. Niestety tacy nauczyciele, na których czasami trafiłem bardzo zniechęcali do programowania. ”

    No i? A wiesz, że w dzisiejszych czas każdy przyszły technik informatyk musi to umieć zrobić z palca bo na egzaminie nie ma dokumentacji? Jeśli nauczyciel nie wymusi, to uczeń polegnie na egzaminie. I wiesz co, bardzo często zdarza mi się programować zarobkowo, więc wrzutka, że nauczyciel wymuszający nauczenie się połączenia z bazą danych jest słaby i zniechęca do nauki programowania bo sam nigdy nie programowała jest bardzo słabe. Tym bardziej, że jest to raptem kilka linijek kodu….

    Z całą resztą się zgadzam ale takie wrzutki są niepotrzebne.

    • JavaDevMatt napisał(a):

      Pozostaje pytanie po co komu tak oderwane od rzeczywistości egzaminy. 😀 Cały formalny system edukacji, to w większości jedne wielkie marnowanie zasobów i skutecznie zniechęcanie do nauki. Moim zdaniem należy to krytykować i nagłaśniać.

    • Rumcajs napisał(a):

      Powstaje pytanie, czy uczysz się, aby umieć programować, czy aby zdać egzamin. Jesli egzamin tak wyglada, to problemem jest wlasnie egzamin, a nie to, że nie chcesz sie uczyć na pamięć tematów, ktore w pamieci siedziec nie muszą…

Dodaj komentarz

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