Roger Johannesen

Jeg er født i 1982 og har vært nysgjerrig på hvordan ting fungerer omtrent så lenge jeg kan huske. Ikke bare hvordan de brukes, men hva som skjer på innsiden, hvorfor de er bygget slik de er, hva som kan gå galt, og gjerne hva som kunne vært gjort bedre.

Det begynte med datamaskiner. BASIC rundt åtteårsalderen ble etter hvert til assembly, Pascal, QBasic, HTML, servere, nettverk og programmering. Siden har teknologien skiftet navn, språk og plattformer flere ganger enn jeg har oversikt over. Nysgjerrigheten har stort sett vært den samme.

Yrkeslivet tok imidlertid en langt mindre rettlinjet vei. Jeg har arbeidet med F-16 i Luftforsvaret, marinemotorer og hydraulikk, virksomhetskritiske nettverk, feilsøking på biler og til slutt sju år hos Tesla, blant annet med høyspenning, avansert diagnose og virtuell fjernfeilsøking. Underveis har sikkerhet og beredskap fått en stadig større plass. Jeg har vært valgt verneombud, lokal sikkerhetsansvarlig, industrivernleder og fagleder for industrivernet og fikk etter hvert oppgaven med å utvikle industrivernet for et landsdekkende nettverk av anlegg.

Det er en bredde jeg er stolt av. Ikke minst fordi veien dit ikke først og fremst har vært brolagt med formelle titler og lange rekker av bokstaver etter navnet. Jeg har fått roller med forventninger knyttet til seg, og så har jeg gjort det som har vært nødvendig for å vokse inn i dem. Er det noe jeg trenger å kunne som jeg ikke kan, er den naturlige reaksjonen min å lære det.

Det er sannsynligvis også den enkleste forklaringen på mye av det som finnes på denne nettsiden.

Jeg liker problemer

Eller kanskje mer presist: Jeg liker problemer som kan løses.

Det som driver meg er nysgjerrigheten og gleden ved å få noe til å henge sammen. Jeg liker å ta en idé, bryte den ned i bestanddeler, forstå sammenhengene og bygge den opp igjen som et system som faktisk virker. Det betyr ikke nødvendigvis at jeg alltid velger den enkleste veien når jeg bygger noe for meg selv. Tvert imot.

Denne nettsiden er et ganske godt eksempel. Den er overdimensjonert og overkodet i forhold til hva en personlig hjemmeside strengt tatt trenger å være. Det er med vilje. Når målet er å lære, er ikke alltid den korteste veien den mest interessante. Jeg lærer mer av å utfordre meg selv, bygge ting jeg ikke allerede vet hvordan jeg skal bygge og av og til gjøre noe langt mer komplisert enn det hadde behøvd å være.

Men det er også viktig å vite når man skal la være.

Å overdimensjonere mitt eget prosjekt er et bevisst valg fordi læringen er en del av målet. I en kundesituasjon ville den samme tilnærmingen fort vært dårlig utvikling. En løsning skal ikke være så avansert som utvikleren klarer å gjøre den. Den skal være så enkel som den kan være, samtidig som den løser oppgaven godt. Kodens dybde må møte kundens behov, tekniske utgangspunkt, ressurser og ikke minst evnen til å drifte, forstå og videreutvikle løsningen etterpå.

For meg er grensesetting derfor også en del av utviklerjobben. Å vite hva man kan bygge er én ting. Å forstå hva man faktisk bør bygge er langt viktigere. Skal jeg legge inn det lille ekstra for en kunde, vil jeg heller bruke tiden på de delene de forhåpentligvis aldri legger merke til: kvalitetskontroll, feilhåndtering, debugging, sikkerhet og gjennomtenkte mekanismer for når noe ikke går som planlagt. Det er sjelden det mest spektakulære ved et system, men det er ofte der forskjellen mellom en imponerende demonstrasjon og en god løsning ligger.

Den beste koden er ikke nødvendigvis den som viser hvor mye utvikleren kan. Det er den som gjør jobben sin, passer inn der den skal brukes og fortsatt oppfører seg fornuftig den dagen noe går galt.

På mine egne prosjekter derimot, får jeg lov til å skru på alle knottene og gjøre som Reodor Felgen: sette opp et nytt meter, eller en knapp som «tar over der det andre slutter». Kompetansen min er i stor grad bygget nettopp slik, ved å realisere ting.

«Sånn har vi alltid gjort det»

Noe av det som irriterer meg mest, er gode ideer som stopper halvveis.

Systemer med åpenbart potensial som aldri utvikles videre. Funksjoner som har blitt flaskehalser, men som fortsetter å være det år etter år fordi de tross alt fungerer. Og særlig samfunnsviktige løsninger som fremstår foreldet samtidig som nærmest betydningsløse tjenester kan være gjennomtenkte, intuitive og teknologisk moderne.

At noe fungerer, betyr ikke nødvendigvis at det fungerer godt. Og «sånn har vi alltid gjort det» har aldri vært et spesielt overbevisende argument for meg. Da har jeg lett for å tenke at "Ja vel? Kanskje på tide å endre det da?".

Mange av løsningene jeg lager begynner derfor ikke med et ønske om å programmere noe. De begynner med at jeg trenger noe, leter etter det og oppdager at løsningen enten ikke finnes, ikke gjør det jeg trenger, eller gjør en enkel oppgave unødvendig vanskelig. Da er veien overraskende kort fra «Hvorfor finnes ikke dette?» til «Greit. Da lager jeg det.»

KI endret verktøyet, ikke jobben

KI er et tema som opptar meg i den moderne verden, både med fascinasjon og en god dose skepsis. Jeg bruker teknologien aktivt som utvikler og ser enorme muligheter i den, men også spørsmål om kontroll, ansvar, kreativitet og hvor grensene bør gå. I stedet for å fylle hele Om meg-siden med tankene mine om KI, fant jeg ut at det var bedre å samle dem i en egen artikkel. Les hele artikkelen her:

Når jeg ikke holder på med dette

Jeg er heldigvis ikke fullt så systematisk hele tiden.

Familien betyr mest, og utenfor jobb og teknologi bruker jeg gjerne tiden på matlaging og friluftsliv. Jeg fotograferer, bygger og reparerer ting i metall og tre, og har en forkjærlighet for historie. Historie fascinerer meg mye av samme grunn som feilsøking gjør: Man har fragmenter av informasjon, kilder som ikke alltid er enige og manglende brikker, og oppgaven er å sette det sammen til et bilde som faktisk holder.

Jeg driver derfor også et lokalhistorisk arkivprosjekt hvor jeg kombinerer research med utvikling. Jeg kan være ganske pirkete. Setter du på en film hvor fysikkens lover blir behandlet som vennlige anbefalinger, finnes det en betydelig risiko for at jeg påpeker det. Dette øker ikke nødvendigvis filmopplevelsen for de andre i rommet.

Jeg liker å tro at jeg også er morsom. Det finnes mennesker rundt meg som ennå ikke har bekreftet dette, men det kan skyldes manglende teknisk innsikt. Fellesnevneren er nok at når noe først vekker nysgjerrigheten min, har jeg vanskelig for å la det ligge. Et problem jeg virkelig ønsker å løse kan utvikle seg til noe som ligner en mindre besettelse. Jeg må forstå hvorfor. Jeg må finne ut hvordan. Og når jeg først har forstått det, får jeg gjerne lyst til å bygge det også. Det er mye av forklaringen på denne nettsiden.

Den enkleste veien gir ikke alltid nok motstand til å være interessant, men kunsten er å velge den veien som gir et resultat du er stolt av.

To sitater oppsummerer mye

Det ene kommer fra Solan Gundersen:

«For Solan er vanskelighe en bagatell, og det umulige en utfordring.»

Det andre forbindes med Jack Sparrow:

«The problem is not the problem. The problem is your attitude about the problem.»

De er sagt av to fiktive figurer som neppe burde få ansvaret for henholdsvis HMS eller prosjektledelse. Likevel treffer begge noe jeg har tatt med meg gjennom livet. Problemer ser forskjellige ut avhengig av hvor du står. Erfaring fra ett fag kan være akkurat det som gjør at du ser noe menneskene i et annet fag har sluttet å legge merke til. Jeg verdsetter derfor bredden i erfaringene mine minst like høyt som dybden i de enkelte fagene.

Jeg har fått arbeide med fly, båter, nettverk, biler, mennesker, sikkerhet, beredskap og kode. De erfaringene har lært meg forskjellige måter å betrakte det samme problemet på. Og kanskje er det egentlig det jeg ønsker at denne siden skal vise.

Jeg er nysgjerrig, analytisk, ganske pirkete, tilpasningsdyktig og oppriktig begeistret når jeg får holde på med noe jeg synes er interessant. Jeg liker å lære, jeg liker å bygge, og jeg liker mennesker som tør å spørre hvorfor noe fungerer slik det gjør.

Jeg har ingen ambisjon om å kunne alt. Et faktum er vel det gamle ordtaket at når du tror du har forstått alt, så har du sannsynligvis ikke forstått noen som helst. En annen vinkling er vel at tenk hvor kjedelig livet ville blitt uten å ha mer å oppdage? Men møter jeg noe jeg ikke kan, har jeg som regel lyst til å finne det ut.

KERNELPANICMODE og tidlig datanerd

I mine tidlige år som programmerer brukte jeg KernelPanicMode som en slags digitalt artistnavn. For en programmerer er det kanskje et av de mindre betryggende navnene man kan velge frivillig. En kernel panic er ikke en vanlig programfeil. Kjernen, kernel, er den mest grunnleggende delen av operativsystemet, laget som blant annet håndterer maskinvaren, minnet og prosessene alt annet er avhengig av. Når kjernen oppdager en alvorlig feil den ikke lenger kan håndtere på en trygg måte, stopper den hele systemet. Det er datamaskinens variant av: «Dette har gått så fundamentalt galt at det tryggeste jeg kan gjøre nå er absolutt ingenting.»

Begrepet forbindes derfor ikke akkurat med stabilitet, kontroll og tillitvekkende programvareutvikling. Hadde jeg i dag forsøkt å selge meg inn som profesjonell utvikler eller systemarkitekt under navnet KernelPanicMode, ville det vært omtrent som om en elektriker kalte firmaet sitt Kortslutning AS eller en pilot presenterte seg som ControlledCrashMode. Teknisk relevant, absolutt. Tillitvekkende, kanskje ikke.

Historien bak navnet er heldigvis langt mindre dramatisk.

Jeg ble kalt datanerd av skolekameratene mine omtrent så langt tilbake som jeg kan huske. Det var verken spesielt pent ment eller særlig stas den gangen. I voksen alder bærer jeg derimot betegnelsen med en viss stolthet. For å være datanerd på slutten av 1980-tallet krevde faktisk en ganske spesiell form for stahet.

Jeg begynte å utforske datamaskiner og kode rundt seks/syvårsalderen, cirka 1989. Det var lenge før internett kunne redde deg, før YouTube kunne vise deg hvordan, og rundt tre tiår før du kunne spørre en KI hvorfor koden din ikke virket. Når noe gikk galt, fantes det ingen søkemotor å lime feilmeldingen inn i. Ingen forumtråd der noen hadde hatt nøyaktig samme problem elleve år tidligere. Ingen video med tittelen FIXED!!! 100% WORKING!!! og et miniatyrbilde av noen som peker sjokkert på en feilmelding. Stort sett hadde du ikke engang noen å spørre.

Var du heldig, hadde du en manual. Var du enda heldigere, inneholdt den faktisk svaret. Den var selvfølgelig på engelsk, et språk jeg på det tidspunktet fortsatt holdt på å lære. Dermed kunne selve jakten på løsningen innebære først å finne ut hva problemet het, deretter hva ordene betydde, og til slutt hva i all verden datamaskinen forventet at du skulle gjøre med det.

Resten måtte løses med nysgjerrighet, logikk, prøving, feiling og en ganske betydelig mengde tålmodighet.

Mye av engelsken min lærte jeg faktisk gjennom dataspill, og særlig Sierra-eventyrene. De gamle tekstparserne hadde liten forståelse for at spilleren bare var et norsk barn som forsøkte så godt han kunne. Kommandoen måtte være riktig, ordene måtte være riktige, og de måtte helst være stavet riktig også. Datamaskinen var en nådeløs, men overraskende effektiv engelsklærer.

Programmering fungerte på omtrent samme måte: Du prøvde. Det virket ikke. Du forsøkte å forstå hvorfor. Så prøvde du igjen. Noen ganger lærte du noe. Andre ganger klarte du å få hele maskinen til å dø (ja så dramatisk var det). Og nettopp der ligger KernelPanicMode. For den tidlige datanerden var feil ikke bare noe som sto i veien for målet. Feilene var mye av undervisningen. Når du ikke hadde noen fasit, måtte du lære deg å bryte ukjente problemer ned i mindre deler, lete etter sammenhenger og systematisk eliminere det som ikke kunne være årsaken.

Du lærte også noe som jeg fortsatt mener er viktig: «Jeg vet ikke» betyr ikke nødvendigvis stopp. Det betyr bare at neste oppgave er å finne ut av det. Det er en måte å tenke på som har fulgt meg siden. Å være «datanerd» i den tidlige dataalderen handlet derfor om mer enn å være glad i datamaskiner. Du måtte lære deg å strukturere problemer du aldri hadde sett før, forstå systemer uten nødvendigvis å ha dokumentasjonen du trengte, formulere hypoteser, teste dem, forkaste dem og prøve igjen. Ikke fordi noen hadde lært deg en metode for problemløsning, men fordi alternativet var at problemet forble uløst. Kanskje var det også denne utfordringen som gjorde det å være datanerd, om ikke å leve som en, så spennende?

Teknologien har forandret seg voldsomt siden 1989. Verktøyene jeg har tilgjengelig i dag ville fremstått som ren science fiction for seks år gamle meg. I dag kan jeg diskutere et problem med en KI, få analysert kode på sekunder og hente fram mer teknisk dokumentasjon enn jeg kunne lest på et helt liv. Men selve problemløsningen er merkelig gjenkjennelig.

Forstå systemet. Finn logikken. Bryt problemet ned. Gjør en antakelse. Prøv den. Finn ut hvorfor du tok feil. Juster. Prøv igjen. Bygg videre på det du lærte. Verktøyene har blitt dramatisk bedre. Behovet for å forstå hva man holder på med har ikke forsvunnet.

Så ja, KernelPanicMode er oppkalt etter øyeblikket der et datasystem i praksis har mistet fullstendig kontroll og bestemt seg for at det eneste forsvarlige er å stoppe alt. På en eller annen måte syntes jeg det passet godt som navn på fyren som brukte mesteparten av tiden på å finne ut hvorfor.

Bulletin board-systemer var forløperne til det vi nå kaller nettsteder. Den gangen ringte man ikke til "internett" også kunne man kommunisere med hele verden. Den gangen ringte man en spesifikk BBS tjener.