Z esejů Paula Grahama jsem již (s laskavým svolením) přeložil Přebal Javy. Nyní se dostávám k delší a hlubší úvaze, kterou lze označit za kultovní. Původní text Hackers and Painters. (překlad uvolňuji pod licencí Creative Commons by-nc-sa)

Květen 2003

Tento esej vznikl z hostující přednášky na Harvardu, která zahrno­vala dřívější proslov na Northeas­tern Univer­sity Boston.

Když jsem dokončil inženýrské studium infor­ma­tiky, šel jsem na uměleckou školu studovat malíř­ství. Mnoho lidí, zdá se, překva­pilo, že někdo, kdo se zajímá o počítače, by se také mohl zajímat o malíř­ství. Očividně si mysleli, že hackování a malíř­ství jsou velmi odlišné druhy práce - hackování je chladné, přesné a metodické; zatímco malíř­ství je bouřlivé vyjádření nějakého prapůvod­ního nutkání.

Oba tyto pohledy jsou nesprávné. Hackování a malíř­ství toho mají mnoho společ­ného. Ve skuteč­nosti jsou všichni tito rozdílní lidé (hackeři a malíři), které znám, podobní.

Hackeři a malíři mají společné to, že obě skupiny jsou tvůrčí. Spolu se sklada­teli, archi­tekty a spiso­va­teli se hackeři a malíři snaží dělat dobré věci. Nedělají výzkum jako takový, přesto objeví-li při samotném pokusech o dobru věc nějakou novou techniku, tím lépe.

Architekti versus inženýři

Nikdy jsem neměl rád termín computer science. Hlavní důvod, proč ho nemám rád je, že taková věc neexi­s­tuje. Computer science je pytel, do kterého sesypali chabě spolu souvi­sející oblasti, dané dohro­mady jen historickou náhodou jako Jugos­lávie. Na jedné straně máte skutečné matema­tiky, ale nazvete jejich činnost computer science, takže můžou požádat DARPA ( Agentura pro výzkum pokroč­ilých obran­ných projektů) o grant. Někde upros­třed jsou lidé, které zajímá bezpros­třední historie počítačů - studují například chování algoritmů pro směrování dat skrze sítě. Druhým extrémem jsou hackeři, kteří se snaží napsat zajímavý software a pro které jsou počítače jen vyjadřo­vacím prostřed­kem. Jako beton pro archi­tekty nebo barva pro malíře. Je to jako kdyby matema­tici, fyzici a archi­tekti byli všichni v tom samém oddělení.

Někdy hackeři dělají něco, čemu se říká softwa­rové inženýr­ství, ale tento termín je zavádějící. Dobří softwa­rový desig­néři nejsou inženýři víc než archi­tekti. Hranice mezi archi­tek­turou a inženýr­stvím není ostře defino­vaná, ale je. A to mezi co a jak: archi­tekti rozho­dují co dělat, kdežto inženýři přicházejí na to, jak to udělat.

Co a jak by nemělo být příliš oddělováno. Říkáte si o malér, pokud se rozhod­nete co, aniž byste rozuměli, jak to udělat. Ovšem hackování může být zajisté víc než jen rozho­dování o tom, jak imple­men­tovat nějakou speci­fi­kaci. Nejlepší z toho je vytváření speci­fi­kace, třebaže nejlepší způsob, jak to učinit, je speci­fi­kaci imple­men­tovat.

Hackeři nejsou vědci

Možná jednou bude computer science jako Jugos­lávie, rozpadne se na malé části. Může to být pro dobro věci. Především znamená-li to nezávis­lost pro hackování, moji rodnou zem.

Spojit všechny tyto různé typy práce dohro­mady v jedno oddělení může být vyhovující administ­ra­tivně, ale matoucí intelek­tuálně. Je ještě další důvod, proč nemám rád označení jako computer science. Lidé upros­třed zřejmě dělají něco jako experi­men­tální vědu. Ale lidé na obou koncích, hackeři a matema­tici, ve skuteč­nosti vědu nedělají.

Matema­tici se tím zjevně nezne­po­ko­jují. Šťastně posta­vili práci na dokazování vět jako ostatní matema­tici v matema­tickém oddělení kolem a možná si brzy přestanou všímat, že budova, ve které pracují, má na sobě napsáno computer science. Zato s označ­ením pro hackery je potíž. Pokud nazveme jejich práci vědou, tak dostanou pocit, že by se s nimi mělo jednat vědecky. Takže místo toho aby dělali, co chtějí, což je navrhovat krásný software, budou hackeři na univer­zitách a v labor­kách mít dojem, že by měli psát výzkumné práce.

V nejlepším případě to bude forma­lita. Hackeři naprog­ra­mují úžasný software a pak o něm něco napíší. Tyto papíry se stanou zastou­pením pro to, čeho se daným softwarem dosáhlo. Nicméně často tenhle zmatek způsobí problém. Je snadné nechat se unést od stavby krásných věcí ke stavbě ošklivých, které jsou vhodnější jako objekt výzkumné práce.

Bohužel krásné věci nejsou vždy nejlepším objek­tem, o kterém by šlo psát. Výzkum musí být zaprvé originální - kdoko­liv, kdo psal diser­taci kvůli svému Ph.D. titulu, ví, že abyste s jistotou prozkoumávali nedotknuté území, vyžaduje to tvrdě hájit zem, kterou nikdo nechce. Zadruhé výzkum musí být dosta­tečně rozsáhlý a příšerný systém plodí tuny papírů, protože můžete psát o překážkách, které jste museli překo­nat. Nic nezaručí vydatný problém jako začít špatným předpok­la­dem. Většina umělé inteli­gence je příkladem tohoto pravidla; pokud předpok­ládáte, že znalost může být repre­zen­tována jako seznam predikátů logic­kých výrazů, jejichž proměnné repre­zen­tují abstraktní koncept, budete mít mnoho co psát, jak by to mělo fungo­vat. Jak Ricky Ricardo říkával: “Lucy, máš co vysvětlovat.”

Způsob jak vytvořit něco krásného je často v nepatr­ných kosme­tic­kých úpravách již existujícího, případně kombi­nací dosavad­ních myšlenek trochu jinak. Tento způsob práce je obtížné převést ve vědecké papíry.

Jak posuzovat kvalitu práce

Tak proč univer­zity a labora­toře stále soudí hackery podle publi­kací? Ze stejného důvodu jako je školní znalost měřena prostými standar­di­zo­vanými testy nebo produk­ti­vita programátorů měřena řádkami kódu. Tyto testy je jedno­duché aplikovat a není nic lákavějšího jako snadný test takového druhu práce.

Měření toho, o co se totiž hackeři pokouší, tj. návrh úžasného softwaru, by bylo mnohem obtížnější. Musíte mít smysl pro design, abyste mohli design posuzo­vat. A není žádná korelace, leda záporná, mezi schop­ností rozpoznat dobrý design a sebejis­to­tou, že to umí.

Jediný vnější test je čas. Časem se krásným věcem daří, a ošklivé bývají odloženy. Naneštěstí potřebný čas může být delší nežli lidský život. Samuel Johnson řekl, že trvá sto let, než se ustálí spiso­va­te­lova pověst. Musíte počkat než spiso­va­te­lovi vlivní přátelé a pak ještě jejich násle­dov­níci zemřou.

Domnívám se, že hackeři prostě musí resig­novat na velkou roli náhody, která ovlivňuje na jejich pověst. Nijak se tím neliší od ostat­ních tvůrců. Ve skuteč­nosti mají v tomto srovnání štěstí, protože vliv módy není v hackování ani zdaleka takový jako v malířství.

Skicování

Jsou horší věci, než to, že lidé neporo­zumí vaší práci. Horší je, že sami neporo­zumíte své práci. Souvisí to s tím, kde hledáte nápady. Když jste na oddělení computer science, máte například sklon věřit, že hackování je apliko­vaná verze computer science. Po celou dobu inženýr­ského studia jsem měl nepříjemný pocit někde vzadu v hlavě, že bych měl znát více teorie. Bylo pak ode mne velmi ledabylé, že jsem vše zapomněl do tří týdnů od státnic.

Nyní si uvědo­muji, jak jsem se mýlil. Hackeři potře­bují rozumět počítačové teorii stejně tak, jako malíři musí rozumět chemii barev. Potře­bu­jete znát jak vypoč­ítat časovou a paměťovou složi­tost a mít povědomí o turin­govské úplnosti. Měli byste si pamatovat i něco o stavových strojích, pro případ, že byste měli napsat parser nebo knihovnu pro regulární výrazy. Malíři si opravdu musí o barvách pamatovat mnohem víc.

Zjistil jsem, že nejlepší zdroj nápadů nejsou ostatní oblasti světa počítačů, ale oblasti společné i ostatním tvůrcům. Malíř­ství mi bylo mnohem bohatším zdrojem myšle­nek, než počítačová teorie.

Například nás ve škole učili, že bychom si měli program, před tím, než se vůbec přiblížíme k počítači, napsat celý na papír. Zkusil jsem si, že takhle nepro­gra­muji, že při tom rád sedím před počítačem, ne s kusem papíru. O co hůř, místo trpělivého psaní úplného programu a ujišťování se, že je správně, jsem měl sklony chrlit ze sebe kód, který byl beznadějně rozbitý a postupně ho stloukal do nějakého tvaru. Učili nás, že debugování je druh závěrečné zkoušky, kde zachytíme překlepy a to, co jsme doposud přehlédli. Způsob, jakým jsem praco­val, se spíš zdál jako progra­mování složené z debugování.

Dlouhou dobu mě to trápilo, stejně jako tehdy, když jsem se cítil provi­nile za to, že nedržím pero tak, jak nás to učili na základce. Kdybych se býval podíval na ostatní tvůrce, malíře nebo archi­tekty, uvědomil bych si, že pro to, co jsem dělal, existuje jméno: skicování. Můžu říct, že způsob progra­mování, který mě učili ve škole byl celý špatně. Musíte přijít na program zatímco ho píšete, stejně jako to dělají spiso­va­telé, malíři a architekti.

Uvědomění si toho má skutečný dopad na softwa­rový design. Znamená to, že progra­mo­vací jazyky by měly být především kujnou hmotou. Progra­mo­vací jazyk je k vymýšlení programů, ne k vyjadřování programů, které jste už vymys­leli. Měl by být tužkou, nikoliv perem. Staticky typované programy by byly krásný nápad, kdyby lidé psali programy tak, jak nás to učili ve škole. Ale tak žádný hacker, kterého znám, nepíše. Potře­bu­jeme jazyk, který nás nechá čmárat, šmudlat a mazat, ne jazyk, u kterého budete sedět s čajovým šálkem plných typů, balan­covat ho na koleni a vést zdvořilou konver­zaci s přísnou tetičkou kompilátorem.

Matematická závist

Když už jsme narazili na téma static­kého typování, identi­fi­ku­je­me-li se s tvůrci, ušetří nás to dalšího problému, který trápí vědu: matema­tická závist. Každý ve vědě tajně věří, že matema­tici jsou chytřejší, než ve skuteč­nosti jsou. Mám dojem, že matema­tici tomu taky věří. Každopádně ve výsledku se vědci snaží, aby jejich práce vypadalo co nejvíce matema­ticky. V oboru jako je fyzika to nejspíš nenapáchá tolik škody, ale čím víc se blížíme přírodním vědám, tím větší problém se z toho stává.

Stránka vzorečků prostě vypadá působivě. (Tip na extra působi­vost, použijte písmena řecké abece­dy). Což svádí k tomu, pracovat na problémech, které lze vyřešit formálně, spíš než na problémem, které jsou, řekněme, důležité.

Pokud se hackeři ztotožní s jinými tvůrci, jako spiso­va­telé a malíři, nebudou mít snahu tohle dělat. Spiso­va­telé a malíři netrpí matema­tickou závistí. Mají za to, že dělají něco naprosto nesou­vi­sejícího. Stejně jako hackeři, alespoň se to domnívám.

Velké firmy

Jestliže univer­zity a výzkumné labora­toře nepustí hackery k práci, kterou chtějí dělat, tak je pro ně možná vhodné místo ve firmách. Bohužel ani firmy nenechají dělat hackery co chtějí. Univer­zity a výzkumné labora­toře nutí hackery, aby byli vědci, a firmy je nutí, aby byli inženýry.

Objevil jsem to teprve nedávno. Když Yahoo koupilo Viaweb, zeptali se mě, co chci dělat. Nikdy jsem neměl příliš v lásce byznys, tak jsem řekl, že chci prostě hacko­vat. Když jsem se dostal do Yahoo, zjistil jsem, že pro ně hackování znamená imple­men­tovat software, nikoliv ho navrho­vat. Programátory brali jako techniky, kteří převádí vizi (jestli tomu tak lze říkat) produk­tových manažerů do zdrojového kódu.

To je, zdá se, výchozí plán ve velkých firmách. Činí tak proto, že tím snižují směro­datnou odchylku v příjmu. Pouze malé procento hackerů totiž může navrhovat software a pro lidi, kteří řídí firmy, je obtížné tyto lidi rozpoz­nat. Místo svěření budouc­nosti software jednomu brilant­nímu hacke­rovi se firmy zařídili tak, že design navrhuje výbor a hackeři ho pouze implementují.

Pokud chcete v nějakém bodu vydělat peníze, pamatujte toto, protože je to jeden z důvodů, proč startupy uspějí. Velké firmy chtějí snížit směro­datnou odchylku designu, protože se chtějí vyhnou katastrofě. Ovšem když oříznete oscilace, přijdete jak o vysoké hodnoty tak i o nízké. To je problém velkých firem, nevyhrají tím, že by dělali skvělý produkt. Velké firmy vyhrají, protože stojí za prd méně, než jiné velké firmy.

Pokud přijdete na to, jak vést desig­novou válku s dosta­tečně velkou firmou, kde je software navrhován produk­tovými manažery, nemůžou vám nikdy stačit. Tyto příleži­tosti není snadné najít. Je obtížné velkou firmu zatáhnou do desig­nové války, asi tak jako je obtížné vylákat obránce hradu ven do bitvy muže proti muži. Bylo by například úžasně snadné napsat lepší textový editor než Micro­soft Word. Ve svém hradu monopolu na operační systém by si toho dokonce nejspíš ani nevšimli.

Bitevní pole desig­nových válek jsou nové trhy, kde ještě nikdo nestačil zřídit opevnění. Zde můžete hodně získat odvážným přístupem k designu, máte-li navíc lidi, kteří dělají obojí, jak navrhují, tak imple­men­tují produkt. Micro­soft sám to na začátku učinil. Stejně tak Apple, rovněž Hewlett-Pac­kard. Mám podezření, že tak si tak počínal téměř každý úspěšný startup.

Startup

Jeden ze způsobů, jak napsat parádní software, je začít vlastní startup, ačkoliv to s sebou přináší dva problémy. Zaprvé ve startupu musíte dělat spoustu věcí vedle psaní software. Ve Viaweb považuji za štěstí když progra­muji čtvrtinu času. Věci, které musím dělat ve zbývajících třech čtvrtinách, jsou někde mezi nudný po úděsný. Mám na to srovnávací měřítko. Jednou jsem musel opustit poradu vedení kvůli zubnímu kazu. Pamatuji si, jak jsem seděl v zubařském křesle, čekal na vrtačku, a cítil se jako na dovolené.

Další problém se startupy je, že není velký přesah mezi druhem software, který vydělává peníze, a druhem, který je zajímavé psát. Psaní progra­mo­vacích jazyků je zajímavé, první produkt Micro­softu byl takový, ale dnes nikdo za progra­mo­vací jazyk platit nebude. Chcete-li vydělat peníze, obvykle bude třeba pracovat na problémech, které jsou příliš nesym­pa­tické, aby je řešili zadarmo.

Všichni tvůrci čelí tomuto problému. Ceny jsou určeny nabídkou a poptávkou a není tak velká poptávka po věcech, na kterých je radost praco­vat, jako po věcech, které řeší všední problémy indivi­duál­ních zákaz­níků. Hraní v divadle Off-B­rodway není placené tolik jako nošení gorilího převleku u něčího stánku na veletrhu. Psaní románů nevynáší tolik jako psaní inzerátu na kuchyňský drtič odpadu. A hackování progra­mo­vacích jazyků není placené tak, jako vyřešení, jak připojit zasta­ralou a shnilou firemní databázi na jejich webový server.

Denní práce

Myslím, že odpovědí na tento problém je, i v případě software, koncept známý téměř všem tvůrcům: denní práce. Toto označení začalo s muzikanty, kteří vystu­po­vali večer. Obecněji to znamená, že máte jednu práci pro peníze a druhá je vaší láskou.

Takřka všichni tvůrci mají v počátku kariéry denní práci. Malíři a spiso­va­telé jsou tím proslulí. Když máte štěstí, tak vaše denní práce bude úzce spjata s vaší skutečnou prací. Hudeb­níci často pracují v prodejně s nahráv­kami. Hackeři pracují na progra­mo­vacím jazyku nebo operačním systému, který jim podobně může sehnat denní práci. [1]

Nepřináším nic nového, mluvím-li od denní hackerské práci a psaní krásného softwaru bokem. O tom je vlastně open-source. Možná že je open-source ten správný model, protože je nezávisle stvrzen všemi ostat­ními hackery.

Překva­puje mě, že se zaměst­na­va­telé zdráhají dovolit hackerům pracovat na open-source projek­tech. Ve firmě Viaweb bychom se naopak zdráhali přijmout někoho, kdo tak nečinil. Při technickém pohovoru nás jako hlavní věc zajímá, jaký software napsali ve svém volném čase. Nemůžete dělat doopravdy nic pořádně, jestliže to nemilu­jete. A miluje­te-li hackování, nevyh­nu­telně budete pracovat na svých projek­tech. [2]

Postupné učení

Jelikož hackeři jsou spíš tvůrci než vědci, tak správná metafora není věda ale srovnání s ostat­ními typy tvůrců. Co dalšího nás může malování naučit o hackování?

Jedna věc, kterou se můžeme od malování přiučit, nebo alespoň potvr­dit, je, jak se naučit hacko­vat. Malovat se naučíte většinou tak, že budete malovat, stejně tak hacko­vat. Většina hackerů se nenaučila hackovat tak, že by chodila na vysokoškolské kurzy progra­mování. Naučili se hackovat díky psaní vlast­ních programů ve svých třinácti letech. Dokonce i na vysoké škole se naučíte hackovat především hackováním. [3]

Jelikož za sebou nechávají malíři stopu, můžete sledovat jak se praxí zdoko­na­lo­vali. Podíváte-li se na malířovo portfolio v chrono­lo­gické pořadí, uvidíte, že každá malba staví na věcech, které se naučil na předchozí malbě. Pokud v malbě něco funguje velmi dobře, obvykle nalez­nete verzi jedna v menším prove­dení na nějakém předchozím obraze.

Předpok­ládám, že tak pracuje většina tvůrců, zdá se, že i spiso­va­telé a archi­tekti. Možná by bylo pro hackery dobré, kdyby se chovali víc jako malíři a pravi­delně začínali od nuly, místo letitého pokrač­ování na jednom projektu a pokoušet se zahrnout všechny své pozdější nápady jako revize.

Skuteč­nost, že hackeři se učí hackovat tím, že hackují, je další známka toho, jak se liší od vědců. Vědci se neučí vědu tak, že by ji dělali, ale tím, že dělají laborky a vzorové úlohy. Vědci začínají dělat práci, která je dokonalá, v tom smyslu, že se pokoušejí zrepro­du­kovat práci, kterou už pro ně někdo udělal. Případně se dostanou do bodu, kdy můžou dělat původní práci. Zatímco hackeři dělají od samého počátku původní práci, což je prostě velmi špatně. Takže hackeři začínají původně, dostanou se k dobře, a vědci začínají s dobře a dostanou se k původně.

Kopírujte jako umělci

Dalším způso­bem, jak se tvůrci učí, je pomocí příkladů. Pro malíře je muzeum referenční knihovnou technik. Po staletí bylo kopírování velkých mistrů součástí tradič­ního vzdělání malířů, protože kopírování vás přinutí se dívat pozor­něji na to, jak byla malba provedená.

Stejně tak spiso­va­telé. Benjamin Franklin se naučil psát tak, že shrnoval myšlenky z esejů Addisona a Steeleho a pokoušel se je repro­du­ko­vat. Raymond Chandler dělal to samé s detektivkami.

Podobně se hackeři mohou naučit progra­movat díváním se na dobré programy; ne jen na to, co dělají, ale taky do zdrojového kódu. Jeden z nejméně propa­go­vaných přínosů open-source hnutí je to, že učení se progra­movat učinilo snazší. Když jsem se učil progra­movat, museli jsem se spoleh­nout většinou na příklady z knih. Jeden dostupný pořádný kus kódu byl Unix, ale dokonce ani ten nebyl open-source. Většina lidí, která četla kód, ho četla z nelegální kopie knihy, kterou napsal John Lion v roce 1977 a jejíž vydání bylo povolené teprve až v roce 1996.

Změna

Další příklad, který si můžeme vzít z malování je to, jak jsou obrazy tvořeny postupným vylepšováním. Malby obvykle začnou skicou. Postupně jsou doplňovány detaily. Ale není to pouze proces vyplňování. Občas se původní plány ukážou být chybné. Na nesčetně maleb, když se na ně podíváte rentge­nem, se ukážou konče­tiny, které byly přesu­nuty nebo upravené rysy obličeje.

To je poučení, které jsem si vzal z malíř­ství. Myslím, že hackování by mělo fungovat stejně. Je nereálné očekávat, že speci­fi­kace programu bude dokonalá. Budete na tom lépe, pokud si to přiznáte a budete psát programy, které umožní změnu v průběhu.

(Struk­tury velkých firem jim to dělají složitějším, takže další aspekt, v čem mají startupy výhodu.)

Každý teď nejspíš ví o nebez­pečí předč­asné optima­li­zace. Mám za to, že bychom se měli také bát předč­asného návrhu; rozhod­nout se příliš brzy, co by program měl dělat.

Správné nástroje vám pomůžou se tomuto nebez­pečí vyhnout. Dobrý progra­mo­vací jazyk, stejně jako olejová barva, by vám měl umožnit snadno změnit názor. Dynamické typování je zde výhrou, protože se nemusíte předem zavázat ke speci­fické datové repre­zen­taci. Ovšem klíčem ke flexi­bi­litě je, myslím, učinit jazyk velmi abstrakt­ním. Nejsnáze se mění krátký program.

Detail


Leonardo da Vinci, Ginevra de' Benci

Zní to jako paradox, ale skvělí malíři musí být lepší než je potřeba. Když například Leonardo maloval portrét Ginevra de Benci v Národní galerii, umístil ji za hlavu jalovec. Přičemž pečlivě vymalovat každý jednot­livý list. Mnoho malířů si přesto může myslet, že je to prostě jen něco, co přijde na pozadí, aby to zarámo­valo její hlavu. Nikdo se tak blízko nepodívá.

Nikoliv však Leonardo. Jak tvrdě pracoval na části malby vůbec nezáleželo na tom, jak očekával, jak moc z blízka se bude někdo dívat. Byl jako Michael Jordan. Vytrvalý.

Vytrva­lost vítězí, protože v souhrnu se stávají neviděné detaily viditel­nými. Když lidé prochází kolem portrétu Ginevra de Benci, jejich pozor­nost je jím často upoutána, aniž by se předtím podívali na štítek a všimli si, že je na něm napsáno Leonardo da Vinci. Všechny tyto zkombi­no­vané neviděné detaily vytvoří něco, co je prostě ohromující jako tisíc sotva slyši­tel­ných zpívajících hlasů, které ladí.

Podobně tak skvělý software vyžaduje fanatickou oddanost kráse. Podíváte-li se dovnitř dobrého softwaru, shledáte, že části, o kterých se nepřed­pok­ládá, že je někdo uvidí, jsou rovněž krásné. Netvr­dím, že píšu skvělý software, ale vím, že když přijde na psaní kódu, jsem zralý na prášky, kdybych tak přistu­poval i běžnému životu. Vytáčí mě, když vidím špatně odsazený kód nebo ošklivá jména proměnných.

Cykly

Pokud by hackeři byli pouze imple­men­tátoři přetvářející speci­fi­kaci do kódu, mohli by k tomu přistu­povat jako k hloubení výkopu. Ale jestliže jsou hackaři tvůrci, musíme vzít v potaz inspiraci.

V hackování jako v malíř­ství přichází práce v cyklech. Někdy vás nakopne nový projekt a chcete na něm pracovat šestnáct hodin denně. Jindy se zase nic nezdá zajímavé.

Abyste odváděli dobrou práci, musíte tyto cykly vzít na vědomí, protože ovlivňují to, jak na ně reagu­jete. Když řídíte auto s manuální převo­dovkou a jedete do kopce, musíte občas sešláp­nout spojku, aby vám nechcípl motor. Sešláp­nout spojku může podobně zabránit poklesu ambic. Jak v malíř­ství tak v hackování jsou některé úlohy děsivě ambiciozní a jiné zase uklidňujícím způsobem rutinní. Je dobrý nápad šetřit si nějaké snadné úlohy na chvíle, kdybyste se mohli zaseknout.

V hackování to doslova znamená vyšetřovat bugy. Mám rád debugování, při tom je hackování tak přímoč­aré, jak si lidé myslí, že je. Máte zcela omezený problém a musíte ho vyřešit. Váš program by měl dělat x, místo toho dělá y. Kde se to pokazilo? Víte, že nakonec vyhra­jete. Je to odpoč­in­kové jako malování zdí.

Spolupráce


Andrea del Verrochio, Kristův křest

Malíř­ství nás může naučit nejenom si organi­zovat svou vlastní práci, ale taky jak spolu­pra­co­vat. Mnoho ohrom­ného umění v minulosti vzniklo jako práce více rukou, přesto vedle něj v muzeu visí pouze jedno jméno. Leonardo byl učeň v dílně mistra jménem Andrea del Verrocchio a maloval tam anděly na obraze Kristův křest. Takový způsob práce byl pravid­lem, nikoliv výjim­kou. Miche­lan­gelo byl považován za obzvláště zaníceného, protože trval na tom, že bude malovat všechny postavy na stropě Sixtinská kaple sám.

Pokud vím, tak když pracují malíři společně, tak nikdy nepra­cují na stejné části. Bylo běžné, že mistr maloval hlavní figury a asistenti ostatní a pozadí. Ale nikdy nemaloval nikdo přes práci někoho jiného.

Myslím, že je to správný model spolu­práce i pro software. Když je kus kódu hackován třemi nebo čtyřmi různými lidmi, nikdo ho skutečně nevlastní a skončí to jako společ­enská místnost. Obvykle bezútěšné a opuštěné, kde se hromadí odložené věci. Myslím, že správný způsob spolu­práce je rozdělit projekt do ostře defino­vaných modulů, každý by měl určeného správce. Rozhraní mezi nimi je pečlivě navrženo a artiku­lováno (je-li to možné) jako progra­mo­vací jazyk.

Empatie

Stejně jako malíř­ství je software většinou určen lidem. Proto hackeři stejně jako malíři musí mít empatii, aby dokázali skvělou práci. Musíte být schopní vidět věci z uživa­tel­ského pohledu.

Jako dítěti mi vždy říkali, abych se díval na věci z pohledu někoho jiného. Což v praxi vždy zname­nalo dělat něco, co chtěl někdo jiný, místo toho, co jsem chtěl jí. To pocho­pi­telně dalo empatii špatné jméno a já si udělal poznámku, že empatii nemám rozvíjet.

Páni, jak já se mýlil. Ukázalo ze, že dívat se na věci z pohledu jiných lidí je prakticky tajem­ství úspěchu. Nezna­mená to nutně být obětavý. Zdaleka ne. Porozumění tomu, jak se někdo dívá na danou věc, nezna­mená, že budete jednat v jeho prospěch; v některých situacích (například ve válce) budete chtít udělat přesně opak. [4]

Většina tvůrců dělí věci pro lidi. Abyste zaujali publi­kum, musíte porozumět jejich potřebám. Například téměř všechny velké významné malby jsou malby lidí, protože lidé jsou to, co lidi zajímá.

Empatie je možná ten nejdůležitější rozdíl mezi dobrým a skvělým hacke­rem. Někteří hackeři jsou docela chytří, ale když dojde na empatii, jsou v podstatě solipsis­ti&l­t;/>. Pro takové lidí je obtížné navrh­nout skvělý software [5], protože se nedokáží na věc podívat cizíma očima.

Jak dobří jsou lidé v empatii poznáte, když je budete pozoro­vat, jak vysvět­lují technickou otázku někomu netech­nic­kému. Všichni nejspíš známe lidi, jinak chytré, kteří jsou v tomto komicky špatní. Pokud se jich někdo na večírku zeptá, co je to progra­mo­vací jazyk, řeknou něco jako: „Ehm, vyšší progra­mo­vací jazyk je to, co kompilátor používá jako vstup pro generování objek­tového kódu.“ Vyšší progra­mo­vací jazyk? Kompilátor? Objek­tový kód? Někdo, kdo neví, co je progra­mo­vací jazyk zjevně neví co zname­nají ani tyto termíny.

Součást toho, co musí dělat software, je vysvět­lovat sám sebe. Abyste napsali dobrý software, je potřeba, abyste porozuměli tomu, jak málo uživa­telé rozumí. Prokli­kají program bez příprav a bylo by lepší, aby dělal to, co hádali, že bude dělat, protože návod číst nebudou. Nejlepší systém, který jsem kdy viděl, že na to bral ohled, byl v roce 1985 originál Macin­tosh. Dělal, co software téměř nikdy nedělá: prostě fungo­val. [6]

Zdrojový kód by se také měl vysvětlit sám. Pokud by si lidé měli pamatovat jediný citát o progra­mování, měl by to být ten z úvodu knihy Struc­ture and Inter­pre­ta­tion of Computer Programs.

Programy by měly být psány tak, aby je lidé zvládli přečíst, nikoliv jen aby je stroje mimochodem vykonávaly.

Musíte mít empatii nejen pro vaše uživa­tele, ale i pro vaše čtenáře. Je to pro vaše dobro, protože budete jeden z nich. Mnoho hackerů napsalo program jen proto, aby po šesti měsících, kdy se k němu vrátili, neměli ani tušení, jak funguje. Znám několik lidí, kteří se po takové zkuše­nosti zřekli Perlu. [7]

Nedostatek empatie je spojován s inteli­gencí, někde je to dokonce něco jako móda. Ale já si nemys­lím, že je mezi nimi nějaká korelace. Můžete dělat dobře matema­tiku a přírodní vědy aniž byste se naučili empatii. Lidé v těchto oborech bývají chytří, takže tyto dvě kvality bývají spojovány. Ale je spoustu hloupých lidí, kteří jsou v empatii taky špatní. Jen schválně poslou­chejte otázky, které lidé volají do talk show. Ptají se takovou oklikou, že moderátor musí dotaz přefor­mu­lovat za ně.

Sláva


Piero della Francesca, Federico da Montefeltro

Jestliže funguje hackování jako malíř­ství a psaní, není to skvělé? Dosta­nete jen jeden život. Můžete ho strávit prací na něčem skvělém.

Bohužel na otázku je těžké odpovědět. Vždy je velké časové zpoždění co se prestiže týče. Je to jako světlo ze vzdálené hvězdy. Malíř­ství má teď významné posta­vení, protože lidé před pěti sty lety dělali skvělou práci. V té době si nikdo nemys­lel, že tyto malby budou tak důležité jako dnes. Tehdy by se zdálo velmi divné, že Federico da Montefeltro, urbinský vévoda, bude jednoho dne znám převážné jako chlápek s divným nosem díky obrazu, který namaloval Piero della Francesca.

Přestože přiznávám, že hackování teď není tak bezva jako malíř­ství, měli bychom pamatovat na to, že ani malíř­ství se nezdálo tak skvělé.

S částečnou jistotou můžeme prohlásit, že dnes je hackování na výsluní slávy. Ve většině oborů je skvělá práce udělána podstatně dřív. Obrazy namalo­vané mezi roky 1430 a 1500 jsou stále nepře­ko­vané. Shakes­peare, zdá se, se už jako profe­sionální divadelník narodil a posunul toto médium tak daleko, že každý autor divadel­ních her musí od té doby žít v jeho stínu. Albrecht Dürer učinil to samé s rytinou a Jane Austen s románem.

Znovu a znovu vídáme ty samé vzorce. Objeví se nové médium a lidé jsou z něj tak nadšení, že objevují většinou jeho možností během několika generací. Hackování, zdá se, je nyní v této fázi.

Malíř­ství nebylo v čase Leonarda tak skvělé, jako ho jeho práce pomohla udělat. Jak skvělé se nakonec ukáže být hackování, bude záležet na tom, co s tímto novým médiem dokážeme udělat.

Poznámky

[1] Největší škodu, kterou fotog­rafie udělala malíř­ství, může být skuteč­nost, že zničila jeho nejlepší denní práci. Většina velkých malířů v historii se živila malováním portrétů.

[2] Bylo mi řečeno, že Micro­soft odrazuje zaměst­nance od přispívání do open-source projektů, i kdyby v jejich volném čase. Ale tolik nejlepších hackerů pracuje na open-source projek­tech, že hlavní dopad této politiky může být postarat se, že nebudou schopní najmout žádného prvotříd­ního programátora.

[3] Co se naučíte o progra­mování na vysoké škole je jako co se naučíte o knihách, oblečení nebo randění. Měli jste na střední špatný vkus?

[4] Taky je příklad apliko­vané empatie. Ve firmě Viaweb jsme se nemohli rozhodnou mezi dvěma alter­na­ti­vami. Zeptali jsem se, co by naši konku­renti nenáviděli nejvíce? V jednom okamžiku přidal konku­rent funkč­nost do svého software. Byla to vlastně zbyteč­nost, ale bylo to něco, co jsme my neměli, takže to tlačili do novin. Mohli jsme se pokusit vysvět­lit, že je to zbyteč­nost, ale místo toho jsme se rozhodli, že by našeho konku­renta naštvalo, kdyby­chom funkč­nost imple­men­to­vali sami. Takže jsme danou funkč­nost ještě to samé odpoledne nahac­ko­vali po svém.

[5] Kromě textových editorů a kompilátorů. Na jejich navrhování hackeři nepotře­bují empatii, protože jsou sami typic­kými uživateli.

[6] Tedy téměř. Nějak minuli dostupnou RAM, což způso­bo­valo nevhodné swapování disku, ale to mohlo být opraveno během několika měsíců tak, že jste si koupili další disk.

[7] Programy neuděláte čitel­nější tím, že je vycpete komen­táři. Ještě bych citát posunul o krok vpřed. Progra­mo­vací jazyky by měly být navrhovány k vyjádření algoritmů, nikoliv jen aby říkali počítačům, jak je mají vykonávat. Dobrý progra­mo­vací jazyk by měl být lepší pro vysvět­lení software než anglič­tina. Měli byste potře­bovat komentář jen v případě, že potře­bu­jete varovat čtenáře ohledně nějakého rychlého a špinavého řešení. Jako jsou na silnici značky jen u nečekaně ostrých zatáček.

Poděkování patří: Trevor Blackwell, Robert Morris, Dan Giffin, a Lisa Randall za přečtení konceptu a Henry Leitner a Larry Finkelstein za pozvání přednášet.