Det er en setting som er overraskende temmelig utfordrende hver eneste gang, og det er når man er i starten av et oppdrag. I tillegg til at nye kolleger skal læres å kjenne, nye rammeverk eller programmeringsspråk må gjøres kjent med, eller i det minste oppfriskes, så er det at løsningen man skal jobbe med, eller domenekunnskapen, må tilegnes.

For min egen del tenker jeg ofte hvor vanskelig kan det være?

En saksbehandlingsløsning i offentlig sektor kan da ikke være så forskjellig som et bedriftsbanksystem i en privat bank? I alle fall ikke så ulikt at man snakker om måneder for å ansees som produktiv?

Gjennom over 20 år som utvikler har jeg ofte satt meg som mål å være en som bidrar tidlig. Ikke minst fordi at følelsen av å bidra godt inn i et oppdrag er mye mer behagelig enn å kjenne på at man henger litt etter.

Mange organisasjoner har opplegg for onboarding og parprogrammering i starten, noe som selvfølgelig er en god praksis. Her tenker jeg på de mange timene man disponerer mer på egen hånd, og kan angripe det store ukjente domeneuhyret som man vil.

Her er noen små grep som jeg synes har fungert for meg.

Begynn med enkle oppgaver

Da jeg begynte på et tidligere oppdrag, og skulle for første gang tråkke rundt helt på egen hånd i kodebasen, fant jeg den tilsynelatende enkleste og minste oppgaven jeg kunne finne, i dette tilfelle å legge et bilde av en ugle ut sammen med resten av firmalogoen. I kompliserte nok kodebaser er det ikke bare - bare å finne rett sted å gjøre kodeendringer, og ikke minst hvordan teste at endringene er ute.

Og veldig greit at ting blir med helt ut i produksjon, slik at du blir kjent med organisasjonens rutiner for deploy, kvalitetssikring i form av f.eks. pull requests og produksjonssetting. Ikke minst gir det en god følelse å kunne rapporte at, joda, jeg har faktisk løst en oppgave på boardet, selv om jeg er helt ny her og knapt kan navnene til alle teammedlemmene enda.

Bli ekspert på noe

Det er fort gjort å bli overveldet av et enormt og fremmed domenespråk. I stedet for å fokusere på det du ennå ikke har taket på, begynn med litt av gangen.
Finn en liten ting, kanskje en supportsak eller et spørsmål fra en annen utvikler, som er lite nok til å håndtere for deg som er helt fersk.

Tidlig i et oppdrag kastet jeg meg over en kundehenvendelse som så liten nok ut til at jeg kunne greie å sette meg inn i den på kort tid, og kanskje til og med levere en løsning.

At løsningen ikke ble riktig på første forsøk fikk så være, en bratt men hyggelig læringskurve gjorde at denne lille tingen var det jeg som kunne best. Snart kunne jeg også delta i diskusjoner, og bli ansett som en autoritet på dette lille området.

Ikke minst gjør det et under for selvtilliten i oppdraget, noe som er uvurdelig for å prestere best mulig!

Still dumme spørsmål!

Dette er jo ikke så revolusjonerende i seg selv at verdifullt både for en selv og for resten av teamet å se utfordringene med nye, friske, øyne. Men når det gjelder perioden man sitter for seg selv, gravende i ukjente klasser og funksjoner, kan det være nyttig å stille de dumme spørsmålene for deg selv. Prøv å forenkle kode og problemstilling mest mulig, til det banale. Det er en nyttig måte å lære hvor skoen (og kompleksiteten) trykker.

Gå gjennom kodebasen for å se om det er noe du (tror) du kan gjøre bedre.
Selv om dette skulle føre til at noen tester ikke kjører riktig, eller funksjonalitet brekker lokalt hos deg, er det godt læringsutbytte.

Test løsningen som om du skulle være en bruker

Før du kanskje hvordan noen av brukerene ser ut, eller oppfører seg, kan det være en nyttig øvelse å tenke etter hvordan du tror de agerer. Med begrenset kunnskap kan du prøve å forestille hvordan du antar at du ville jobbet. Klikk deg rundt så mye som mulig for å teste løsningen. Jeg tenker ikke da at du skal forsøke å finne feil og svakheter (selv om det også er en bonus!).

Når de virkelige brukerene kommer på banen sitter du med en kvalifisert gjetning på hva de lurer på, og du har kanskje allerede (med dine ferskisbriller) kommet med noen gode forslag.

Henvendelser og supportsaker vil komme fra enten bruker eller egen organisasjon, så det er ikke så dumt at du allerede har vært gjennom det du kan av produktet på din måte!

TL;DR

Hvis jeg skal gi ett kort råd om hvordan du skal angripe et nytt domene - prøv å bli helt rå på én ting - uansett hvor liten den tingen er. Det skaffer rom, god selvfølelse, og autoritet til å bygge videre kompetanse ut fra.

Lykke til med ditt neste oppdrag og tilegningen av domenekunnskap!