Jeg pleide å tenke at alt viktig skjedde på serveren. At god arkitektur, rene API-er, stabile tjenester var selve kjernen i god utviklingsarbeid. Backend var et sted jeg følte kontroll. Det var logisk, strukturert og trygt.

Men etter hvert som jeg fikk mer ansvar og begynte jobbe tettere med designere, produkteiere og sluttbrukere, endret perspektivet seg. Jeg begynte å se at kode alene, i seg selv ikke skaper verdi. Det er helheten som gjør det.

Tryggheten i backend

‍
Jeg startet karrieren min som backend-utvikler. Det var alt jeg ønsket å bli etter studietiden min. Jeg digget det! Det var noe tilfredsstillende med å bygge robuste systemer, som bare fungerte! Jeg likte tydeligheten. Det var input, prosesser og output. Det kunne testes, valideres og dokumenteres. Man kunne se resultatet av det man bygget gjennom stabilitet og ytelse.

Jeg ble fascinert av hvordan arkitektur kunne løse komplekse problemer. Du har arkitekturer som CQRS (Command, Query, Responsibility, Segregation), Event-drevet arkitektur og REST. Det var domene modellering. Det var noe spesielt og ikke minst gøy å kunne jobbe med strukturen. Man begynte å se skjønnheten ved det.

Men samtidig begynte jeg å merke at man i noen tilfeller bygget noe man ikke helt forsto. Jeg begynte å innse at kode kan være feilfri og likevel uten verdi. At det som virkelig teller, er hva koden betyr for noen og i noen tilfeller glemme å stille spørsmål på hvorfor vi skal gjøre disse features.
‍

Helheten i det å utvikle

‍
Jeg har hatt muligheten til å jobbe på ulike prosjekter. Prosjekter i offentlig og i den private sektoren. Domenere fra shipping, salg av boliger til telekom. Sluttbrukere har vært alt i fra teknisk til ikke tekniske.

Sakte men sikkert legger jeg merke til at det ikke bare handler om teknologi, men om mennesker, prosesser og valg som påvirker brukerne direkte. Vi innser hvor lite det virker for oss som utviklere — et kopieringsknapp, en feilmelding, lastetid, som kan ha stor betydning for andre.

Det er slike situasjoner jeg innser at arkitektur, database og grensesnitt egentlig ikke er separate verdener. De er deler av den samme bildet, produktets utvikling. Vi glemmer at vi utviklere er med på den reisen fra idé til virkeligheten. Derfor er det viktig at vi tar en større rolle i denne reisen. Begi oss ut på brukertesting, skyggeing. Slik at vi får en bedre forståelse på hva vi utvikler.

Når vi ser det store bildet, tar vi også større eierskap til det vi bygger. Vi blir ikke bare en typisk code monkey som bare utfører oppgaver, men en medskaper av produkter. Vi begynner å se sammenhengen mellom kodelinjer og verdien de skaper. Da handler det ikke lenger bare om hva som fungerer, men hva betyr det for de som bruker det.

‍

Å være utvikler - ikke backend og frontend
‍

I dag deler vi ofte utvikling opp i backend og frontend. Rollene er nyttige, men de kan også skjule det viktigste: at vi egentlig jobber mot samme mål.

Etter mine år som utvikler har jeg begynt å se på disse rollene på en annerledes måte. Jeg betegner det som utvikler. Vi har et felles ansvar om å jobbe med hele stacken og være med på å utvikle produktet og ta del av hele reisen. Dette betyr at vi utviklere tar initiativet til å være med i brukertesting og ikke minst bli kjent med våre brukere. Vi er ikke bare backendere, frontendere eller fullstackere. Vi er utviklere. Vi er de folka som bygger løsningen og ikke bare kode. Vi tar ansvar for hele verdikjeden: fra Idé og behov, til vedlikehold og brukeropplevelse.

‍
Det å være en utvikler handler nettopp om dette. Å bry seg om hele reisen. Om å forstå hvorfor noe bygges, hvordan det brukes og hva som skjer etter at det er levert.

Jeg tenker ofte det å være en utvikler egentlig handler om å bygge bro mellom mennesker, systemer og behov. Selv om jeg i dag anser meg selv som en utvikler så har jeg fortsatt hjertet mitt i backend. Det er der jeg ofte finner roen i logikken og strukturen.

Men med tiden har jeg lært at utvikling handler mer enn det. Det handler om å forstå helheten. Brukerne, prosessene og behovene bak. Det har gitt meg et større eierskap og en ny forståelse for hva det betyr å være utvikler.

Kanskje det er det som skiller god kode og god utvikling. Den ene fungerer mens den andre betyr noe.

‍