Robert C. Martin hadde æren av å holde Keynote-talen på NDC i år. Der snakket han om hvilke prinsipper man bør følge for å kunne kalle seg en profesjonell utvikler. De som har fulgt med på denne bloggen vet at jeg lytter mye til denne mannen, og jeg er enig i det meste han sier.

Flere av prinsippene han presenterte gikk på hvordan vi utviklere bør forplikte oss til å bli bedre. Her er et utvalg:

Kjenn ditt fagfelt – Vi utviklere må kunne utviklingsfaget. Vi må strekke dette til områder utenfor akkurat det vi holder på med og har erfaring med. Vi må lære vår historie, ulike utviklingsmetodikker og prinsipper som har vært brukt opp igjennom vår forholdsvis korte historie – hvorfor de virket, og hvorfor de har blitt endret eller erstattet.

Kjenn ditt domene – Vi utviklere må sørge for å bli eksperter innenfor det forretningsområdet vi jobber i. Skal vi kunne produsere gode løsninger kommer vi ikke utenom at vi må kunne forretningen og forstå brukerne. Dette har jeg vært inne på i blogposten Utviklerprofiler og fire ferdighetskategorier.

Kontinuerlig læring – Vi må sørge for å hele tiden utvikle oss. Programmering er et stort fagfelt, og en utdanning pluss noen års erfaring er bare et lite steg på veien til å bli en mester. Faget er også i kontinuerlig utvikling, og mens mye bygger på kunnskap som allerede er etablert, er vi nødt til å henge med for å kunne utvikle gode løsninger i morgen.

Øv mye – For å bli en god fotballspiller må man øve. For å bli en god musiker må man øve. Det nytter ikke å bare spille kamper eller konserter. Å basere seg på å bare gjøre produksjonskode holder heller ikke. Man må øve på nye tegnikker, og man må repetere gamle for å holde dem ved like. Man må trimme hjernen, og få ting til å sitte i fingrene. Kun da kan man gjøre den beste jobben når det virkelig gjelder.

Og så slipper Uncle Bob den store bomben:

“En profesjonell utvikler bruker 20 timer av sin fritid hver uke på å utvikle seg selv og bli bedre.”

Rundt meg merket jeg at folk reagerte. 20 timer? Av fritiden vår? Nei nå må han roe seg ned.

Jeg har selv brukt omtrent så mye tid av egen fritid på å bli en bedre programmerer det siste halve året (se å bli en .net ninja), men det er faktisk ganske mye, og man må ofre endel for å få det til. Jeg er på god vei til å bli en mye bedre utvikler enn jeg var, og ideelt sett er jeg enig at det hadde vært fint om alle gjorde som jeg har gjort, men det er nok ikke realistisk å få det til (med den innstillingen vi har til jobb i norge i dag).

Omtrent slik ser uken min ut..

Jeg er enig med Uncle Bob i to ting: For det første må utviklere generelt jobbe mye mer med å bli bedre enn tilfellet er i dag. Og for det andre er jeg enig i at det er utviklernes eget ansvar å sørge for at de utvikler seg. Men våre arbeidsgivere må legge til rette for at utviklingen kan finne sted.

Vår industri må endre sin holdning til hva som er “godt nok”. Vi må innse at vellykket softwareutvikling er mye mer komplisert enn å sette en gjeng halv-erfarne utviklere til å produsere kode. Vi må skape et miljø hvor utvikling av de ansatte er en helt naturlig del av forretningen.

Man må sette av tid til å eksperimentere, og til å øve på grunnleggende ferdigheter. Systemutvikling har mye mer til felles med lege- og advokatyrket, yrker med ekstremt høy kompleksitet og endring, enn til mer forutsigbare yrker som f.eks. bygningsarkitekt eller tradisjonelle ingeniøryrker (flame on..).

Ja, en programmerer må være interessert i å kontinuerlig utvikle seg og sine ferdigheter, og en dyktig programmerer bruker også noe av sin fritid på dette. Men vi må skape større rom og forståelse for at dette skal skje også innenfor arbeidstiden. Ikke bare det å holde seg oppdatert, men å kontinuerlig bli bedre, bør være endel av stillingsinstruksen til enhver utvikler.

Knagger: Uncle Bob

En person som ønsker å bli en virkelig god programmerer må lære seg mye forskjellig. Jeg deler alle de ulike ferdighetene en må ha inn i fire kategorier. I denne artikkelen beskriver jeg disse kategoriene, og snakker litt om hvordan man kan bruke denne grupperingen til å diskutere ulike utviklerprofiler, og hvordan man bør fokusere sin egen utvikling.

Klikk på bildet for full størrelse

Kategori 1: Problemløsning

Tankekartet over forsøker å vise hvordan jeg tenker når jeg grupperer de ulike ferdighetene gode programmerere må ha. Den første kategorien er det man kan kalle generell programmeringskunnskap. Dette er blant annet det man fokuserer på under informatikk-utdannelsen på Universitetet (som er den utdanningen jeg kjenner til). Man må lære seg å bli en dyktig problemløser, lære teknikker man kan bruke mer eller mindre uavhengig av hvilken teknologi man benytter. Man må kunne bryte ned problemer, modellere, se mønstre, og sette kompleksitet i system.

Dette har mye med intelligens å gjøre, men ikke bare intelligens slik man tenker på det i tradisjonell sammenheng. Kreativitet og evnen til å “tenke utenfor boksen” er ting man kan trene opp. Gjennom å kultivere en evig nysgjerrighet på hvordan ting fungerer vil man etterhvert bli flinkere å flinkere til å se løsninger på problemene man møter som utvikler.

Kategori 2: Teknologi

Den neste kategorien omfatter alt man må lære seg for å beherske de spesielle teknologiene man behøver for å programmere. Dette er det mindre fokus på i Univeristetsutdannelsen – sansynligvis noe mer på høyskolene. En som ønsker å være en dyktig programmerer på f.eks. Microsoft .net plattformen har et hav av ting han må lære seg.

Kategori 3: Forretningsforståelse

For å bli en komplett utvikler må man også erværve seg forståelse for forretningsdomenet man jobber i. Det holder normalt ikke at noen andre utarbeider spesifikasjonen, og du som programmerer bare koder. En dyktig utvikler har forståelse for problemet som skal løses, og kan ta avgjørelser til beste for bedriften og sluttbrukerne.

Dessverre er dette et område mange utviklere er lite opptatt av. På den annen side finnes det mange utviklere som først og fremst har god domenekunnskap, og heller liten generell programmeringsbakrunn. De kan gjøre det like bra som utviklere innenfor sitt domene, fordi de kan levere det forretningen virkelig trenger.

Forretningsforståelse kommer først og fremst gjennom erfaring. Ved å jobbe lenge i et bestemt domene får man bedre forståelse for problemene og de potensielle løsningene som finnes. Og gjennom å erfare mange, ulike forretningsområder – slik som konsulenter som hyppig bytter oppdragsgiver får oppleve – kan man dra erfaring basert på likheter og ulikheter i de forskjellige områdene, og dermed få en bedre og bredere forståelse.

Kategori 4: Praktisk utvikling

Den siste kategorien omfatter en rekke andre ferdigheter som er viktig for at du som utvikler skal kunne bidra til å levere programvare av høy kvalitet. Software utvikles best gjennom sammarbeid i et team, og en utvikler må derfor kunne kommunisere med sine team-kamerater, og forstå betydningen av de ulike rollene som inngår der. For at det skal gå bra må utvikleren ha noen bestemte sosiale ferdigheter. Disse blir som regel sett på som utviklerens personlighetstype – noe man har fått med seg under oppveksten eller gjennom arv – og alt for lite blir desverre gjort for å trene på disse ferdighetene.

Man må også lære seg hvilke prosesser og metoder som fungerere til ulike ting. Det kan være formelle software engineering metoder, eller mindre formelle teknikker, slike som praktiseres i smidig utvikling. Teknikker som testdrevent design begrenser f.eks. behovet for modellering og kommunikasjon av spesifikasjoner i teamet, og er gunstig i mange prosjekter.

Det finnes mange kurs og mye litteratur, men det er egentlig kun erfaring som teller på dette området. Man lærer gjennom å sammarbeide, aller helst med dem som allerede har mer erfaring enn deg selv.

Utviklerprofiler

Alle de fire kategoriene jeg har beskrevet er viktige for å skape en komplett utvikler. Men som sakt får de forskjellige ferdighetene ulikt fokus hos programmerere. Jeg har eksperimentert med å sette opp ulike profiler, noe man kan gjøre blant annet for å bli klar over hva man bør bli bedre på.

I bildet over har jeg skissert en helt fersk juniorutvikler og en mer erfaren konsulent. Junioren har gått på Universitetet og lært mye om problemløsning, generelle algoritmer og datastrukturer osv., og skårer derfor relativt bra på den første søylen. Han har derimot begrenset erfaring med konkrete teknologi, noe han raskt må rette på når han blir kastet ut i arbeidslivet. Normalt har han også lite eller ingen forretningsforståelse, men han har tatt kurs i modellering, og en iterativ og inkrementell utviklingsprosess, så han har i alle fall litt balast på det området.

Seniorkonsulenten har vært på mange oppdrag, og har måttet lære seg en rekke teknologier nokså grundig, og gjennom flere år har han også blitt en dyktig problemløser. Oppdragene har gitt ham grunnleggende og bred forretningsforståelse, og gjennom å ha måttet sammarbeide med en rekke mennesker har han blitt en pragmatisk utvikler som vet en god del om hva som må til for å få et team til å fungere, slik at man kan levere det man skal til riktig tid og med riktig kvalitet.

Når man ser på dette og tenker seg om, er det ganske skremmende hvordan man tar inn ferske utviklere fra skolebenken og setter dem til å produsere fra dag en – ofte uten særlig gjennomgang av koden de leverer. Utviklere som mangler ferdigheter innen teknologi vil bruke unødvendig lang tid og levere lav kvalitet. Utviklere som mangler forretningsforståelse vil ikke kunne levere det brukerne trenger. Utviklere som mangler praktiske ferdigheter vil redusere hele teamets evne til å levere om de ikke får riktig oppfølging. Likevel hører mentor-programmer og intern skolering til sjeldenhetene i norske bedrifter. Det er viktig at arbeidsgivere forstår, og også at mer erfarne utviklere husker, at en nyutdannet informatiker eller IT-ingeniør ikke er en ferdigutdannet utvikler. Det krever også praktisk erfaring.

I de siste to grafene har jeg satt opp to profiler som jeg mener er idealer blant dagens utviklere. Den førset viser en erfaren utvikler som gjerne liker å kalle seg en software-ingeniør. Han har stort fokus på den teknologiske plattformen, og noe mindre på generelle problemløsningsteknikker. Han baserer seg på formelle utviklingsmetoder, hvor han bl.a. forventer at kravene fra forretningssiden i stor grad spesifiseres av andre, mens han leverer det de har bedt om på best mulig måte.

Som en kontrast til dette har du den smidige utvikleren, han som gjerne kaller seg selv en Software Craftsman. En slik utvikler tar i større grad en aktiv rolle i utformingen av løsningene, og ønsker et mye tettere sammarbeid med både andre utviklere og forretningssiden. Han er gjerne mer opptatt av velkonstruerte løsninger på problemer enn å utnytte mulighetene i og binde seg til en bestemt teknologi. Og han er opptatt av teknikker som han mener øker kvaliteten på leveransen, selv om de står i sterk kontrast til den formelle og aksepterte teorien.

Konklusjon

Tenk gjennom hvordan din egen utviklerprofil ser ut. I hvilken kategori er du sterk? Hvor har du mer å hente? Vil du bli bedre på generell problemløsning kan du for eksempel lese om domenedrevet design og trene på å løse ulike problemer (kanskje gjennom kode-kata). Vil du bli bedre på teknologi er det mange måter å gjøre det på, men vurder gjerne å lære deg en teknologi (f.eks. et nytt programmeringsspråk) du ikke har prøvd før – det vil øke din generelle forståelse. Mangler du forretningsforståelse bør du oppsøke dem som har det, og be dem om å opplyse deg, slik at du kan levere et bedre produkt til dem. Og mangler du kunnskap om praktisk gjennomføring bør du oppsøke andre utviklere, slik at dere kan dele erfaringer og vokse sammen. Kanskje du kan spørre noen med mer erfaring om de vil være din mentor for en periode?

De ulike kategoriene trekker til en viss grad i ulike retninger, men jeg tror det er kritisk at vi forsøker å balansere dem, og passer på å jobbe med å bli bedre innenfor alle fire. Det er kun da vi kan levere løsninger på de riktige problemene på en riktig måte, med best mulig teknologi, til riktig tid, og med nødvendig kvalitet – på en måte som vi kan leve med over tid.

Tre måneder etter at jeg startet .net ninja initiativet – min plan for å jobbe målrettet og strukturert med å bli en bedre programmerer – er det på tide å ta en titt på backloggen jeg lagde meg for første kvartal, og vurdere hvordan det har gått.

Hva gikk bra?

Det er utrolig mye som har gått bra. Jeg har rett og slett gått gjennom en forvandling de siste månedene, lært utrolig mye, eksperimentert med mye rart, og klart å holde motivasjonen oppe hele tiden. Et tydelig eksempel på dette er denne bloggen, som har gjennomgått en aldri så liten forvandling. Jeg har også klart å skrive et nytt tips til utviklerne i Contiki hver uke (det føles som om jeg har holdt på med det mye lengre enn 12 uker).

Det er faktisk ikke så mange ting fra backloggen jeg har fått gjort – mer om det under neste heading. Men jeg har fått gjort mye annet. Jeg har oppdaget objektdatabasene, og holdt et foredrag om dette på NNUG i februar (referat del 1 og del 2). Jeg har også tatt objektdatabaser i bruk i flere prosjekter, som f.eks. ContikiException, et verktøy jeg laget til bruk på jobben.

Jeg har også kommet mye bedre inn i .NET communityet. Jeg har blitt med i NNUG styret i Bergen, og vi har hatt tre flotte møter til nå i år. MsdnLive var også et bra arrangement, for ikke å snakke om GeekBeer samlingen vi hadde kvelden før.

Andre ting jeg har lyst til å nevne er at jeg har trent litt på ting som dependency injection, labda-utrykk i C#, LINQ og TDD. Det siste gjorde jeg bl.a. gjennom å gjøre en code kata. Jeg fikk oss også til å starte med parprogrammering i Contiki. Jeg har lest Code Complete og Kent Becks bok om TDD, og har startet på et par spennende bøker til. Og jeg har begynt å se på ASP.NET MVC.

Hva gikk ikke så bra?

Som du skjønner føler jeg at de tre første månedene vært en stor suksess. Det jeg er minst fornøyd med er hvor lite jeg har fått gjort på Contiki Center applikasjonen, noe jeg lager delvis for/på jobben og delvis privat/for egen vinning. Jeg nådde minstekravet om en første release før 1. april, men det var langt i fra hva jeg håpet på. Jeg klarte f.eks. ikke å sette meg nok inn i MVVM mønsteret for WPF applikasjoner.

Generelt sett fulgte jeg for dårlig opp de ulike prosjektene jeg startet underveis i perioden. Jeg burde ha fullført Vil Du Bli en .Net Ninja-spillet, og jeg burde klart å bruke mer tid på The Forecast Exchange.

Jeg hadde også en plan om å følge bedre med på noen utvalgte RSS feeds, men det gikk ikke som planlagt.

Hva kan jeg gjøre bedre?

Det jeg vil gjøre anderledes i de kommende tre månedene er å fokusere mer på to bestemte ting. For det første vil jeg lese mer. Jeg har flere bøker liggende, og venter på et par til fra Amazon. Og for det andre vil jeg kode mer. Dette vil gå på bekostning av en del tid jeg normalt bruker på å holde meg oppdatert på hva som skjer i miljøet (via Twitter, RSS feeds etc.), noe som er helt greit. Jeg ofrer gjerne litt bredde for å øke kvaliteten på det jeg gjør.

Knagger: Objektdatabase, NNUG, MsdnLive, GeekBeer, The Forecast Exchange, TDD, CodeKata, Podcast, Parprogrammering, Bøker, DDD

The Inquisitive Coder, Davy Brion, er lei seg og frustrert over tingenes tilstand i software-bransjen. Hvorfor lærer vi aldri, spør han. Hans blogpost reflekterer også min oppfatning for tiden, som er noe av grunnen til at jeg fokuserer så sterkt på personlig utvikling. Spesielt likte jeg følgende uttalelse:

A lot of people not only accept the fact that software is often buggy or unreliable, they’ve even come to expect it! Software that crashes? Oh that’s ok, just restart it. Weird error messages? Oh that’s ok, just click on them and they go away. Is it slow? Well everything is slow these days! I’ve often wondered exactly how we ended up with this culture of accepted and expected mediocrity.

At least there is one benefit: if you’re not a complete idiot, you’ve got a pretty good shot at a successful career in this field.

Takk til Mark Nijhof for linken..

Fakta #1: Den viktigste faktoren i utvikling av software er ikke verktøyene og teknikkene programmererne benytter, det er kvaliteten på programmererne selv.

Fakta #2: De beste programmererne er 28 ganger bedre enn de dårligste programmererne, ifølge forskning på “individuelle ulikheter”. Gitt at lønnen til utviklerne aldri reflekterer dette, så sier det seg selv hva som er det største “røverkjøpet” i softwarebransjen.

Nesten alle er enige i at på et overordnet nivå så er mennesker viktigere enn verktøy, teknikker og prosess. Og likevel fortsetter vi å oppføre oss som om dette ikke var tilfelle. Kanskje er dette fordi mennesker er et vanskeligere problem å addressere enn verktøy, teknikker og prosess. Vi i softwarebransjen, teknologer som vi er, foretrekker å finne opp nye teknologier som skal gjøre jobben vår enklere. Selv om vi innerst inne vet at det er langt viktigere å jobbe med å utvikle menneskene.

Påstanden over er fritt oversatt fra Robert L. Glass, 2003. Sitatet ble funnet i Object Thinking, en bok jeg akkurat har begynt å lese, og som lover å forvandle meg til en Ward Cunningham, Kent Beck, Ron Jeffries, Alister Cockburn eller Bob Martin.

Knagger: Bob+Martin

Har du fulgt med så vet du at jeg liker å høre på hva Robert C. Martin har å fortelle. På Hanselmintes #150 (podcast) sa Onkel Bob Martin noe av det samme som jeg tenkte for 2-3 måneder siden, og som fikk meg til å starte .net ninja-initiativet mitt.

“Our industry does a disservice to people because there’s no consistent career ladder. In a lot of cases the career path is: A couple of years slinging code, a couple of years leading a team, and after that I’m a manager. And once you’re a manager you never write code again.“

“I think this is dead wrong. I think it’s the wrong approach for our industry all together. If you are really serious about your profession you’re willing to be slinging code for 30 or 40 year.”

Bob påpeker at advokater forblir advokater, og kirurger forblir kirurger. Noen av dem går over til å administrere, men de fleste fortsetter sitt håndtverk. Han har forøvrig mange ganger tidligere sammenlignet det å være programmerer med yrker som advokat og lege. Alle forholder seg til noe uoversiktelig hvor det finnes mange muligheter – alle jobber med å administrere og redusere høy komplekistet.

Jeg så tidlig for meg å gå mer over til prosjektstyring og administrering – det virket liksom helt naturlig. Og ved å ta ansvar har jeg gjennom karriæren fått tildelt mye ansvar og roller som prosjekt- og teamleder. Men det er egentlig ikke det jeg vil. Jeg tar slike ansvar når det er behov for det – når jeg ikke oppfatter at andre tar dem. Men egentlig vil jeg bare bli en super utvikler.

Og jeg er enig med Onkel Bob – nå er det på tide at bransjen verdsetter programmerere som utvikler seg i faget. Det holder ikke at man kaller seg juniorutvikler de første to årene og deretter er man senior. Det er faktisk ganske latterlig. Jeg vet ikke hvordan vi skal få det til, men kanskje en definert karriærestige er det vi trenger. En som ikke innebærer at man må slutte å programmere.

En som vil være en .net ninja må ha et bevisst forhold til kunnskapskanaler. Jeg har tidligere snakket om hvilke podcasts man kan høre på, og denne gangen vil jeg snakke litt om blogger og RSS feeds.

For et par år siden leste jeg mye blogger. Min RSS leser var min primære kilde til ny kunnskap, og hver gang jeg kom over en utvikler med en interessant blog la jeg straks feeden inn i Google Reader. Men etterhvert ble det alt for mye – det blir skrevet alt for mange, spennende artikler man får lyst til å lese. En stund rakk jeg bare å markere blogposter som interresante, men rakk aldri å komme tilbake til dem for å lese dem grundig. Og det siste året har jeg ikke fulgt med på en eneste feed.

Planen min for å endre på dette er å koke listen min ned til noen få blogger med veldig høy kvalitet. Deretter må jeg etablere en rutine hvor jeg f.eks. bruker 20 minutter hver dag, eller kanskje bare annenhver dag, til å overvåke feedene og lese det som er interessant. Og her er bloggene jeg har valgt ut:

CodeBetter.com – Stuff you need to Code Better!
CodeBetter.com er en community-blog skrevet av profesjonelle .net-utviklere som David Hayden, Glenn Block, James Kovacs og Jeremy D. Miller. De har et snitt på 2 til 5 innlegg hver dag, og innholdet er førsteklasses.

devlicio.us
Samme type blog-community som CodeBetter.com, og har omtrent samme frekvens. Forfatterne er mindre kjente (i alle fall for meg), men innholdet virker bra. Mye Domain Driven Design.

LosTechies.Com
Nok en communityblog. Her kan du lese artikler av Chad Myers, Jimmy Bogard, og en rekke andre. Litt flere artikler hver dag enn devlicio.us og codebetter.

Object Mentor Blog
Den fjerde og siste community-bloggen på listen min, og den med de mest kjente navnene. Her finner du folk som Robert C. “Uncle Bob” Martin, Michael Feathers og Ron Jeffries. Object Mentor fokuserer på Agile og objektorientert design.

Til sammen gir disse fire RSS-feedene rundt 8 artikler hver dag, noen dager ferre. Det er et antall det går an å forholde seg til, og innholdet vil gi meg mye nyttig kunnskap med mindre fokus på nye teknologier, og mer på craftmanship og kvalitetskode. Nyheter innen .net får jeg med meg andre steder som podcasts og twitter, og når jeg har behov for spesifik kunnskap så er google min gode venn.

Jeg har også endel andre blogger jeg kommer til å stikke innom fra tid til annen, og jeg håper selvsagt du vil ta en titt på min feed av og til. Spesielt synes jeg det er kjekt å se hva norkse utviklere skriver om. Og jeg forsøker også å stikke innom InfoQ av og til – hvor min gode venn Jon Arild skriver ukentlige artikler. Men som regel får jeg med meg de viktigste tingene uten å aktivt gå inn og sjekke, og jeg føler det er lurt å konsentrere meg om de aller beste kildene.

Til slutt har jeg ett tips til alle som bruker en RSS reader; om antallet uleste artikler øker bør du ikke vente for lenge før du bare makerer alle som lest og begynner fra scratch. Blog-lesing skal ikke føre til stress, og går du glipp av noe som er veldig viktig så vil det dukke opp igjen andre steder senere.

Jeff Atwood og Joel Spolsky fikk kraftige reaksjoner da de snakket negativt om TDD, SOLID-prinsippene og Robert C. “Onkel Bob” Martin. For å gjøre det godt igjen fikk Onkel Bob være gjest på Jeff og Joel’s podcast. Og her kom han med noen svært krasse uttalelser selv:

“I think one of the problems we have as an industry is that we got way too many people slinging code. And we should probably reduce the number of people slinging code to the group that cares about it.”

Jeg har stor respekt for Onkel Bob, og synes han sier mye bra. Nå er ikke dette sitatet like hyggelig for alle, men husk da min kommentar om en utviklers karakter: Alle kan bli dyktige utviklere. Det krever ikke noe annet enn interesse for å utvikle sine egne vaner. Er du en av dem Onkel Bob mener ikke burde kode? Ta deg sammen da vel – alle kan klare det!

Lytt til Stack Overflow Podcast #41 om du vil høre mer.

Dine personlige karaktertrekk har direkte innvirkning på din evne til å programmere. Karaktertrekkene som betyr mest er ydmykhet, nysgjerrighet, intellektuell ærlighet, kreativitet, disiplin og opplyst latskap. Overraskende nok gjør ting som rå intelligens, erfaring, ståpåvilje og mot like mye skade som nytte når det kommer til programmering.

Å være en av de bedre utviklerne har nesten ingen ting med talent å gjøre, og nesten alt å gjøre med å forplikte seg til personlig utvikling. Mange programmerere søker ikke aktivt ny informasjon og utviklingsteknikker, men stoler heller på tilfeldig tilgang til ny informasjon når de trenger det. Hvis du bruker en liten prosent av tiden din til å lese og lære om programmering, vil du derfor etter noen få måneder eller år klart skille deg ut fra de fleste andre programmerere.

Riktige karaktertrekk er først og fremst et spørsmål om å ha de riktige vanene. Den beste oppskriftene på å bli en god programmerer er å utvikle de riktige vanene – så vil resten komme naturlig.

Påstandene over er hentet fra Code Complete (fritt oversatt etter key points fra kapittel 33). De er på en måte overraskende, samtidig som de gir mening. Jeg er blitt spesielt oppmerksom på dette med vaner, og skjønner at om jeg skal bli en bedre utvikler så må jeg kultivere nye vaner. Og det er faktisk ganske enkelt om man gjør det på den riktige måten. Man må gå sakte frem, og gjøre ting riktig. Gjør små prosjekter hvor du f.eks. fokuserer på å gjennomføre TDD 100%. Eller å følge ett av SOLID prinsippene. Gjenta, gjenta og gjenta. Om ikke lang tid har du tillagt deg en ny vane.

“The moral virtues, then, are engendered in us neither by nor contrary to nature…their full development in us is due to habit…Anything that we have to learn to do we learn by the actual doing of it…Men will become good builders as a result of building well and bad ones as a result of building badly…So it is a matter of no little importance what sort of habits we form from the earliest age – it makes a vast difference, or rather all the difference in the world.”
-Aristotle

Bytt ut “moral virtues” med “programming skills”…

Code Kata er et begrep skapt av Dave Thomas, forfatteren av The Pragmatic Programmer. Som i karate og andre kampkunster som praktiserer kata, er code kata en praksis som forbedrer dine ferdigheter gjennom øvelse og repitisjon.

På codingdojo.org fant jeg i dag en god liste over slike programmerings-kataer. Og siden jeg er syk og holder meg hjemme i dag så tenkte jeg at jeg skulle forsøke meg på en.

Så jeg satte i gang med KataBankOCR. For en gangs skyld gjennomførte jeg 100% testdreven utvikling, og det hjalp meg veldig med å gjennomføre denne oppgaven. Det tok et par timer og 33 enhetstester å lage en løsning jeg var fornøyd med, og det var både gøy og lærerikt. Jeg fikk også praktisert noe jeg har blitt spesielt oppmerksom på etter å ha lest Code Complete, nemlig bruk av tabelldrevne metoder. Dette gjorde koden min mye enklere enn om jeg i stedet hadde brukt logiske strukturer som if og switch case.

Er du interessert i å bli en bedre programmerer med code katas så anbefaler jeg å ta en titt på CodeKata siden til Dave Thomas.