Produkty a nástroje

Když chce malíř vytvořit obraz (produkt) vezme štětec (nástroj) a namaluje ho. Jasné jako facka. Co ale vlastně dělá malíř, když vezme tužku a namaluje si nejdřív skicu?

Skica se tvoří stejně jako výsledný produkt, vypadá jako výsledný produkt, ale ve skutečnosti je to nástroj, který autorovi pomáhá výsledný produkt vytvořit.

Tato dvojznačnost nástrojů se v různých variantách vyskytuje velmi často. Třeba když se staví dům, je potřeba nejdřív postavit lešení, které samo o sobě vyžaduje stavařský um, zastalo by i nějaké z funkcí stavby, ale před dokončením je strženo. Sloužilo jen jako nástroj zedníků.

Bohužel co je ve fyzickém světě vidět na první pohled je v myšlenkovém světě bez patřičných rozpoznávacích atributů mnohem nejasnější. Selský rozum většinou považuje jakoukoli mentální práci za práci na produktu a to nejen v programování. Ať už otevřete textový editor k sepsání dokumentu, IDE k napsání algoritmu nebo databázi ke psaní dotazů tak se předpokládá, že výsledek je určen ke konzumaci zadavatelem nebo že je to alespoň část takového výsledku.

Úplně se zapomíná na to, že k práci na produktu je potřeba, aby měl jeho autor rozmyšleno konkrétně co a jak chce do produktu vložit. To se bere jako samozřejmé, případně se to považuje za kvalitu, která definuje “experta” nebo “lídra”. Ve skutečnosti ale i největší expert začíná na každé netriviální práci ze stejné nuly, jako všichni ostatní a svojí cestu k uchopení zadání si musí poctivě odpracovat.

A to je právě ten druhý způsob, kterým jsou nám nástroje užitečné. Jako rozšíření naší mysli, pomocí kterého se dokážeme orientovat v komplexitě nebo rozsahu, na které sebetalentovanější představivost nestačí. Textový editor tak nemusí sloužit jen k sazbě dokumentů, ale může sloužit k organizaci a třídění vlastních poznámek. Stejně tak programovací jazyk kromě svého primárního účelu může také pomáhat rozpoznávat abstrakce a nebo databáze může pomáhat s odhalováním souvislostí v datech.

Proč o tom celém píšu? Protože účel práce s nástroji ovlivňuje úplně všechno. Jaké nástroje si vybíráme, co je na výsledku důležité a co, s kým a jak sdílíme. Například u dokumentu pro zákazníka je důležitá typografie, firemní branding, změnová tabulka, formální revizní proces, prostě vše, co zajišťuje profesionální dojem. Naproti tomu pro organizaci myšlenek, které mají tvořit obsah toho dokumentu, je důležitá hustota informací, neustálá dostupnost ke čtení i zápisu, jednoduchost provádění změn, anotace, prostě vše, co podporuje proces tvorby.

Ty první požadavky splňuje Word na sdíleném úložišti, ty druhé markdown texťák v gitu. Stejně je možné proti sobě postavit třeba aplikační servery a REPL nebo BI systémy a Jupyter notebooky. Každý marketing bude sice vždy tvrdit, že právě jeho řešení je one-size-fits-all, ale to je prostě z podstaty nemožné.

Je možné namítnout, že algoritmizace je, na rozdíl od psaní volného textu, inženýrská činnost. Takže ačkoli paralela mezi obrazem a skicou může ještě trochu platit pro textové editory, tak pro programovací jazyky a prostředí už ne, protože tam by se mělo pracovat v mantinelech jasného plánu a ověřených návrhových vzorů.

Takový předpoklad stojí na představě tvorby software jako aktu designu, tedy že autor formuluje problém za pomoci abstrakcí, které si arbitrárně vybere. To je ale podle mě kořen většiny problémů s overengineeringem a jiných diskrepancí mezi vyvinutým řešením a skutečnou potřebou. Mnohem přínosnější je brát vývoj software jako akt objevování, při kterém se snažíme odhalit abstrakce, které jsou v problému inherentně přítomné.

Právě v tom nám mohou nástroje dramaticky více pomoci, pokud si připustíme různorodost jejich významu a zařídíme se podle ní. Je to těžké přijmout pro makáče i jejich manažery, protože z toho kouká násobně víc práce a místo jednotné vojenské disciplíny musí naopak každý pracovat sám na sobě. Přesto se to, stejně jako skicy, vyplatí dělat každému, komu záleží na dobrém výsledku.

Douška

Ačkoli mám tento koncept v hlavě už dlouho, neuvědomil jsem si až do nedávna jeho hloubku. Narážel jsem na něj hlavně skrze frustraci - třeba když jsem chtěl diskutovat s projekťákem o osnově nějakého dokumentu a první otázka byla, proč to nemám sepsané ve Wordu. Nebo když někdo nechápal, že automatické testy mají několikanásobně větší význam než samotné QA.

Před rokem jsem ale četl knihu o teorii kategorií, na kterou moje inteligence bohužel nestačila, přestože byla psána poměrně populární formou. Měl jsem příliš slepých míst a mnoho otázek k nim na které mi neměl kdo odpovědět. Nedokázal jsem si proto pospojovat jednotlivé části ve srozumitelný celek.

V jednom z okamžiků velkého zoufalství mě napadlo zapsat svojí hypotézu, kterou jsem si nebyl jistý, ve formě Haskel kódu. Haskel totiž sám o sobě představuje z matematického pohledu validní kategorii. A kompilátor to skutečně přeložil - hypotéza byla validní! Zkusil jsem si další krok a kompilátor protestoval. Jeho hláška ukázala na chybu v mojí logice.

Je těžké popsat ten podivný pocit, když se z nástroje který mě má na slovo poslouchat, stane učitel, který mi skrze oboustranou diskuzi pomáhá pochopit, co vlastně dělám. Všichni se bojí, co se stane, až umělá inteligence překoná tu lidskou. Za mě to už nastalo a dobrý, dokud si to bude nechávat takhle pro sebe a rozdávat rozumy jen těm, kdo umí poslouchat.