16-Dec

Development, Personal Development

Hvordan håndtere kontekstbytting som en utvikler

I arbeidslivet er man nødt til å skifte oppmerksomheten mellom å programmere på ulike oppgaver, sitte i møter, eller håndtere input fra kolleger.

4 min read

·

By Hein Haraldsen

·

December 16, 2021

Som utvikler kan du ikke alltid kontrollere alle aspektene i hverdagen selv, med mindre du sitter helt alene på et hobbyprosjekt.
Mailer må leses og besvares, møter må deltas i, kolleger trenger bistand eller gjennomgang av pull requests. Alt dette spiser ikke bare av din tid, men gir også en stor mental belastning i form av måtte bytte oppmerksomhet.
Kontekstbytting er noe vi alle i varierende grad må forholde oss til.

Først og fremst er det viktig å være klar over at det ikke er noe galt med en bare fordi man synes det er vanskelig å hoppe inn i en oppgave når man nettopp har vært i en helt annen kontekst. Dette gjelder sannsynligvis oss alle i varierende grad. Personlig tok det lang tid før jeg skjønte at det å streve med komme i gang på en mandag, det å være litt mer ukonsentrert på en fredag, eller den noe kjente "klokka to"-knekken på ettermiddagen i form av vanskeligheter med å fokusere, er ganske universelt.

developer with multiple screens
context switching


Hva som fungerer for den enkelte er selvsagt individuelt.
Jeg tror jeg har kommet på god vei til å finne ut hva som fungerer for meg.

Selv tror jeg jeg er mest produktiv om morgenen, og at det blir langsomt litt verre å ha hodet på rett plass utover dagen. Jeg har forsøkt å håndtere dette ved å alltid vite hva jeg skal gjøre når jeg kommer på jobb på morgenen.
Aller helst bør jeg ha oppe riktig fil i favoritteditoren, og gjerne markøren der jeg skal skrive neste kodelinje, og helst ha en god oppfatning om hva jeg skal skrive. På den måte unngår at jeg den mest våkne tiden går med til å håndtere eposter eller Slack-meldinger. Det kan jeg gjøre mens jeg f.eks. venter på at bygget skal deploye.

Mandag morgen er vanskeligere enn andre morgener. Da er det spesielt viktig for meg at jeg kan gå rett på arbeidsoppgavene, fremfor å ta meg selv i å ønske at helgen hadde vart litt lenger.

Lunsjpausen er muligens enda vanskeligere. En hyggelig prat med kolleger kan gjøre det tyngre å komme inn i kodemodus igjen. Her har jeg valgt å bare akseptere at slik det er det for meg. Jeg benytter sjansen til å oppdatere meg på intranett eller sosiale kanaler, mens jeg langsomt prøver å vri hodet i retning av arbeidsoppgaven jeg skal i gang med.

Man vet heller aldri når man støter på utfordringer man ikke greier å løse selv. I virksomhetene jeg har vært i kan det være ting som skal gjøres som er utenfor en egens kontroll, for eksempel at tilganger må bestilles, eller tjenester man arbeider mot ikke er tilgjengelig. Jeg passer alltid på å ha en annen oppgave i reserve i tillegg til det jeg holder på med, i tilfelle slike situasjoner skulle oppstå.

Helst skal jeg ha satt meg såpass inn i oppgaven da også, slik at det koster mindre å komme inn i den.

Vi må også normalisere at det skal være lov å be om å sitte uforstyrret i perioder for å skulle kode. Noen ganger er det rett og slett riktig å slå av alle eksterne forstyrrelser, gjerne sette på favorittproggemusikken, og finne ut av den vanskelige buggen uten at noe eller noen skal rive vekk fokuset. Hvordan dette bør gjøres kan man bli enige om innad i teamet, men det bør være helt greit å sette et slags symbol på pulten e.l. for å signalisere at her er det bare enda større kriser som gjøre det lov å forstyrre.

På slutten av dagen kan jeg fort få en følelse at jeg helst skulle gjort enda litt mer den dagen. Jeg setter ofte inn en liten sluttspurt for å "føle" at jeg har vært maksimalt effektiv den dagen. Dette prøver jeg egentlig å motarbeide, da jeg tror dette har liten effekt på selve produktiviteten. Hvor produktiv man faktisk er, trenger ikke å korrelere med hvor produktiv man føler seg.

Jeg har funnet hva som kan virke for meg. Kanskje dette kan inspirere andre til å finne sin formel om å hvordan bli mer produktiv.

16-Dec