Poznaš tisto staro modrost o ribah? Če človeku daš ribo, bo sit en dan. Če ga naučiš loviti ribe, bo imel kaj jesti tudi jutri.
No, sam bi temu dodal še nekaj: če mu pokažeš, kako si se naučil loviti ribe, vključno s tem, kolikokrat si vrgel trnek v grmovje, koliko vab si izgubil in kako dolgo si čakal ob praznem vedru, bo morda iz vsega skupaj odnesel še kaj več.
In čeprav se sliši nekoliko nenavadno, mislim, da ta filozofija precej dobro velja tudi za tehnologijo, ustvarjanje in življenje nasploh.
Ribe, trnki in nekaj nepričakovanih lekcij
Da ne bo pomote, ribe v mojem primeru niso samo priročna prispodoba.
Na morju namreč zelo rad lovim ribe. Najraje brancine, orade in špareke, čeprav, roko na srce, nisem pretirano izbirčen. Kar se prime na trnek, je dobrodošlo. No, skoraj vse.
Ribolov ima zame poseben čar. Malo miru, morje, pričakovanje in tisti trenutek, ko začutiš, da se je na drugi strani vrvice nekaj premaknilo. Potem sledi ugibanje, kaj si pravzaprav ujel, in tiho upanje, da bo tokrat nekaj, kar bo vredno vsaj fotografije.
Seveda pa tudi tukaj ni vse tako romantično, kot je videti na fotografijah zadovoljnih ribičev z velikimi brancini.
Recimo morski pauk.
Ta je poskrbel, da sem bil zaradi bližnjega srečanja z njim deležen že dveh injekcij. Ena v prst ena v tazadnjo :). Očitno nekatere ribe svoje nezadovoljstvo z ulovom izrazijo nekoliko bolj odločno kot druge.
Tako sem poleg običajnih ribiških lekcij dobil še eno: ni vsaka riba, ki se prime na trnek, razlog za veselje. In še zdaleč ni vsake pametno prijeti na enak način.
Če bi pokazal samo fotografijo lepe orade, bi bila zgodba precej bolj elegantna. Ampak bistveno manj zanimiva.
In prav to je bistvo tega zapisa.
Svet popolnih rezultatov
Živimo v času, ko je na spletu mogoče najti praktično vse. Od programov, ki jih je nekdo razvil v enem vikendu, do popolno obnovljenih avtomobilov, čudovitih lesenih bark, vrhunskih računalniških konfiguracij in neverjetnih projektov, ki naj bi nastali skoraj mimogrede.
Vse je lepo, čisto, urejeno in praviloma tudi izvrstno osvetljeno.
Potem se podobnega projekta lotiš sam.
In ugotoviš, da je med fotografijo končnega izdelka in resničnostjo kar nekaj prostora. Običajno ga zapolnjujejo razmetana delavnica, kup odprtih zavihkov v brskalniku, nekaj napačnih nakupov in vsaj en trenutek, ko se resno vprašaš, zakaj nisi raje šel na kolo.
Pri programiranju ni dosti drugače. Nekdo pokaže aplikacijo, ki lepo deluje. Klikne gumb, vse se odzove, podatki se izpišejo, grafi so čudoviti.
Nikjer pa ni videti tistih petnajstih različic, ki so končale v košu. Ali funkcije, za katero si porabil tri dni, preden si ugotovil, da je pravzaprav nihče ne potrebuje.
Da ne omenjam trenutka, ko popraviš eno napako, ob tem pa povsem nehote ustvariš tri nove.
Pravzaprav bi lahko rekli, da je razvoj programske opreme včasih zelo podoben obnovi stare hiše. Odpreš eno steno in odkriješ, da imaš zdaj še tri dodatne projekte.
Ko je največji napredek odstranitev nečesa
Dober primer je moje eksperimentiranje z lokalno umetno inteligenco.
Na papirju je zadeva precej preprosta. Imaš zmogljiv računalnik, dve grafični kartici, namestiš operacijski sistem, ustrezne gonilnike, nekaj programske opreme in že lahko poganjaš svoj jezikovni model.
Kaj bi lahko šlo narobe?
Marsikaj, kot se izkaže.
Pri postavljanju Linux okolja sem se med drugim srečal s precej zanimivim prepletanjem grafičnih gonilnikov, knjižnic in različnih programskih komponent. Nekaj je delovalo, nekaj skoraj delovalo, nekaj pa je delovalo samo toliko, da je ustvarilo lažen občutek, da sem tik pred ciljem.
Tista zadnja kategorija je običajno najbolj nevarna za prosti čas.
In potem pride trenutek, ko ugotoviš, da rešitev ni namestitev še enega dodatnega paketa, temveč odstranitev nečesa, kar si pred tem z velikim trudom namestil.
Tri korake naprej, dva nazaj. Občasno še ponovni zagon, za vsak primer.
Če bi pokazal samo končno delujoče okolje, bi bila zgodba kratka: Ubuntu, AMD, ROCm, lokalni model – deluje.
Toda prava vrednost te izkušnje ni zgolj v tem, da model na koncu deluje. Je v razumevanju, zakaj določene komponente sodelujejo, druge pa si stojijo na poti. In zakaj včasih manj nameščene programske opreme pomeni boljši sistem.
Ta izkušnja mi bo koristila tudi naslednjič. In morda še komu, ki bo naletel na podobno težavo.
Tudi pri lesu ni bližnjic
Podobno je pri povsem drugačnem projektu – obnovi stare lesene barke.
Tam ni programskih knjižnic, gonilnikov ali sporočil o napakah. Imaš pa les, star premaz, epoksi, brusilnik in precej neposreden stik z resničnostjo.
Na fotografiji je obnovljena barka videti čudovito. Gladek trup, lepa barva, vse se sveti. Kot nova.
Toda fotografija ne pove, koliko dela je bilo potrebnega, še preden si sploh lahko razmišljal o prvem resnem nanosu nove zaščite.
Stara podlaga lahko skriva marsikaj. Recimo epoksi, ki je na videz še sprejemljiv, ob natančnejšem pregledu pa ugotoviš, da njegov odnos z lesom ni več ravno najbolj trden.
In tukaj pride tisti neprijetni del.
Rad bi že nanašal novo zaščito, občudoval napredek in razmišljal o končnem rezultatu. Namesto tega pa odstranjuješ star material, brusiš, preverjaš stanje lesa in ugotavljaš, kaj vse je treba narediti, preden sploh prideš do prijetnejšega dela.
Včasih po celem dnevu dela izdelek na pogled ni nič lepši. Lahko je celo precej grši.
Pa si vseeno naredil pomemben korak naprej.
To je ena tistih lekcij, ki jih je mogoče prenesti skoraj kamorkoli: napredek ni vedno tisto, kar je videti kot napredek.
Včasih je najboljša odločitev odstraniti nekaj, kar ni dobro. Drugič zavreči zamisel, v katero si že vložil veliko časa. Tretjič pa preprosto priznati, da si se nečesa lotil v napačnem vrstnem redu.
In začeti znova.
Napake niso sramota. So uporabne informacije.
Ne mislim, da bi morali na spletu objavljati prav vsak spodrsljaj. Nihče ne potrebuje podrobnega zapisa o tem, kako sem deset minut iskal orodje, ki sem ga pred tem odložil na popolnoma logično mesto. Ki se ga seveda ne spomnim več.
Čeprav bi iz takšnih prigod verjetno nastal kar dolg blog.
Drugače pa je, kadar napaka razkrije nekaj pomembnega.
Recimo da pri razvoju aplikacije ugotoviš, da si prvotno arhitekturo zastavil napačno. Lahko jo še nekaj tednov krpaš in poskušaš rešiti prvotno idejo. Lahko pa si priznaš, da bi bilo bolje del sistema zasnovati drugače.
Priznati napako ni vedno prijetno. Še posebej, če si zanjo porabil veliko časa.
Toda čas, ki si ga že vložil, ni dober razlog, da bi ga vložil še več.
Enako velja zunaj računalniškega sveta. Če si se pri obnovi česa lotil napačno, nadaljevanje po isti poti običajno ne bo čudežno izboljšalo rezultata.
Zato so mi zapisi, v katerih nekdo odkrito pove, kaj ni delovalo in zakaj, pogosto zanimivejši od klasičnih predstavitev uspeha.
Ne zato, ker bi užival v tujih težavah. Ampak zato, ker mi omogočajo, da se nekaj naučim, ne da bi moral prav vsako napako ponoviti tudi sam.
Čeprav, roko na srce, jih nekaj skoraj zagotovo bom.
Med »deluje« in »preverjeno deluje« je velika razlika
Pri tehnologiji opažam še eno zanimivo navado.
Ko nekaj prvič uspešno zaženemo, hitro dobimo občutek, da smo delo opravili.
Program se odpre. Model odgovori na vprašanje. Avtomatizacija izvede nalogo. Vse lepo in prav.
Toda en uspešen poskus še ne pomeni, da je sistem zanesljiv.
Kaj se zgodi pri petdesetem zaporednem izvajanju? Kaj, če zmanjka pomnilnika? Kaj se zgodi, ko nekdo vnese nepričakovan podatek? Ali ko se po posodobitvi spremeni nekaj, na kar prej sploh nisi pomislil?
V tem delu razvoja se običajno skriva precej več dela, kot bi človek sklepal iz lepe demonstracije.
Zato skušam pri svojih projektih razlikovati med štirimi precej različnimi stvarmi:
- Ideja: nekaj, kar bi bilo zanimivo narediti.
- Eksperiment: preverjanje, ali je zamisel sploh izvedljiva.
- Prototip: nekaj, kar že deluje, vendar še nima vseh potrebnih lastnosti.
- Preverjen rezultat: nekaj, za kar lahko na podlagi ustreznih preizkusov precej bolj utemeljeno trdim, da deluje v določenih pogojih.
Tudi zadnja stopnja seveda ne pomeni popolnosti. Pomeni le, da za trditev obstajajo konkretni dokazi in da poznamo vsaj del omejitev.
To razlikovanje se mi zdi pomembno. Še posebej danes, ko je s pomočjo umetne inteligence mogoče razmeroma hitro sestaviti nekaj, kar na prvi pogled deluje zelo prepričljivo.
Med lepim posnetkom zaslona in zanesljivim sistemom je lahko še ogromno dela.
Ni treba, da vse počnemo sami
Tukaj se lahko vrnem k tistim ribam z začetka.
Če nekdo že zna loviti ribe, mu ni treba vsakič znova izdelovati ribiške palice.
Enako velja za tehnologijo.
Nimam nič proti uporabi pripravljenih rešitev. Nasprotno. Če obstaja dobro orodje, ki opravi svoje delo, ga z veseljem uporabim. Nima smisla izumljati kolesa vsakič, ko bi se rad nekam odpeljal.
Me pa zanima, kako je to kolo sestavljeno, zakaj je nekdo izbral prav takšne materiale in kaj bi se zgodilo, če bi kaj spremenil.
Ne zato, ker bi moral prav vse narediti sam. Temveč zato, ker mi razumevanje daje možnost izbire.
Ko razumeš vsaj osnovna načela, nisi več povsem odvisen od navodil, ki jih je nekdo pripravil za idealne pogoje.
Lahko presodiš, ali so primerna tudi zate.
In ko stvari ne gredo po načrtu, imaš vsaj približno predstavo, kje začeti iskati težavo.
Ali, če ostanemo pri ribolovu, vsaj veš, kdaj je pametneje najprej pogledati, kaj se je prijelo na trnek, preden sežeš po ulovu.
Zakaj torej vse to zapisujem?
Ne zato, ker bi imel za vsako težavo najboljšo rešitev.
Prav tako nimam ambicije, da bi ta blog postal zbirka popolnih receptov za vse mogoče življenjske situacije.
Bolj mi je blizu zamisel nekakšnega odprtega dnevnika ustvarjanja.
Prostor, kjer lahko predstavim zamisel, opišem pot do nje, pokažem nekaj uspešnih odločitev in tudi kakšno takšno, ki je bila v danem trenutku videti pametna, pozneje pa malo manj.
Včasih bo to računalnik z dvema grafičnima karticama. Drugič program, ki ga razvijam, ali stara barka, ki ji poskušam vrniti nekaj nekdanjega sijaja. Morda kolesarski izlet, kakšna ribiška prigoda, domač projekt ali povsem običajno razmišljanje o nečem, kar se mi je zgodilo.
Pri vseh teh stvareh mi je skupna radovednost.
Rad razumem, zakaj nekaj deluje. Še bolj me zanima, zakaj ne deluje. Čeprav bi bilo včasih za moje živce precej bolje, če bi preprosto delovalo že prvič.
Seveda obstajajo tudi meje. O svojih projektih in izkušnjah lahko pišem odkrito. To pa ne pomeni, da bom razkrival tuje zaupne informacije, zasebnost drugih ali stvari, ki niso moje za deliti.
Odprtost in odgovornost se ne izključujeta.
Na koncu je pomembna tudi pot
Ko danes pogledam nazaj na kakšen svoj projekt, mi pogosto v spominu ne ostane samo končni izdelek.
Spomnim se trenutka, ko sem končno razumel težavo, ki me je prej dneve spravljala ob živce. Ali odločitve, da bom nekaj naredil povsem drugače, kot sem sprva načrtoval.
In, priznam, tudi tistega posebnega zadovoljstva, ko po dolgem iskanju ugotoviš, da je bila rešitev ves čas skoraj pred nosom.
Takrat se običajno ne odločiš, ali bi se smejal ali jezil.
Pa se raje smejiš.
Zato bi rad, da je na tem blogu poleg končnih rezultatov videti tudi nekaj poti do njih.
Ne bom trdil, da vedno izberem najkrajšo. Glede na nekatere svoje projekte bi bilo to precej težko zagovarjati.
Upam pa, da je vsaj zanimiva.
In če bo kdo ob kakšnem zapisu dobil novo idejo, se izognil napaki, ki sem jo že naredil jaz, ali pa preprosto dobil pogum, da se nečesa loti sam, potem je moj namen dosežen.
Ker na koncu ni najpomembnejše, da pokažeš, kaj si naredil. Včasih je veliko dragoceneje pokazati, kako si do tega prišel.
In če se je treba na poti tudi kdaj pošteno nasmejati na svoj račun, toliko bolje.
Samo pri morskem pauku bi naslednjič vseeno raje preskočil praktični del izobraževanja.