I morges fikk jeg over meg at jeg ville skrive om hvorfor jeg ikke liker rammeverk som gjør for mye. Jeg begynte å skrive. Så innså jeg at jeg ikke ville bli ferdig på kort tid, dette er et stort tema. Så jeg kastet teksten.

For noen minutter siden fant et problem med et shell-script jeg bruker for å navigere mellom prosjekter. Jeg tok en titt på problemet, og innså at jeg ikke hadde noen gode løsninger. Så jeg kastet koden.

Jeg mener det er superviktig at vi som utvikler programvare lærer oss nye ting. Ellers blir vi sittende fast med det vi kan. Vi kan sikre at vi lærer ting ved å ta læringen seriøst. Patrick Dubroy beskriver i Taking Learning Seriously hvordan han aktivt skriver "Today I Learned" for å holde læringsfarten oppe, og hvilke andre ting han også gjør.

Men balansen mellom "lære ting jeg er nysgjerrig på" og "kode opp ting jeg vet må på plass" kan være vanskelig. Jeg synes i alle fall det har vært vanskelig. Jeg kunne bruke veldig mye tid på noe spennende og få dårlig samvittighet etterpå, eller bruke null tid på nye ting, og bli irritert og sur.

Nå om dagen synes jeg balansen er lettere. Jeg må bruke litt tid på å lære meg ting jeg er nysgjerrig på, og også tiden som kreves til å gjøre jobben min. Balansen mellom de to holder jeg med tidsbudsjetter. Jeg setter av litt tid til å prøve en ting jeg er nysgjerrig på. Når tiden er ute, shipper jeg hvis det er godt nok, eller kaster resultatet hvis det ikke er godt nok.

Men å "kaste resultatet hvis det ikke er OK" må vel være dumt? Er ikke det bortkastet arbeid? Nei, det mener jeg det absolutt ikke er. Jeg har lært noe. Og hvis jeg alltid kaster det jeg har gjort, og aldri shipper, er det et tegn på at jeg prøver å bite over for mye på én gang. Læring er mest effektivt når du klarer å dele opp læringen i små, veldefinerte steg.

Som utvikler kan du øke læringsfarten din enormt. Bør du prøve? Det finner du aldri ut hvis du ikke prøver :)

—Teodor