Od učení programování ke skutečnému stavění

Když se člověk začne učit programovat, pokrok bývá ze začátku poměrně dobře vidět. Naučí se proměnné, podmínky, cykly, funkce, práci s databází, nějaký framework a postupně dokáže následovat stále složitější návody.

Pak ale často přijde zvláštní moment.

Člověk rozumí kódu, který vidí před sebou. Dokáže vysvětlit, co jednotlivé části dělají. Když má tutorial nebo dostatečně přesné zadání, umí ho dokončit. Jenže když otevře prázdný projekt a řekne si „teď postavím něco vlastního“, najednou neví, kde začít.

Tenhle rozdíl mi přijde mnohem důležitější než počet technologií, které člověk zná.

Umět programovat a umět něco postavit totiž nejsou úplně stejné schopnosti.

Programování nám dává stavební bloky. Stavění produktu vyžaduje navíc rozhodnout, které z nich použít, jak problém rozdělit, co udělat jako první a jak pokračovat ve chvíli, kdy neexistuje návod přesně pro naši situaci.

A právě v téhle mezeře podle mě spousta lidí při učení uvízne.

Tutorialy řeší spoustu rozhodnutí za nás

Na dobrém tutorialu není nic špatného. Když se učím nový framework nebo technologii, často je to nejrychlejší způsob, jak pochopit základní principy a vidět je rovnou v praxi.

Problém vzniká, když si při tom nevšimneme, kolik práce už za nás udělal autor.

Rozhodl, co budeme stavět. Vybral technologie. Navrhl strukturu projektu. Určil pořadí kroků a vyřadil slepé cesty, kterými se při přípravě možná sám vydal. Když přijde problém, většinou už zná jeho řešení a může nás k němu dovést.

My potom píšeme kód, ale velká část rozhodování už proběhla před námi.

Proto může vzniknout velmi nepříjemná iluze. Dokončíme několik aplikací, rozumíme tomu, co jsme napsali, a máme pocit, že bychom měli zvládnout podobný projekt sami.

Pak si například řekneme, že vytvoříme vlastní jednoduchou aplikaci na správu úkolů, otevřeme editor a objeví se první otázky.

Jaké objekty vlastně potřebujeme? Kde začít? Nejdřív databáze, nebo rozhraní? Jak má vypadat přihlášení? Kam dát data? Jak strukturovat projekt? Jak propojit frontend s backendem? A co máme vůbec vyhledat, když ještě nevíme, jak se problém jmenuje?

Tutorial tyto otázky často schová. Samostatný projekt je naopak položí všechny najednou.

Právě proto může být první vlastní aplikace překvapivě těžká, i když její jednotlivé části už technicky známe.

Nejtěžší není napsat kód, ale rozdělit problém

Představme si požadavek:

„Chci, aby se uživatel mohl přihlásit.“

Pokud už známe konkrétní technologii, samotná implementace nemusí být příliš složitá. Jenže předtím musíme z neurčitého požadavku vytvořit sérii konkrétních problémů.

Jak uživatele reprezentujeme v databázi? Registruje se e-mailem a heslem, nebo přes externí službu? Jak se heslo bezpečně ukládá? Jak aplikace pozná, že je člověk přihlášený? Jak dlouho přihlášení platí? Co se stane po odhlášení? Jak obnovíme zapomenuté heslo? Které stránky mají být dostupné pouze přihlášeným?

Najednou už neřešíme jeden úkol, ale celý strom menších rozhodnutí.

A právě schopnost takový strom vytvořit je podle mě jedna z hlavních dovedností, které se člověk při samostatném stavění učí.

Zkušenější developer často nevypadá rychlejší proto, že by napsal jednu funkci desetkrát rychleji. Spíš dokáže neurčitý problém mnohem rychleji převést na několik menších problémů, které už řešit umí.

Začátečník vidí:

„Musím postavit e-shop.“

Zkušenější člověk začne přemýšlet nad katalogem, produkty, variantami, košíkem, objednávkou, platbou a jednotlivými vztahy mezi nimi.

Velký neznámý problém se tím postupně mění na sérii menších otázek.

A s menšími otázkami se pracuje mnohem lépe.

Prázdný projekt je součást učení

Při učení máme přirozenou tendenci chtít postupovat efektivně. Když se zasekneme, najdeme video, článek, AI nebo hotový příklad a pokračujeme.

To je často správně. Nemá cenu několik hodin znovu objevovat něco, co je dobře popsáno v dokumentaci.

Jenže existuje rozdíl mezi hledáním odpovědi na konkrétní problém a hledáním někoho, kdo za nás celý problém strukturoval.

Pokud například nevím, jak ve frameworku vytvořit dynamickou route, dokumentace je přesně to, co potřebuji.

Pokud ale hledám „full Next.js e-commerce tutorial“ a potom jen změním barvy, velmi snadno znovu předám většinu důležitých rozhodnutí autorovi.

Proto mi přijde užitečné strávit určitou část času i v nepříjemném stavu, kdy ještě nevím, co dělat.

Zkusit si problém nakreslit. Sepsat potřebné části. Odhadnout, jak by spolu mohly komunikovat. Udělat první verzi, zjistit, že byla špatně, a změnit ji.

Tahle fáze může působit jako neproduktivní tápání, ale právě během ní se člověk učí samostatnost.

Když nám pokaždé někdo okamžitě ukáže správnou cestu, naučíme se po ní chodit. Nemusíme se ale naučit ji sami najít.

Umět hledat je součást programování

Samostatné stavění neznamená mít všechno v hlavě.

Ani zdaleka.

Čím déle programuji, tím méně mi přijde podstatné pamatovat si přesnou syntaxi a tím důležitější je umět zjistit správnou informaci ve chvíli, kdy ji potřebuji.

Rozdíl je hlavně v kvalitě otázky.

„Moje aplikace nefunguje“ je problém, se kterým se pracuje špatně.

„Po odeslání formuláře dostávám z API status 401, přestože session cookie v prohlížeči existuje“ je už výrazně lepší začátek.

Člověk musí nejdřív poznat, kde přibližně problém leží, co už ověřil a která informace mu chybí. Teprve potom začínají být dokumentace, vyhledávač nebo AI opravdu silné nástroje.

Stejně důležité je nenechat si řešení jen podat a pokračovat dál. Pokud narazím na kód, který problém opraví, ale vůbec nerozumím tomu proč, vytvořil jsem si velmi křehkou znalost.

Při podobném problému příště budu pravděpodobně hledat stejné řešení znovu.

Mnohem hodnotnější je pochopit mechanismus pod ním. Co bylo špatně? Proč změna pomohla? Jak bych stejný problém poznal jinde?

Tím se z jednotlivých odpovědí začínají postupně skládat principy.

Kopírování kódu není problém, pokud víme, co kopírujeme

Programování vždycky obsahovalo práci s existujícími řešeními a s AI je dnes množství generovaného kódu ještě mnohem větší.

Nemyslím si proto, že správný způsob učení je všechno psát ručně bez pomoci.

To by byla zbytečně umělá překážka.

Pokud mi AI připraví základ komponenty, vygeneruje opakující se část API nebo ukáže příklad použití knihovny, může mi ušetřit spoustu mechanické práce.

Problém nastává ve chvíli, kdy se rychlost generování začne vzdalovat rychlosti našeho porozumění.

Dokud umím vysvětlit, co daná část dělá, poznám, když je špatně, a dokážu ji změnit podle potřeby, nástroj mi pomáhá.

Pokud ale celý produkt drží pohromadě jen proto, že jsem opakovaně kopíroval řešení, kterým příliš nerozumím, dříve nebo později narazím na problém, který se do předchozích vzorů nevejde.

A přesně tam se ukáže rozdíl mezi schopností produkovat kód a schopností řídit jeho chování.

AI tedy podle mě potřebu naučit se stavět neodstranila. Spíš ještě více snížila hodnotu samotného psaní syntaxe a zvýšila hodnotu porozumění tomu, co se v systému skutečně děje.

Vlastní projekt vás donutí dělat rozhodnutí, která tutorial nepotřebuje

Jakmile začneme něco vlastního, narazíme na věci, které v učebních projektech často nemají jednu správnou odpověď.

Máme použít vlastní autentizaci, nebo externí službu?

Potřebujeme backend zvlášť, nebo stačí funkce uvnitř stejného frameworku?

Má být určitá informace samostatná databázová tabulka, nebo jednoduché pole?

Má smysl řešit konkrétní případ obecně, nebo teď stačí jednoduché řešení?

Často najdeme deset článků a každý doporučí něco jiného.

To může být ze začátku frustrující, protože jsme zvyklí hledat správnou odpověď. Jenže u návrhu softwaru často žádná univerzální není.

Existují kompromisy.

Jedna cesta bude jednodušší, druhá flexibilnější. Jedna levnější dnes, druhá možná výhodnější při větším růstu. Jedna vyžaduje méně infrastruktury, druhá dává větší kontrolu.

Člověk se tedy postupně musí naučit rozhodnout podle svého konkrétního projektu a přijmout, že některé rozhodnutí později změní.

Tohle je podle mě velká část přechodu od učení programování k samotnému stavění.

Přestáváme hledat způsob, jak se to dělá, a začínáme řešit, jak to dává smysl udělat právě tady.

První vlastní projekt by měl být menší, než chcete

Když člověk konečně přestane kopírovat tutorial a chce něco postavit sám, velmi snadno si vybere projekt, který je příliš velký.

Sociální síť.

Kompletní e-shop.

Vlastní Discord.

Obrovský SaaS s několika rolemi a předplatným.

Technicky není nic špatného na tom mít podobnou ambici. Pro učení je ale podle mě mnohem hodnotnější zvolit něco, co dokážeme projít od prázdné složky až k nasazené a používané verzi.

Například místo kompletního systému pro řízení firmy vytvořit malou aplikaci na evidenci jednoho konkrétního procesu.

Místo celého e-shopu postavit katalog s košíkem a jednoduchým dokončením objednávky.

Místo sociální sítě vytvořit jeden funkční proces publikování a zobrazování příspěvků.

Jakmile základní cesta funguje, můžeme ji rozšiřovat. Pokud se ale projekt skládá od prvního dne z patnácti velkých oblastí, budeme velkou část času jen přepínat mezi rozpracovanými problémy a pravděpodobnost dokončení rychle klesá.

Vlastní projekt má podle mě člověka naučit nejen začínat, ale také dokončovat.

Záměrně si odeberte část návodu

Poměrně praktický způsob, jak přejít od tutorialů k samostatné práci, je nedělat ten skok najednou.

První krok může být jednoduchý: projít tutorial a potom jeho výsledek rozšířit o funkci, kterou autor neřešil. Najednou už musíme sami zjistit, kde změnu udělat a jak ji propojit se stávajícím systémem.

Další projekt můžeme postavit podle stejného konceptu, ale bez sledování konkrétního návodu. Máme například zkušenost s todo aplikací, tak vytvoříme jednoduchý systém poznámek. Principy jsou podobné, ale jednotlivá rozhodnutí už musíme dělat sami.

Potom můžeme zkusit projekt, u kterého pouze víme, čeho chceme dosáhnout, a dokumentaci nebo AI používáme až pro jednotlivé problémy, na které během práce narazíme.

Postupně tak snižujeme množství struktury, kterou dostáváme zvenku.

Není potřeba jeden den zavřít všechny návody a od té chvíle všechno vymýšlet bez pomoci. Důležité je, aby se podíl rozhodnutí, která děláme sami, postupně zvětšoval.

Právě tím se buduje samostatnost.

Poznáte to podle typu problémů, které začnete řešit

Pokrok v programování se často měří podle technologií.

Umím JavaScript.

Naučil jsem se React.

Teď znám Next.js.

Používám PostgreSQL.

Takový přehled je užitečný, ale podle mě není nejlepším ukazatelem toho, jestli se člověk opravdu posouvá k samostatnému stavění.

Mnohem zajímavější je sledovat, jaké otázky dokáže řešit.

Na začátku se ptá:

„Jak udělám tlačítko?“

Později:

„Jak po kliknutí bezpečně změním tento stav a promítnu ho do databáze?“

Ještě později:

„Má vůbec tahle akce měnit tento objekt, nebo jsme špatně navrhli datový model?“

Technologie může být pořád stejná.

Změnila se ale úroveň problému.

Člověk postupně přestává uvažovat jen v jednotlivých řádcích nebo funkcích a začne vidět části systému, jejich vazby a důsledky rozhodnutí.

Právě to je pro mě mnohem silnější znak pokroku než další logo technologie v seznamu dovedností.

Zaseknutí není důkaz, že ještě neumíte programovat

První samostatné projekty bývají nepříjemné hlavně proto, že člověk má pocit, že by už měl vědět, co dělat.

Po několika měsících učení očekává, že dokáže otevřít editor a jednoduše začít stavět.

Pak stráví dvě hodiny problémem, který v tutorialu vypadal jako deset minut, a začne mít pocit, že se nic nenaučil.

Jenže právě to zaseknutí je často nová část učení.

Poprvé už neřešíme problém, který někdo před námi vyčistil a připravil. Musíme sami zjistit, kde začít, co je relevantní a co ignorovat.

To přirozeně trvá déle.

S každým podobným problémem si ale vytváříme další zkušenost. Příště poznáme některé vzory rychleji, budeme vědět, kde hledat, a velký problém dokážeme dřív rozdělit.

Samostatnost tedy nepřichází ve chvíli, kdy už se nikdy nezasekneme.

Spíš ve chvíli, kdy víme, co dělat, když se zasekneme.

Jak bych dnes postupoval, kdybych se učil programovat znovu

Základy bych se pořád učil strukturovaně. Syntaxi, datové typy, funkce, práci s asynchronním kódem, HTTP, databáze a základní principy frameworku je podle mě výrazně jednodušší pochopit s kvalitním kurzem nebo návodem než náhodným experimentováním.

Jen bych se mnohem dřív snažil znalosti používat mimo přesný kontext, ve kterém jsem je získal.

Po každém větším tématu bych postavil něco malého bez kompletního návodu. Nemusí to být originální startup ani produkt, který někdo koupí. Stačí projekt, kde znám požadovaný výsledek, ale cestu si musím určit sám.

Když bych se zasekl, použil bych dokumentaci, vyhledávání nebo AI. Snažil bych se ale hledat odpověď na co nejkonkrétnější problém místo kompletního řešení celé aplikace.

A hlavně bych projekty dokončoval.

Raději pět malých věcí, které jsem od začátku navrhl, postavil a nasadil, než jednu obrovskou aplikaci, jejíž prvních dvacet procent jsem třikrát přepsal podle různých tutorialů.

Každý dokončený projekt totiž uzavře další učební cyklus. Nejen že něco napíšeme, ale také zjistíme, jestli naše rozhodnutí fungovala jako celek.

Kdy tedy člověk skutečně umí něco postavit?

Podle mě to není ve chvíli, kdy přestane používat Google, dokumentaci, AI nebo cizí kód. Takový stav pravděpodobně ani není žádoucí.

Rozdíl je v tom, kdo řídí celý proces.

Pokud potřebujeme návod, který nám říká, jaký má být další krok, pořád se primárně učíme následovat řešení.

Pokud naopak dokážeme sami popsat problém, rozdělit ho na menší části, rozhodnout se mezi několika možnostmi a potom si dohledat konkrétní znalosti, které nám chybí, začínáme skutečně stavět.

Nástroje nám pořád pomáhají.

Jen už za nás neurčují směr.

A právě proto bych se při učení nesoustředil jen na otázku:

„Kolik toho už umím?“

Mnohem užitečnější je podle mě:

„Co dokážu vytvořit, když mi nikdo předem nepřipravil cestu?“

Odpověď na druhou otázku mnohem lépe ukáže, jestli se naše znalosti začínají měnit ve skutečnou schopnost něco postavit.

Zdroje

• David A. Kolb — Experiential Learning
• John Sweller — práce o teorii kognitivní zátěže
• Lahtinen, Ala-Mutka & Järvinen — A Study of the Difficulties of Novice Programmers