Jeg jobber for det meste alene. Det betyr at jeg ikke bare skriver kode — jeg tar beslutninger. Hvilken teknologi skal brukes? Hvordan skal systemet struktureres? Hva prioriteres når tiden er knapp? Og de beslutningene er ikke bare tekniske. De handler om mennesker, om trade-offs, og om å forstå konsekvensene av valgene du tar.
Det har tvunget meg til å tenke bredere enn bare kode.
Brukere er ikke rasjonelle maskiner
Noe av det viktigste jeg har lært, har ingenting med programmering å gjøre. Det handler om hvordan mennesker faktisk bruker ting.
Folk leser ikke instruksjoner. De klikker på det som ser klikkbart ut. De gir opp etter tre sekunder med loading. De blir frustrerte av feilmeldinger som sier «noe gikk galt» uten å si hva de kan gjøre med det.
Denne innsikten har endret hvordan jeg bygger brukergrensesnitt. Feilmeldinger i Nextbook sier ikke bare hva som feilet — de sier hva brukeren kan gjøre nå. Onboarding-flyten er designet for å minimere beslutninger, fordi hver beslutning er et punkt der noen kan gi opp. Layouten er bygget rundt det brukeren trenger akkurat nå, ikke alt de kanskje trenger.
Det er ikke avansert psykologi. Det er bare å ta seg tid til å tenke på mennesket på andre siden av skjermen.
Arkitekturbeslutninger er verdivalg
Når jeg velger mellom Supabase og en egenbygd backend, tar jeg ikke bare en teknisk beslutning. Jeg velger hvor mye tid jeg investerer i infrastruktur versus produktutvikling. Jeg velger hvilken type risiko jeg aksepterer — vendor lock-in mot vedlikeholdsbyrde. Jeg velger hva som er viktigst akkurat nå for prosjektet og brukerne.
Det samme gjelder for mindre valg. Bruker jeg server-side rendering eller statisk generering? Det handler ikke bare om ytelse — det handler om hva brukerne trenger. Trenger de alltid fersk data? Eller er en side som laster på 200ms viktigere enn data som er fem minutter gammel?
Disse avveiningene har aldri et objektivt riktig svar. De krever kontekst, dømmekraft, og viljen til å innrømme at du velger noe bort hver gang du velger noe annet.
Å jobbe alene tvinger deg til å se hele bildet
Når du er i et team, kan du spesialisere deg. Frontend-utvikleren tenker på UI, backend-utvikleren tenker på API-et, DevOps-ingeniøren tenker på deployment. Ansvaret er fordelt.
Når du jobber alene, er hele ansvaret ditt. Det betyr at du må forstå nok av alt til å ta fornuftige beslutninger — selv i områder der du ikke er ekspert.
For meg har det betydd å lære meg nok om databaser til å forstå hvorfor indeksering betyr noe. Nok om sikkerhet til å vite når RLS er riktig valg. Nok om DevOps til å sette opp en CI/CD-pipeline som faktisk fungerer. Ikke nok til å kalle meg spesialist i noe av det — men nok til å forstå helheten.
Den bredden er verdifull. Ikke fordi jeg gjør alt selv — jeg spør folk som kan mer når det trengs — men fordi jeg kan stille de riktige spørsmålene og forstå svarene.
Trade-offs som etikk
Hver teknisk avveining har konsekvenser for mennesker. Velger du raskere utvikling over tilgjengelighet? Da er det noen som ikke kan bruke produktet ditt. Velger du billigere infrastruktur over responstid? Da er det noen som venter lenger. Velger du å utsette sikkerhet? Da er det noen sine data som er mer utsatt.
Det er lett å tenke at disse valgene bare er tekniske. Men de handler om hvem du prioriterer og hva du er villig til å akseptere.
Jeg har ikke alltid tatt de riktige valgene. Noen ganger har jeg valgt hastighet over kvalitet og betalt for det etterpå. Andre ganger har jeg overengineered en løsning som ingen trengte. Poenget er ikke å alltid velge riktig — det er å være bevisst på at du velger.
Den beste versjonen av meg som utvikler
Den beste versjonen av meg som utvikler er ikke den som kan flest frameworks eller skriver kode raskest. Det er den som stopper opp og spør: hva prøver vi egentlig å løse? Hvem er dette for? Hva er konsekvensene av dette valget?
Teknologi er et verktøy. Filosofi er å vite hva du bygger med det — og hvorfor.