Lei sløsing med utvikleres tid: «Må brukes med omhu»
– Jeg kommer til å miste forstanden om jeg blir kalt inn til enda et møte for å vurdere en kostnad som bokstavelig talt er mindre enn kostnaden møtet har, skriver Variant-utvikler Jakob Endrestad Kielland.
Et av de største sjokkene jeg fikk erfare da jeg startet å jobbe som utvikler og IT-konsulent, var det tullete antallet nuller som dukker opp når man har med penger å gjøre. Jeg husker jeg alltid prøvde å velge den billigste typen billett jeg fant, gjerne kombinert med skikkelig kjipe flyruter for å spare selskapet et par hundre kroner.
Med tiden har jeg blitt vant til at ikke alle penger er like, og at det er tullete å stresse over hvert eneste øre (selv om man selvsagt bør være fornuftig også med firmapenger).
Etterhvert som nye utviklere har startet hos oss i årene etter meg, har jeg hatt muligheten til å hjelpe dem med å forstå dette heller før enn siden, og med det forhåpentligvis bidratt til et litt lavere stressnivå.
I løpet av disse samtalene har jeg merket at jeg ofte kommer tilbake til uttrykket monopolpenger når jeg snakker om summene som bedrifter i bransjen vår forholder seg til, siden det å se dem med øyne kalibrert for personlig økonomi gjør at alle summene ser latterlig store ut.
Et av de største sjokkene jeg fikk, var det tullete antallet nuller som dukker opp når man har med penger å gjøre.
Til syvende og sist så handler det jo om hva slags summer vi er vant til å se, ikke sant? Da jeg var student jobbet jeg deltid som privatlærer, og var ganske så fornøyd med mine 210 kroner i timen. I min verden var det en veldig grei sum å tjene på en time.
Det var litt av en overgang å gå derfra til konsulentbransjen, der selv en helt fersk utvikler kan ha timepris på rundt 1.000 kroner. Dette kom selvfølgelig med en hel haug bekymringer om hvordan i alle dager jeg skulle leve opp til en så spinnvill timepris, men etterhvert ble jeg vant til dette tallet også.
Nå stusser jeg ikke engang dersom en seniorkonsulent sier at timeprisen hennes er 2.000 kroner, for selv om det er hårreisende mye penger, er det rett og slett den størrelsesordenen bransjen vår opererer med.
Fartsblindhet
Alle som har kjørt på en motorvei, vet at det er lett å kjøre for fort etter man har tatt av fra motorveien. Hjernen vår blir nemlig fort vant til å se verden suse forbi i 110 kilometer i timen. Denne effekten er så kraftig at 80 kilometer i timen, en hastighet som i høyeste grad fortsatt kan føre til dødelige ulykker, føles som skikkelig sneglefart.
Jeg tror det samme skjer med penger. Man blir vant til å se at en viss utgift er et eller annet kjempehøyt tall, på samme måte som man blir vant til 110 på E18.
Altså, okei, dette er kanskje ikke noen åpenbaring. Folk vil åpenbart se ulike utgifter i ulikt lys. Det jeg synes er interessant, er avgjørelser som påvirker flere utgifter samtidig.
Utgiftsposter er ofte sammenkoblet; det å øke en liten budsjettpost med 5.000 kroner kan potensielt spare en stor budsjettpost for 10.000. Men likevel, og jeg tror dette ofte handler om fartsblindheten jeg beskrev tidligere, så virker det som mange går glipp av at dette faktisk utgjør en stor besparelse.
Man ser en kjempestor relativ økning av én budsjettpost og en liten relativ reduksjon av en annen, og sammenligner ubevisst endringene som prosenter i stedet for faktiske beløp.
Jada, jeg vet at dette er et ekstremt eksempel. Enhver rasjonell leder med disse tallene foran seg, vil nok velge å bruke 5.000 mer ett sted for å spare 10.000 et annet. Problemet er at det er minst to ting til som gjør at det er litt vanskeligere enn som så.
- For det første er det langt fra alle avgjørelser det er lett å forutse utfallet av. En programvarelisens er en konkret, kjent kostnad, men det er tilnærmet umulig å si akkurat hvor mye penger man sparer på å kunne ta i bruk programvaren.
- Videre så er det ganske vanlig at minst én side av dette regnestykket ikke består av kroner i det hele tatt, men en eller annen abstrakt form for penger, for eksempel utviklertid.
Alle utgifter er like, men noen utgifter er likere enn andre
Det er nemlig når man begynner å snakke om utviklertid at ting blir vanskelig, enten man prøver å estimere hvor mye penger et prosjekt vil koste, eller å forutse om et kjøp vil betale for seg selv i form av spart tid.
Mitt inntrykk er at det er her mange beslutningstakere snubler. Jeg tror dette skyldes at utviklertid oppfyller alle “gjør-det-vanskelig-å-ta-gode-økonomiske-avgjørelser”-kravene jeg har nevnt så langt:
Lønn er en kjempestor budsjettpost, så det som ville vært et betydelig kutt et annet sted, kan virke ubetydelig lite her.
De fleste av oss har nok erfart hvor vanskelig det kan være å gi et estimat på hvor mye tid man vil spare gjennom et visst grep, og et eksakt tall kan man stort sett bare glemme.
Det faktum at vi snakker om tid, ikke kroner, utnytter at hjernen vår er dårlig på å sammenligne beløp i ulike formater. (Dette er en av grunnene til at du betaler for skins med “Riot points” og “V-bucks” i henholdsvis League of Legends og Fortnite, i stedet for penger.)
I resten av dette innlegget har jeg lyst til å utforske tre steder der denne lønnsfeilslutningen dukker opp ofte nok til at irritasjonen den vekker i meg, har nådd et kritisk nivå.
#1: Hvor mye kan en utviklerplattform koste da, Michael? Ti dollar?
Vi kommer til å starte med det som antageligvis er den mest åpenbare måten man, innenfor IT, kan velge mellom tid og penger: Skal vi bygge eller kjøpe løsningen?
Dette spørsmålet dukker opp overalt i bransjen vår, men jeg har lyst til å se på et konkret eksempel.
La oss sammenligne det å bruke en tjeneste som Vercel til å hoste applikasjonene dine, med å bygge en plattform som lar utviklerne dine gå fra kodebase til applikasjon på internett med minst mulig styr.
La oss gå ut ifra at man har ansatt et team på fire plattformutviklere for å lage plattformen. Disse er heldigvis også så gode til å selvorganisere seg at de ikke trenger noen ekstra roller i teamet sitt.
Det teamet koster nok minst 5 millioner i året i lønn, pensjon, feriepenger og arbeidsgiveravgift. Og forøvrig, om organisasjonen har mer enn noen få team som skal tjenes av denne plattformen, kan jeg garantere at et plattformteam på bare fire mennesker kommer til å være en flaskehals.
Med andre ord vil jeg påstå at dette tallet, 5 millioner, er ganske konservativt.
Har du noen som helst anelse om hvor mye Vercel du kan kjøpe for 5 millioner kroner i året?
Basert på en veldig røff beregning med utgangspunkt i trafikken på min egen blogg, snakker vi i alle fall om en størrelsesorden på 100 millioner sidetreff i måneden. Estimering av trafikk på Vercel er skikkelig vanskelig, siden det vil variere veldig avhengig av hva slags tjeneste man leverer, hvordan brukere oppfører seg, og hvor flink man har vært til å optimalisere for lave Vercelkostnader.
Vi kan i alle fall si sikkert at det er snakk om veldig, veldig mye trafikk på en plattform som ikke akkurat er kjent for å være billig. Og altså, dette er bare for å matche personalkostnadene til plattformteamet.
Du trenger nødvendigvis også noen servere å kjøre greiene dine på, det er vanligvis ikke gratis. Poenget er i alle fall at dette er et mattestykke som rett og slett ikke gir mening før man forholder seg til voldsomt mye trafikk.
Har du noen som helst anelse om hvor mye Vercel du kan kjøpe for 5 millioner kroner i året?
Jada, det finnes andre grunner til å bygge sin egen utviklerplattform (eller CMS, eller observabilitetsløsning, osv.), selv i tilfeller der økonomien ikke rettferdiggjør det direkte.
Et av de beste rådene jeg har hørt angående dette, er at man bør bygge de delene av systemet som gir produktet ditt et konkurransefortrinn, og trygt kan kjøpe resten. Om du bygger en YouTube-konkurrent, bør du nok bygge streamingteknologien for å sørge for at du har rom til å levere en bedre opplevelse enn konkurrenten. Innloggingsløsningen din, derimot, kan du nok trygt kjøpe.
Som en utvikler som – av natur – er skikkelig glad i å bygge ting, sier jeg ikke at vi alltid bør kjøpe oss ut av problemene våre. Men jeg synes vi må bli bedre til å vurdere om det faktisk er lurt å bruke ni måneder på å bygge dybdeforståelse for betalingssystemer fordi vi ikke hadde lyst til å gi Vipps noen prosenter.
#2: Sørg for at sirkelsagen din har nok RAM
Som nevnt i starten av dette innlegget, førte min inntreden i arbeidsmarkedet med seg en selvpålagt periode i sparemodus.
Det beste eksemplet på dette er nok et valg jeg tok da jeg skulle bestille jobb-PC. Arbeidsgiveren min hadde det jeg fortsatt mener er veldig gode retningslinjer når det gjelder valg av jobb-PC, og kjøp av arbeidsmateriale generelt: “Vi stoler på at du er fornuftig, her er firmakortet.”
Okei, kjapt sidespor – hvis du som arbeidsgiver stoler nok på en ansatt til at du er villig til å selge tiden hans for tusenvis av kroner timen, så bør du kunne stole på at vedkommende er i stand til å vise fornuft når det gjelder valg av arbeidsverktøy.
Det å henvise noen til en liste med forhåndsgodkjente laptop-undermodeller er ikke bare bortkastet tid, men også en innrømmelse av at selv etter to evnetester, fire intervjurunder og syv referansesjekker, så stoler du ikke på at den nyansatte utvikleren din har en fungerende hjerne.
Vennligst forklar hvordan dette gir noen som helst form for mening (men hold deg til firmaets forhåndsgodkjente argumentliste).
De fleste av mine kommende kolleger var på Mac, og som en som hadde vært på Windows hele livet, gledet jeg meg til å sjekke ut “the dark side”. Dette var et drøyt halvår etter Apple begynte å selge maskiner med den nye M1-chippen sin, og jeg gikk ut ifra (med rette) at den billigste prosessormodellen jeg kunne få til en MacBook Pro, ville holde for mine behov.
Tabben min var å tro at 16 GB RAM ville være rikelig. Jeg hadde hørt fra noen erfarne utviklere at det kunne være lurt å gå for mer, men da jeg så de latterlige prisene bestemte jeg meg for at 16 sikkert ville holde allikevel.
Jeg husker ikke akkurat hva prisen lå på, men jeg tror det var snakk om en prisøkning på om lag 4.000 kroner for å komme meg opp på 32 GB. I skrivende stund koster det 6.000 sure kroner å gå fra 24 (minstevalget) til 48 gigabyte RAM på en 16-tommers MacBook Pro på apple.no.
Hvis du som arbeidsgiver stoler nok på en ansatt til at du er villig til å selge tiden hans for tusenvis av kroner timen, så bør du kunne stole på at vedkommende er i stand til å vise fornuft når det gjelder valg av arbeidsverktøy
Det er nok på tide å prøve seg på Linux, ja.
Så jeg tok det økonomisk konservative valget, noe jeg virkelig har fått kjenne på konsekvensene av de siste tre årene. Skal jeg spinne opp Dockerbildene som trengs for å kjøre applikasjonen vår lokalt, så forsvinner minst halvparten av minnet mitt.
Siden absolutt alle programmer i verden kjører på Electron nå er det også sterk konkurranse om den andre halvparten. IntelliJ bruker for tiden 3-5 virkedager på å gjøre grunnleggende statisk analyse etter jeg har gjort en endring, sannsynligvis fordi den ikke får legge beslag på mer enn omtrent 2 millimeter av minnebrikken min.
Dette er nok en feil jeg ikke kommer til å gjøre igjen, men det illustrerer likevel poenget mitt godt. Hvis en snekker går på butikken for å kjøpe en sirkelsag, kan du banne på at det blir en skikkelig sirkelsag.
Vi (og ikke minst lederne våre) bør ha samme holdning til verktøyene vi trenger for å yte bra på jobb. Med “verktøy” mener jeg forøvrig ikke bare hardware, men også programvare, kurs, tjenester, og andre ting vi trenger for å være så effektive som mulig.
Jeg er villig til å vedde 16-gig-MacBook’en min på at 50 utviklere med et årlig budsjett på 20.000 kroner hver til verktøy, kurs og alt det andre de måtte trenge, kommer til å være langt mer produktive enn 51 utviklere med et årlig budsjett på 0 kroner, selv om begge koster like mye for selskapet.
Som en ekstra bonus så kommer de ansatte også til å være mye mer fornøyde dersom de får utvikle ferdighetene sine og bruke gode verktøy. Det betyr at du kan bruke mindre penger på rekrutteringsselskap som kan tråle LinkedIn etter nye ansatte (les: ofre) å skru av Figmalisensen til.
Det faktum at lønnskostnader står for en så stor andel av utgiftene i bransjen vår, betyr at et hvilket som helst grep som gjør utviklere bittelitt mer produktive i praksis er verdt tullete mye penger. Vi snakker om en vekstang av latterlige proporsjoner.
#3: Mitt bidrag til den saotomesiske økonomien
Underbevisstheten min har tydeligvis rangert disse tre hovedseksjonene etter hvor mye vrede de vekker i meg. For altså, jeg kommer til å miste forstanden (hele greia!) dersom jeg blir kalt inn til enda et timeslangt møte med tre personer for å vurdere en éngangskostnad som bokstavelig talt er mindre enn kostnaden møtet har.
Hadde spørsmålet vært om vi skulle sette fyr på 2.000 kroner hadde det fortsatt vært mer økonomisk forsvarlig å bare tenne på sedlene enn å bruke så mye tid på å diskutere det.
Den eneste måten et sånt møte kan oppstå på, er ved at møteinnkalleren har glemt hvor dyre møter faktisk er. Og bare så det er sagt, jeg sier ikke at vi aldri bør ha møter!
Hadde spørsmålet vært om vi skulle sette fyr på 2.000 kroner hadde det fortsatt vært mer økonomisk forsvarlig å bare tenne på sedlene enn å bruke så mye tid på å diskutere det.
Noen møter er nødvendige, andre er nyttige, og jeg har vært i mange møter som har ført til at folk i større grad trekker i samme retning, og at møtet derfor har spart oss tid og penger. Det beste rådet jeg har fått om møter, kom fra en tidligere kollega.
Han mente at møter er et verktøy som primært bør brukes for å få folk som ellers ikke prater med hverandre om en ting, til å faktisk snakke sammen om den.
Hvis teamet ditt allerede oppdaterer hverandre med hva man jobber på og hva slags hindringer man har møtt på, så kan du nok trygt slette den standupen fra alles kalendre.
Når det er sagt, er ikke egentlig målet mitt å gi føringer for hvilke møter du bør ha, og hvilke du bør droppe - det er et spørsmål jeg skulle ønske jeg var bedre til å svare på selv.
Jeg tror det allerede har fremgått at jeg er tilhenger av å la folk ta sine egne, velinformerte valg, og heller stole på at vi klarer å ansette flinke, fornuftige folk.
I stedet for å holde preken om hvilke møter som er nyttige, vil jeg derfor heller si meg fornøyd med å hjelpe deg å visualisere hvor kostbart et møte er, og dermed overlate valget til din gode beslutningsevne.
Inspirasjonen for hvordan jeg ønsker å gjøre det, kommer fra det som nesten helt sikkert er den dyreste møteserien jeg har vært en del av. På et prosjekt jeg var på for noen år siden hadde vi regelmessige demomøter som omtrent 120 mennesker var “sterkt oppfordret” til å delta på.
Disse varte vanligvis i minst tre timer, og besto av at hvert eneste team fikk rundt 10 minutter til å vise frem det de hadde jobbet med de siste to månedene.
Møteorganisatorene hadde nok gode intensjoner, og det var faktisk slik at kommunikasjonen mellom teamene hadde noen enorme mangler, men de aller fleste jeg snakket med var enige i at dette var en interessant måte å bruke folks tid på.
Det var i et av disse møtene jeg ble slått av en tanke om at noen bør lage en slags “møteklokke” man kan sette på i starten av et møte for å se pengene tikke avgårde. Så jeg kjøpte mitt første (og så langt eneste) saotomesiske domenenavn, meetingco.st, og lot det ligge ubrukt et drøyt år. (Ikke døm meg! Måtte utvikleren uten ubrukte domener kaste den første stenen.)
Da jeg startet på dette innlegget og merket at en utblåsning om møter var uunngåelig, brukte jeg det som motivasjon til å faktisk få laget nettsiden. Den lar deg regne ut hvor mye et møte koster, gitt varigheten og antall deltakere. Den lar deg også starte en live-teller, så du kan se kronene tikke bort hvert eneste sekund.
Kuren for det hele
Da jeg tok førerkortet lærte jeg at måten å motvirke fartsblindhet på var å følge ekstra nøye med på speedometeret mens hjernen blir vant til den nye hastigheten. Jeg har lenge lurt på hva ekvivalenten til dette er i IT-bransjen.
Jeg skulle gjerne delt et enkelt triks du kan bruke for å motvirke lønnsfeilslutningen, ikke bare fordi det hadde vært en tilfredsstillende avslutning på dette innlegget, men også fordi det hadde vært nyttig å ha for min egen del.
Dessverre så tyder alt på at verdenen vi lever i er kompleks, og det eneste jeg har klart å komme frem til er at løsningen avhenger helt av situasjonen det er snakk om.
Når det er sagt, så tror jeg at vi alle har godt av å huske at lønnskostnader er kostnader på lik linje med alt annet, og at utviklertid derfor er en valuta vi må bruke med omhu.
Jeg tror dette er spesielt viktig å huske når vi ser muligheter til å veksle inn kroner for utviklertid, for valutakursen er ofte langt bedre enn ved å ansette sin 51. utvikler.
