fredag 10. april 2009 Softwareutvikling Meninger Personlig utvikling
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.