Det første prosjektet mitt som faktisk hadde brukere var ikke spesielt imponerende. En enkel app, pushet til produksjon med en god dose optimisme og veldig lite feilhåndtering. Den krasjet innen den første uken. Ikke fordi koden var dårlig — den fungerte perfekt på min maskin — men fordi jeg ikke hadde forstått forskjellen mellom kode som kjører og et system som fungerer.
Den forskjellen har definert mye av det jeg har lært siden.
Fra hobbyprosjekt til reelt ansvar
Jeg kommer fra frontend. HTML, CSS, React — det er der jeg er mest komfortabel. Men når du bygger noe som Nextbook — en læringsplattform med brukere, data og betalingsflyt — innser du raskt at frontend bare er toppen av isfjellet. Under overflaten ligger databaser, autentisering, API-design, deployment og alt det som holder systemet i live.
Jeg måtte lære mye av dette på veien. Og jeg var heldig — jeg fikk hjelp fra dyktige folk. En data engineer som forklarte meg hvorfor indeksering betyr noe. En backend-utvikler som viste meg hvorfor RLS-policyer i Supabase var bedre enn å stole på at applikasjonskoden min alltid sjekket tilganger riktig. Disse samtalene endret måten jeg tenker om systemer.
Det viktigste jeg tok med meg var ikke spesifikke tekniske løsninger. Det var en måte å tenke på: hva skjer når ting går galt?
Feilhåndtering er en tenkemåte
I et hobbyprosjekt er feilhåndtering det du legger til når noe krasjer. I et produksjonssystem er det det første du planlegger for.
Brukere gjør ting du aldri forventet. De klikker på knapper to ganger. De mister nettverksforbindelsen midt i en operasjon. De sender inn data du aldri hadde tenkt var mulig. Tredjepartstjenester går ned uten forvarsel.
Det var en backend-utvikler som sa noe som festet seg: «Ikke planlegg for at ting fungerer. Planlegg for at alt feiler, og gjør det enkelt å finne ut hva som gikk galt.» Det endret perspektivet mitt. Nå tenker jeg alltid: hva skjer hvis dette kallet feiler? Hva ser brukeren? Hva ser jeg i loggene?
Logging er mer enn console.log
I starten logget jeg feil. Bare feil. Når noe krasjet klokken to om natten, stod jeg igjen med en feilmelding som sa «Something went wrong» og ingen kontekst.
Nå logger jeg annerledes. Hvem var brukeren? Hva prøvde de å gjøre? Hvilken tilstand var systemet i? Hvilke verdier ble sendt inn? Ikke fordi jeg liker verbose logger, men fordi kontekst er forskjellen mellom å finne feilen på fem minutter og å lete i flere timer.
Det er en ting jeg lærte av å faktisk drifte et system med ekte brukere. Du kan ikke spørre brukeren hva de gjorde — du må ha loggene som forteller deg det.
Sikkerhet er ikke noe du legger til senere
Det er fristende å tenke «jeg fikser sikkerheten etterpå». Problemet er at «etterpå» aldri kommer — det er bare «for sent».
Jeg lærte dette den harde veien. Tidlig i Nextbook hadde jeg API-ruter som stolte på at frontend sendte riktige bruker-IDer. En enkel fetch med en annen ID i request body, og du kunne se andres data. Det var aldri et reelt problem fordi ingen oppdaget det — men da jeg forstod hva som var mulig, ble det en vekker.
Nå bruker jeg RLS i Supabase som et siste forsvarsverk. Selv om applikasjonskoden min har en bug, returnerer databasen bare data brukeren har lov til å se. Det er den typen forsvar-i-dybden-tenkning jeg har lært å verdsette.
Hva systemtenkning betyr for meg
Jeg er ikke den utvikleren som har skrevet tusenvis av linjer med backend-kode. Min styrke ligger et annet sted: jeg forstår hvordan delene henger sammen. Hvordan frontend snakker med API-et, hvordan API-et snakker med databasen, hvorfor autentisering bør håndteres på et bestemt lag, og hva konsekvensene er av å ta snarveier.
Den forståelsen kom ikke fra å lese dokumentasjon. Den kom fra å gjøre feil i produksjon, fra å samarbeide med folk som kunne mer enn meg, og fra å tvinge meg selv til å forstå hele stacken — ikke bare den delen jeg var komfortabel med.
Det jeg tar med meg
Produksjonssystemer lærer deg ydmykhet. De viser deg at koden din er en liten del av et større system, og at det systemet må fungere for ekte mennesker med ekte behov.
De viktigste leksjonene er ikke tekniske:
- Planlegg for feil, ikke bare for suksess. Hva skjer når nettverket feiler? Når databasen er treg? Når brukeren gjør noe uventet?
- Kontekst i logger redder deg. Ikke bare logg at noe feilet — logg nok til å forstå hvorfor.
- Sikkerhet fra dag én. Det koster nesten ingenting å gjøre det riktig fra starten. Det koster enormt å fikse det etterpå.
- Spør folk som kan mer. De viktigste tingene jeg har lært om produksjonssystemer, lærte jeg fra utviklere som hadde gjort det lenger enn meg.
Jeg bygger fortsatt. Jeg lærer fortsatt. Men forskjellen mellom meg nå og meg for noen år siden er at jeg nå forstår hva jeg ikke visste — og det er kanskje den viktigste ferdigheten av alle.