Heisann,
velkommen!

Arbeidsprosessen starter vanligvis med et møte mellom meg og min leder, hvor vi gjennomgår prosjektets mål, krav og ønskede funksjonalitet. Lederen presenterer ofte skisser eller andre visuelle eksempler for å illustrere hvordan løsningen skal se ut og fungere. Under møtet dokumenterer jeg relevante krav, tekniske behov og andre viktige detaljer som danner grunnlaget for det videre utviklingsarbeidet. Når jeg har fått tilstrekkelig oversikt over prosjektet, oppretter jeg et nytt prosjektoppsett og registrerer nødvendige konfigurasjonsverdier i databasen. Disse verdiene er spesifikke for det aktuelle prosjektet og kan blant annet omfatte CSS, JavaScript, applikasjonsruter og andre prosjektspesifikke innstillinger. Ved å håndtere slike innstillinger gjennom databasen kan vi gjøre enkelte endringer uten å måtte gjennomføre en ny deployment via Azure Pipelines. Dette reduserer behovet for unødvendige deployeringer og gjør det enklere å tilpasse løsningen underveis i utviklingsprosessen.

Når prosjektoppsettet er klart, oppretter jeg en egen feature-branch i vårt monorepo. Dette gjør det mulig å utvikle ny funksjonalitet isolert fra øvrige endringer i kodebasen. Vi benytter JWT (JSON Web Token) som en del av mekanismen for å identifisere og skille mellom ulike kunder. Vi har valgt en monorepo-arkitektur fremfor separate repositories for hver kunde. Dette gjør det mulig å samle prosjektene i én felles kodebase, samtidig som kundespesifikk funksjonalitet kan organiseres og vedlikeholdes separat. En slik struktur legger til rette for gjenbruk av felles kode, enklere vedlikehold og bedre skalerbarhet etter hvert som antall kundeprosjekter øker. I frontend-utviklingen følger jeg etablerte prinsipper for komponentbasert arkitektur, med særlig fokus på gjenbrukbarhet. Mappestrukturen organiseres slik at mindre, gjenbrukbare komponenter kan kombineres til større komponenter, som til slutt utgjør komplette seksjoner i brukergrensesnittet. Delte typer og hjelpefunksjoner organiseres i egne mapper for å sikre en oversiktlig og vedlikeholdbar kodebase. Denne tilnærmingen reduserer duplisering av kode og gjør det enklere å videreutvikle eksisterende funksjonalitet. Endringer i felles komponenter kan også gjenbrukes på tvers av flere deler av løsningen, noe som bidrar til mer konsistent funksjonalitet og design. Gjennom hele utviklingsprosessen legger jeg stor vekt på robusthet, lesbarhet og tydelig ansvarsfordeling. Dette innebærer blant annet bruk av optional chaining, hensiktsmessige fallback-verdier, beskrivende funksjonsnavn og komponenter med klart definerte ansvarsområder. Optional chaining og fallback-verdier benyttes for å håndtere situasjoner der data fra API-er er mangelfulle eller udefinerte. Dette reduserer risikoen for kjøretidsfeil og bidrar til at brukergrensesnittet fungerer mer forutsigbart, også når datagrunnlaget ikke er komplett. Tydelig ansvarsfordeling og beskrivende navngivning gjør samtidig koden enklere å forstå, feilsøke og vedlikeholde. Samlet bidrar disse prinsippene til høyere kodekvalitet, mer konsistente brukeropplevelser og en mer strukturert utviklingsprosess. Målet er å utvikle løsninger som er enkle å forstå, vedlikeholde, videreutvikle og gjenbruke i fremtidige prosjekter.

Vår backend er integrert med etablerte kjernesystemer gjennom REST-API-er. Data fra disse systemene blir normalisert, indeksert og mellomlagret (cachet) for å sikre effektiv databehandling og tilgjengelighet. Normalisering bidrar til en mer konsistent datastruktur på tvers av ulike kilder, mens indeksering og mellomlagring kan redusere behovet for gjentatte og ressurskrevende dataoppslag. Dette legger til rette for raskere datatilgang og mer effektiv kommunikasjon mellom frontend og backend. Disse dataene benyttes videre i utviklingen av nettsider og digitale salgsoppgaver, hvor frontend presenterer informasjonen på en strukturert og brukervennlig måte.

Alle våre produkter utvikles med TypeScript, som bidrar til økt typesikkerhet og gjør det mulig å avdekke potensielle feil allerede under utviklingen. Dette reduserer risikoen for type-relaterte kjøretidsfeil og gjør kodebasen mer forutsigbar og enklere å vedlikeholde. Hyppigheten på statusmøtene varierer ut fra prosjektets fremdrift, kompleksitet og behovene som oppstår underveis. Når ny funksjonalitet er klar for demonstrasjon, deployes prosjektet gjennom Azure Pipelines til et eget testmiljø med tilhørende domene. Her kan løsningen testes og gjennomgås før eventuell produksjonssetting. Bruken av et separat testmiljø gjør det mulig å demonstrere og kvalitetssikre funksjonalitet uten å påvirke løsningen som allerede er tilgjengelig for sluttbrukerne. Dette reduserer risikoen for at uferdige endringer introduseres i produksjonsmiljøet. Tilbakemeldinger fra kunden mottas vanligvis via e-post eller i forbindelse med statusmøter. Dersom tilbakemeldingene krever ytterligere avklaringer, kommuniserer jeg direkte med enten leder eller kunde for å sikre en felles forståelse av ønskede endringer. Basert på tilbakemeldingene gjør jeg nødvendige justeringer i koden og tester funksjonaliteten på nytt. Før en løsning lanseres, gjennomføres det også en kodegjennomgang av en seniorutvikler. Formålet er å kvalitetssikre implementasjonen, identifisere mulige forbedringer og kontrollere at koden følger etablerte prinsipper for struktur, lesbarhet og vedlikeholdbarhet. Kombinasjonen av TypeScript, testing og kodegjennomganger bidrar til høyere kodekvalitet og redusert risiko for feil i produksjon. Kodegjennomgangene gir meg også verdifulle faglige tilbakemeldinger som jeg kan ta med meg videre i utviklingsarbeidet.

Utviklingsprosessen er iterativ, noe som innebærer at løsningen videreutvikles gjennom gjentatte sykluser med implementering, testing, demonstrasjon og tilbakemeldinger. Denne arbeidsformen gjør det mulig å avdekke misforståelser og forbedringsmuligheter tidlig, samtidig som kunden får anledning til å påvirke løsningen underveis. Ved å gjennomføre jevnlige evalueringer og justeringer reduserer vi risikoen for å utvikle funksjonalitet som ikke samsvarer med kundens behov. Prosessen gjentas frem til kunden er fornøyd og løsningen oppfyller de avtalte kravene.

Jeg er en person som lader batteriene best med egentid. Har en sterk lidenskap for film. Som barn, ungdom og voksen har jeg opparbeidet meg en del innsikt når det kommer til manusforfattere, regissører, skuespillere, filmstil og virkemidler som etter min mening gjør en god filmopplevelse. Er veldig fascinert i behind-the-scenes klipp som forklarer hvordan filmteknikk utføres i bakgrunnen og hvordan det til slutt oppleves for en seer. Ellers liker jeg å se dokumentarer om teknologi og samfunnet vi lever i. Musikk er også en stor del av livet. Hører veldig mye på metal (deathcore, slam), liquid dnb, trap, dubstep. Trener regelmessig, da jeg opplever at dette gir en mental klarhet og godhetsfølelse etter en session, noe som er viktig i livet generelt.

Jeg er tilhenger av tydelig kommunikasjon, bistår gjerne andre eller er med å løse utfordringer. Som person er jeg hyggelig og samarbeide med. Trives best i team som har et åpent mind-set, respekterer og vil hverandre det beste, deler av sin kompetanse og erfaringer på en empatisk måte. Dette ser du også fra referansen min.

Å bli en del av et faglig varmt arbeidsmiljø hvor jeg kan vokse videre, lære mer og bygge gode erfaringer, et sterkt nettverk og bedre forståelse for skalerbare systemer med samfunnskritisk nytteverdi.

Hvis vi er en match og kjemien stemmer så gir jeg veldig mye av meg selv. Dvs at utvikler rollen ikke bare en en vanlig jobb for meg. Dette er et fag jeg er glad i og har driv for, sammen med menneskene jeg samarbeider med. Det har ofte forekommet å sitte utenfor ordinær arbeidstid fordi jeg ønsker at kunden skal være fornøyde. Jeg er disiplinert, ydmyk og lærer fort via praksis fra reele produkter.

Ønsker å jobbe videre med skalerbarhet, arkitektur og optimalisering fullstack. Er også nysgjerrrig på Go, .NET og C# i backend. Håper å kunne jobbe meg opp til et mer senior nivå med mer ansvar for helheten.