Hvor mange faglige spørsmål har du i løpet av en dag?
Jeg har hundrevis: “Hvordan skrives en dato i C#?”, “Hva er egentlig dependency injection?”, “Hvorfor er skjermen gul — kodeendringen burde jo ikke ha ført til en feil?”.
Hva gjør du med spørsmålene du har?
Jeg stiller dem ofte til teamet. Selv om jeg alltid blir møtt med tålmodighet og gode svar, tror jeg ikke dette er det første du bør gjøre.
Google først
Ta eksempelet med å bli møtt med en nettside som kræsjer. Jeg har flere ganger blitt møtt en mystisk feilmelding, og instinktivt spurt andre teammedlemmer om de har sett feilmeldinga før.
Det første de gjør er å gjøre et søk på nett, og løsningen står som første resultat.
Andre ganger kan jeg spørre ting som “hva er egentlig dependency injection?”. Så får jeg en forklaring, men forklaringen går rett over hodet mitt. Vosj.
Om du alltid stiller spørsmål til teamet ditt før du prøver selv, tror jeg du taper både mestring og stjeler tid fra både deg og teamet ditt.
Jeg tror du gagner mye på å prøve minst 15 minutter på egenhånd.
Sindre og Kent Inge har tre forslag til hvordan du løser kodeproblemene dine
15-minuttersregelen
15-minuttersregelen innebærer at du ved et hinder venter minst 15 minutter før du ber om hjelp fra teamet. I disse 15 minuttene prøver du selv å løse problemet. Om du etter 15 minutter ikke har noen retning, kan du spørre.
Grunnen til at jeg tror denne regelen kan være nyttig, er at jeg tar meg selv i å stille spørsmål som er veldig googlebare. Om det er et spørsmål med en enkel fasit, kan det være raskere å bruke en søkemotor enn å spørre en person.
Alle spørsmål er ikke like enkle. Noen ganger kan det du lurer på være uklart, så du vet ikke engang vet hva du skal spørre om. Du vet du skal sette opp dependency injection, men vet ikke hva dependency injection er. Du mangler noen knagger.
«Om det er et spørsmål med en enkel fasit, kan det være raskere å bruke en søkemotor enn å spørre en person.»
Uten knagger kan det være vanskelig å forstå forklaringer eller stille spørsmål. Løsningen kan være å bruke hinderet som en læringsmulighet. Tillat deg hvert fall 15 minutter på å danne noen knagger. Les deg opp på dokumentasjon, bloggposter eller se en YouTube-video på temaet. Det er litt greiere å sparre om oppsett av dependency injection, om du først har funnet ut hva greia med dependency injection er.
15-minuttersregelen innebærer ikke at du må bli ferdig innen 15 minutter. Å sette opp dependency injection, og sjekke om det er rett, kan jo ta timesvis. Det kan også hende at du er på vei mot en løsning etter 15 minutter, men heller ikke da må du be om hjelp. Det viktigste etter 15 minutter er å ha en retning. Om du ikke har det, bruk teamet rundt deg.
Men hvordan ber du om hjelp?
Hvordan ber du om hjelp?
Hvem av disse er det enklest å hjelpe?
Aksel:
"Kan du hjelpe meg med å åpne syltetøyglasset?"
Bård:
"Kan du hjelpe meg med å åpne syltetøyglasset? Jeg har prøvd å holde lokket med en hånd og vri glasset med den andre."
Bård kommer med ting han allerede har prøvd, så jeg vil hvert fall ikke foreslå det. Her sparer vi begge tid. Jeg kan foreslå uprøvde ting, som å sette lokket under varmt vann. Jeg tror det også kan være lettere å sparre med Bård om løsninger, siden han har forsøkt noen løsninger og dermed har noe bakgrunnsinformasjon.
Etter å ha fått til vane å liste opp hva jeg har prøvd, blir 15-minuttersregelen trigget om jeg skriver et ensomt spørsmål på Slacken. Noen ganger glemmer jeg rett og slett å sjekke åpenbare løsninger, som å google en feilmelding. Så om jeg ser meg selv stille et ensomt spørsmål, prøver jeg hvert fall 15 minutter, og ser om jeg får noe retning.
Mange ganger er jeg Aksel:
"Jeg ønsker å åpne et syltetøyglass, men vet ikke hvor jeg skal starte. Kan du hjelpe meg med en retning?"
Jeg syns også det å spørre om retning kan være et fint spørsmål. Du viser hva du ønsker å løse, og du viser at du er villig til å jobbe mot å finne løsningen. Du trenger bare litt hjelp med å starte.
Mikaels beste tips for å bli en bedre utvikler kan oppsummeres med ett ord
Ikke vent for lenge
Mitt mål med å formidle 15-minuttersregelen er todelt:
- Å oppfordre de som spør ved første hinder til å se etter en løsning selv først.
- Å oppfordre de som jobber for lenge på egenhånd, å ta kontakt med den store ressursen teamet deres er.
15-minuttersregelen har hjulpet meg med å finne svar på ting jeg lurer på. Jeg tillater meg mer tid på å forstå rundt problemet, så jeg får mer helhetsforståelse. Det gir meg mestring å oftere finne svaret på egenhånd, selv når det bare innebærer å google en feilmelding. Jeg får også mestring av å være en aktiv part i sparringen.
«Teamarbeid handler ikke om å bare gi svar til hverandre, men også å diskutere løsninger.»
For 15-minuttersregelen handler ikke om å slutte å spørre om hjelp. For all del, utnytt kompetansen teamet ditt sitter med. De har møtt på lignende problemer, så de kan hjelpe deg. Og når du finner løsningen, er andre interessert i svaret. Kunnskapsdeling er bra for et team.
Det er noen scenarioer hvor 15-minuttersregelen ikke er relevant, som når du sitter og jobber tett sammen med en annen. Du trenger heller ikke å vente 15 minutter om du parprogrammerer med en annen. Eller at du vet at en annen nettopp har løst samme problem. Teamarbeid handler ikke om å bare gi svar til hverandre, men også å diskutere løsninger.
Jeg håper denne posten kan hjelpe deg å ta et hinder som en utfordring. Jeg håper du først prøver å løse problemet på egenhånd og tar deg tid til å lese deg opp om temaet rundt problemet. Også håper jeg du ikke venter for lenge med å spørre om hjelp når du står fast.
Når syns du at man bør be om hjelp fra teamet?
