-
Leder for utstedelse og styring av BankID
-
Head of Finance
-
Direktør for KI Norge
-
Konserndirektør digitalisering og teknologi
-
Senior Full-Stack Utvikler | Lawai
-
Senior Security Engineer | Firi
-
Medeier* | Boitano
-
Utvikler | Blank
-
FullStack Site Reliability Engineer | Vespa.ai
-
Lead Security Software Engineer | Vespa.ai
innlegg
❞ Slutt å ansette etter rammeverk. Ansett dem som har vært med når det virkelig brenner
Det finnes en enkel måte å få mer fart i utviklingsteamet på: Start litt saktere. Det høres bakvendt ut, men tid brukt på å ansette riktig gir høyere tempo når prosjektet blir komplekst, skriver utvikler Eirik Midttun i Witted Megacorp.
Rekruttering innen utvikling har fått en uvane der stillingsannonser fylles med rammeverk og årstall. Fem år i React. Tre år i Kotlin. To år i et skyprodukt. Det gir et ryddig filter, en rask prosess og en følelse av kontroll. Det gir også et team som ser sterkt ut på papiret, men som raskt bruker mer tid enn planlagt på å håndtere overraskelser i virkeligheten. Når mye står på spill, kan krav om X år i Y bli en ulempe, fordi de favoriserer smal stack-kunnskap over risikoforståelse.
Høyrisikoprosjekter handler sjelden om ren syntaks. De handler om uklarhet, endring og konsekvenser. Krav flytter seg. Det som gir fart på lang sikt, kommer fra folk som har håndtert slike situasjoner før, og som har lært mønstre som gjentar seg på tvers av teknologi.
Spesialisten og strategen
Jeg skiller ofte mellom spesialisten og strategen. Spesialisten har dyp ekspertise i et tydelig avgrenset område. Det gir høy verdi når oppgaven er kjent og stabil. Strategen har dyp forståelse av hvordan programvare fungerer som et system: dataflyt, samtidighet, feilhåndtering, ytelse, innsikt i hva som faktisk skjer i produksjon (observability), sikkerhet og drift. Strategen er noe mer enn en generalist; en utvikler med dybdeforståelse som flytter seg raskt mellom teknologier og ser konsekvensene av valg i produksjon.
Strategen kjenner mønstre som dukker opp i nye rammeverk med nye navn, og tar gode valg når prosjektet endrer retning.
Generativ AI gjør dette skillet tydeligere. Verktøyene hjelper med oversettelse mellom språk, forslag til API-kall og koding blir mindre tidkrevende. Kodesyntaks er ikke lenger et stort hinder. Samtidig øker verdien av dømmekraft, som evnen til å se hva som skjer når koden møter last, tidspress, nettverksfeil, ressursknapphet og samtidighet (concurrency) – der flere ting skjer på én gang og rekkefølgen varierer. Kunnskap er å kunne syntaksen og verktøyene. Dømmekraft er å forutse hva som ryker når systemet får belastning.
AI gjør dømmekraft til konkurransefortrinn
AI-generert kode som ser gjerne vakker og gjennomført ut, kan inneholde subtile feil som kan gi store konsekvenser, særlig med språk som C og C++ som kjører i flertrådet kode.
Erfaring med slike feil gir et instinkt for hvor man skal lete, hvilke antakelser som må testes, og hvilke løsninger som skalerer. Den raske starten dere får av rammeverk-match varer ofte kortere enn dere tror. Uansett rammeverk tar det tid å lære kodebasen, domenet, historikken og måten teamet jobber på.
Derfor bør rekruttering måle ansvar og erfaring i tillegg til ferdigheter. Start med å skrive stillingsannonser som peker på situasjoner, eierskap og modenhet:
Erfaring med systemer i produksjon, med vaktordning, hendelser og forbedringer
Erfaring med ytelse og stabilitet, med måling, tuning og regresjoner
Erfaring med sikkerhet og avhengigheter, med oppdateringer, risikovurdering og leverandørkjede
Erfaring med endring, migrering og teknisk gjeld, med prioritering og kommunikasjon
I intervjuer gir erfaring fra når det virkelig brenner tydelige signaler. Be kandidaten fortelle om en hendelse de husker. Hva var symptomene? Hvordan fant teamet årsaken? Hvilke tiltak ble gjort i kode, prosess, overvåking og feilsøking? Be om en historie om et valg som senere viste seg dyrt, og hva de lærte. Svarene sier mye om perspektiv, samarbeid og faglig tyngde.
Ulike bakgrunner gir bedre beslutninger
Bygg også team med variert bakgrunn. Erfaring fra embedded, plattform, app, data, drift og sikkerhet skaper bedre samtaler og bedre beslutninger. Jeg har sett hvor mye lettere det blir å løse nye problemer når teamet har møtt de samme mønstrene i andre domener. Det gir flere perspektiver i rommet før man låser seg til første løsning som «føles riktig» i dagens
stack. Det gir et miljø der folk oppdager svakheter tidligere, og der kvalitet blir et felles ansvar. I praksis er dette risikostyring: den dyreste regningen kommer når systemet feiler i produksjon, ikke når dere sitter i intervjurommet.
Bruk litt mer tid på å ansette riktig. Det sparer dere for mye tid i produksjon. Rammeverk kan læres. Dømmekraft kommer fra å ha vært med når det virkelig brenner, og fra å ha gjort jobben med å forstå hvorfor det brant.