10 ting om utviklere

Kom over en diskusjon her om dagen rundt å være i yrket utvikler; og der kom det frem en rekke punkter – gjerne sagt med humor men som samtidig gav en god beskrivelse av utvikler som yrke. Husker bare hva jeg selv tenkte i mine yngre dager, det å være utvikler må jo være drømmejobben. Man lærer ting, man utvikler ting og man får oppleve en masse morro – joda, jeg har aldri angret på at jeg ble en utvikler, men enkelte ting ble jeg aldri fortalt når jeg valgte å gå mot denne karrieren.

1. En utvikler har aldri rett.

Det er ikke til å legge under en stol at de fleste utviklere, eller egentlig majoriteten av de som jobber innenfor tekniske yrker, er egoister. Derfor er det da også fryktelig vanskelig å akseptere at vi faktisk har tatt feil – det finnes nok av eksempler der utviklere gjerne kan argumentere i timesvis for valg av løsning. Derfor kommer det nok ikke som en overraskelse til våre kjære prosjektledere at joda, utviklere har ofte feil – og det er ikke før vi klarer å innse det selv, at vi kan klare å høre på andre sine idéer og innspill, bruke deres tanker og lage noe bedre.

2. Om noe kan kræsje, så vil det kræsje.

En ting man så absolutt ikke har lyst til å høre fra en utvikler er; ”i utgangspunktet skal dette fungere”. Er man der, så har man gjerne store problemer. Uansett hvor liten koden kan være, så kan du ta det for gitt at noe vil så absolutt gå galt. Eneste løsningen for dette er faktisk å gjøre som man hører prosjektlederen gjerne nevner ved hvert eneste møte; spesifisere – teste, og teste litt mer.

3. All kode er dårlig.

Etter årevis med å klage over andre sin kode, så må jeg vel være enig i det som Gutierrez også sier, all kode er dårlig – inklusiv din egen. Selvsagt er det forskjellige stadier med dårlig kode, men også den beste koden kan være vanskelig å lese; hvorfor? Utviklere har forskjellig forståelse av hva som er bra kode, og hva som er dårlig kode. Hva kan gjøres bedre? Igjen kan man høre noen velkjente fraser komme snikende inn i bakhodet; dokumentere, strukturere, kommentere. Så skriv kode som du ville skrevet et kjærlighetsbrev, med lidenskap.

4. Det er alltid feil i koden.

Det er ikke til å komme utenom, man finner ALLTID feil i koden, det som betyr noe er hvor hardt man faktisk leter etter feil. Så før du stolt leverer inn produktet ditt, så la noen som aldri har prøvd produktet før teste, så skal du se hvor mange feil det faktisk er.

5. Kunden er hva som er viktig.

En ting man aldri kommer utenom er at kunden til syvende og sist bryr seg lite om hvordan du løser et problem, så lenge du løser det. Hva slags teknologi du benytter deg av, eller om du løser dette bra – er ofte brennende likegyldig. Så det er ingen grunn til å gjøre mer enn akkurat det kunden ønsker og forventer – hvis du ser at resultatet og funksjonaliteten blir det samme om du velger den raske ruten, fremfor å bruke mange timer for å få løsningen til å bli i topp-sjiktet teknisk sett – ja så sier det seg selv at både du og kunden tjener på å få unnagjort dette raskere. Kunden forventer resultat, det er hva som er viktig.

6. Komplekse spesifikasjoner fungerer ikke.

Uansett hvor hardt du prøver – komplekse spesifikasjoner vil bare gjøre at det vil være vanskeligere å gjennomføre et prosjekt. Spesifikasjoner skal være generalisert, med fokus på hva som er viktig – som hva man forventer av funksjonalitet. Spesifikasjoner er til god hjelp tidlig i prosjektfasen, men det er først når man begynner å grave i prosjektet at man ser alle de små relasjonene man gjerne ikke så under spesifikasjonsfasen. Spesifikasjoner er derfor å anse som overordnet guide – og ikke nødvendigvis den absolutte løsning.

7. Mindre er mer.

Husk at det er ikke nødvendig å putte på alle slags fancy løsninger om det ikke gir noe av verdi til produktet. Husk at om noe kan kræsje, så vil det kræsje.

8. Utvikling er bare 20% av tiden.

Ja, tro det eller ei – du kommer til å bruke 80% av tiden din på å tenke, finne feil, teste, møter og diskusjoner. Dette er da ting som må gjennomføres for å komme i mål, slik at det hjelper ikke at man er en fantastisk flink utvikler om man ikke klarer å ta del i diskusjoner, komme med innspill og forstå hvordan man kan komme til målstreken.

9. Kunden vet ikke hva den vil ha.

Kunder har gjerne et behov, eller en idé – men ofte så vet de ikke detaljene rundt dette. Utvikling kan derfor også forklares som; ”en oppdagelsesferd for å finne ut av detaljer, få klarhet i og konvertere dette til en applikasjon”.

10. Noen har gjort det før deg.

Ikke bruk tid på å finne opp hjulet, du kan ofte være sikker på at noen har løst et problem før deg. Bruk Google, eller enda bedre – bruk dine kollegaer. Ofte vil du finne at de har løst problemet før, eller i det minste – gjort noe som er veldig likt. Ikke se deg blind på et problem, spør – og du skal få svar.

Så hvem sa at det å være utvikler er enkelt? Man kan jo spørre seg hvorfor man velger et slikt yrke – men jeg vil gå ut i fra at de fleste vil samtykke når jeg sier – fordi vi simpelthen elsker yrket vårt. Så neste gang en prosjektleder henger over nakken din, så husk denne listen og se om du for en gang skyld klarer å legge egoet til side og lage noe enklere som gjør akkurat det samme.

Avslutningsvis vil jeg trekke frem en sang av Jonathan Coulton som beskriver utviklere på en perfekt måte; start helgen med låta; ”Code Monkey”.

Denne artikkelen er løst basert på artikkel skrevet av Alberto Guiterrez fra Making Good Software.