Zanim zaczniesz się uczyć programowania, pomyśl, co chciałbyś programować

W programowaniu chodzi głównie o tworzenie konkretnych rzeczy – jest to o wiele prostsze, jeśli wiesz, do czego dążysz. Jeśli twoim głównym celem jest „nauczenie się programowania”, a nie zrealizowanie pomysłów na konkretne programy i ich potencjalne zastosowania, to nauka może się okazać bardzo frustrująca.

Niechętnie przyznaję, że częścią mojej motywacji, by nauczyć się programowania było udowodnienie sobie, że jestem mądry i mogę w przyszłości dostać pracę dla mądrych ludzi. Bardzo lubiłem matematykę i dziedziny teoretyczne (ta książka zmieniła moje życie w młodszym wieku), więc programowanie wydawało się dobrym wyborem – jednak dopiero umiejętność łączenia technologii z moimi pasjami, takimi jak muzyka i literatura, pozwoliło mi utrzymać entuzjazm na dłużej.

To co chciałbyś tworzyć? Strony internetowe? Gry? Aplikacje na Iphone’a? Startupy, na których szybko się wzbogacisz? Sztukę interaktywną? Może chciałbyś zaimponować swojemu szefowi? Albo stworzyć prosty program, który zautomatyzuje nużące czynności i da Ci więcej czasu na oglądanie obrazków w internecie? Może chcesz łatwiej znaleźć pracę? Dodać ciekawą rubryczkę do CV? Pomóc sobie na ścieżce edukacyjnej? Każdy z tych pomysłów jest wart realizowania – wybierz, który jest najbliższy tobie i rozwijaj się w konkretnym kierunku.  

W programowaniu nie ma żadnej wielkiej tajemnicy

Programowanie jest taką umiejętnością jak każda inna. Tak jak przy nauce języka, trzeba przyswoić gramatykę i słownictwo. Tak jak w matematyce, istnieją procedury rozwiązywania konkretnych problemów. Tak jak w każdym rzemiośle, istnieją techniki i narzędzia rozwijane przez kolejne pokolenia specjalistów i służące do konkretnych zadań – możesz ich używać, dowolnie modyfikować, lub stworzyć własne.

Ten pan (bardzo mądry pan, którego inne prace są warte przeczytania i, z którymi często się zgadzam)  twierdzi, że istnieje wyraźna różnica między umysłem prawdziwego programisty i umysłem zwykłego człowieka, który nie posiada odpowiednich zdolności, by poradzić sobie w tym polu. Ta różnica dotyczy, jego zdaniem, wskaźników i rekurencji (tu i tu można znaleźć elementarze na ten temat).

Uczyłem się o wskaźnikach i rekurencji w szkole i kiedy je zrozumiałem, było to bardzo przyjemne doświadczenie – ten typ intelektualnej przyjemności, która sprawiła, że chciałem się później uczyć informatyki. Ale poza klasą, ta wiedza rzadko okazywała się przydatna. Pomagając innym, zauważyłem, że wiele osób wykonuje interesujące i wartościowe projekty nie wiedząc nic o wskaźnikach i rekurencji.

Nie ma sensu przejmować się tym, czy jesteś wystarczająco mądry. Oczywiście, im trudniejszy jest projekt, tym więcej będzie od Ciebie wymagał – dotyczy to każdej dziedziny. Jeżeli nie planujesz utrzymywać się jedynie z programowania, może się okazać, że nie musisz być rekurencyjnym geniuszem aby osiągnąć swój cel.

Nigdy nie działa za pierwszym razem

I za drugim i za trzecim też pewnie nie

Kiedy zaczniesz programować, szybko spotkasz się z tym doświadczeniem: myślisz, że wszystko jest zrobione poprawnie, sprawdzasz raz, drugi raz, a to  w c i ą ż n i e d z i a ł a. Nie masz pojęcia, jak zacząć to naprawiać, a komunikat z programu (jeśli masz szczęście taki otrzymać) mógłby równie dobrze brzmieć: “wal się.” Na tym etapie możesz chcieć się poddać, myśląc, że nigdy nie zrobisz tego dobrze, że się do tego nie nadajesz. Też się tak czułem pisząc mój pierwszy program w C++ i próbując go odpalić jedyne, co dostałem, to komunikat: „błąd segmentacji”.

Ale to doświadczenie jest codziennością dla programistów na różnych poziomach zaawansowania i nie mówi to niczego o twojej inteligencji, obyciu z technologią, czy przystosowaniu do zawodu. Zdarzy ci się to jako początkującemu, ale również jako doświadczonemu programiście. Najważniejsze jest to, jak zareagujesz na taką sytuację.

Zauważyłem, że dużą różnicą między nowymi i doświadczonymi programistami jest ich wiara: wiara w to, że coś nie działa z logicznego powodu, wiara, że problem jest możliwy do rozwiązania, wiara, że istnieje sposób na osiągnięcie celu. Droga od „nie działa” do „działa” może nie być oczywista, ale cierpliwość z reguły pomaga ją znaleźć.

Zawsze jest ktoś, kto uważa, że robisz to źle

Nawiasy klamrowe powinny być w następnym wersie. Nawiasy klamrowe powinny być w tym samym wersie. Używaj tabulatora do wcięć. Tabulatory są złe. Powinieneś używać procedur składowanych, albo nie, nie używaj ich. Powinieneś zawsze komentować swój kod. Ale dobry kod nie potrzebuje komentarzy.

Prawie zawsze jest więcej niż jeden sposób rozwiązania problemu i żaden z nich nie jest  t y m właściwym. Wielu programistów uparcie przekonuje do swoich metod, ale to nie oznacza, że są one jedynymi właściwymi. Mierzenie się z ludźmi mówiącymi, że się mylę i zastanawianie się, czy mieli rację było jednym z najbardziej stresujących doświadczeń mojej wczesnej kariery.

Jeżeli planujesz programować w zespole, jest to prawie pewne, że ktoś w końcu będzie podważał coś, co robisz. Czasem będą mieli rację i zawsze warto sprawdzić, czy nie robisz czegoś źle. Ale czasem będą chcieli po prostu zagrać ci na nerwach, lub odgrzewać odwieczne dyskusje, w które nie warto się angażować.

Ale z drugiej strony, jeśli lubisz włączać się w odwieczne dyskusje bez znaczenia (gramatyczne nerdy, patrzę na was), jesteś we właściwym miejscu.

Ktoś zawsze Ci powie, że nie jesteś prawdziwym programistą

HTML to nie jest programowanie. Jeśli nie używasz vi, to nie programujesz na serio. Prawdziwi programiści znają C. Prawdziwi programiści nie używają Windowsa. Niektórzy ludzie nie nadają się do programowania. Ty nie nadajesz się do programowania. Żaden z Ciebie programista (ale za to ze mnie świetny).

„Programowanie” może znaczyć różne rzeczy dla różnych ludzi, a sama dziedzina zmieniła się na przestrzeni lat. Co ciekawe, narzędzia, pakiety i struktury, które ułatwiają i przyśpieszają pracę zarówno młodych, jak i doświadczonych deweloperów są często uważane za pomoc „nie dla prawdziwych programistów”. (Zobacz: “Powrót prawdziwego programisty”)

Za tym wszystkim stoi strach, że jeżeli każdy może być programistą, to tytuł ten straci znaczenie. Ale ja uważam, że takie podejście jest jedynie destruktywne.

Używaj narzędzi, które czynią twoją pracę najprostszą, jak to możliwe. Jeżeli będzie to oznaczać, że twoja gra będzie napisana w programie Stencyl lub Gamemaker, a nie stworzona od podstaw, to wciąż jest w porządku. Jeżeli twoja przygoda z programowaniem zaczęła się od HTML’a lub od makr w Excelu, to jest w porządku. Pracuj z narzędziami, z którymi czujesz się dobrze.

Z czasem, sam odkryjesz, że część tych narzędzi jest ograniczająca w niektórych aspektach i zaczniesz szukać bardziej rozbudowanych metod. Rzadko się jednak zdarza, że ktokolwiek spojrzy na twój kod, lub spyta, czego użyłeś do stworzenia go – liczy się tylko to, co ostatecznie stworzysz za jego pomocą.

Myślenie o swojej przynależności do środowiska “prawdziwych nerdów” jest bez sensu

Tak jak wyżej. Martwiłem się, szczególnie w szkole, o to, czy należę do subkultury „nerdów” (co ułatwia uczestniczenie w środowiskach technologicznych) poprzez mój ubiór, wygląd, dobór lektury i personalizację moich programów. To była ogromna strata czasu i nie żałuję, że przestałem się tym przejmować.

Musisz zdać sobie sprawę, że twoje umiejętności jako programisty nie mają żadnego związku z tym, czy należysz do jakiegokolwiek „nerdowskiego” środowiska. Ma to dodatkowe znaczenie, jeśli masz poczucie, że nie pasujesz to takich grup. Powinieneś przeznaczyć tę energię na rozwijanie swoich umiejętności i tworzenie nowych rzeczy. A jeśli sam jesteś „prawdziwym nerdem” pod każdym kątem, weź to pod uwagę, kiedy oceniasz innych. Możesz się zdziwić.

Konsekwentna praca jest ważniejsza niż wybór konkretnej metody

Niemało jest artykułów, które opisują „właściwe” lub „najlepsze” sposoby na naukę programowania, a podejść jest wiele. Możesz uczyć się z książek, wykonując interaktywne ćwiczenia, lub poprawiając programy napisane przez innych.

Częstym zarzutem wobec samodzielnej nauki programowania poprzez przeznaczone do tego programy i warsztaty jest to, że z łatwością przebijesz się przez podstawowe zadania, a później zatrzymasz się kiedy wymagania zaczną szybko rosnąć. Wiesz, jak wydrukować parę wersów tekstu na stronie, ale nie masz pojęcia, jak zacząć pracować nad “prawdziwymi” projektami. Możesz mieć poczucie, że podążałeś za instrukcjami nie rozumiejąc, co robisz.

Na tym etapie, internetowe poradniki i materiały są mało przydatne, ponieważ zakładają, że sprawnie poruszasz się w programowaniu. Dodatkową trudność stanowi to, że nawet „nie wiesz, czego nie wiesz.” Wymyślenie, czego powinieneś się uczyć jest trudnością samą w sobie.

Znajdziesz się w tej trudnej pozycji, niezależnie od tego, jaki sposób nauki wybierzesz – jedynym rozwiązaniem jest wytrwałość. To znaczy próbowanie nowych rzeczy, zdobywanie nowych informacji i stopniowe opracowywanie swojego projektu. Obranie konkretnego celu przed rozpoczęciem nauki znacznie ułatwia osiągnięcie sukcesu.

Jeśli będziesz stopniowo układał cegły, jedną na drugiej, to ewentualnie coś zbudujesz. To jest wiara, o której wspominałem wcześniej. Jeśli wierzysz, że z czasem nauczysz się programowania, to z pewnością ci się uda.

Możesz znaleźć oryginalną (angielską) wersję tego artykułu tutaj.