Reagerer på «feature pushing» og «codemonkey»-kultur

- Man får masse ros for at man har utviklet noe kjapt, men bak kulissene så er det masse teknisk gjeld, sier Ukas Koder Dean Demetria, og etterlyser bærekraftig utvikling.

Den erfarne frontendutvikleren Dean Demetria synes koding er kjempegøy, men med egen leilighet våknet interessen for noe helt annet; interiør og interørdesign. 📸: Privat
Den erfarne frontendutvikleren Dean Demetria synes koding er kjempegøy, men med egen leilighet våknet interessen for noe helt annet; interiør og interørdesign. 📸: Privat Vis mer

Hvorfor ble du utvikler? 👶

På Filippinene tok jeg min bachelor i Multimedia Arts and Design og hadde noen fag innen webdesign og programmering. Vi ble lært basic HTML, CSS og PHP og hvordan man skal designe ett nettsted som var aktuelt i den tida (ca 2008).

Her ble jeg fascinert av hvordan mine designskisser, som da var lagd i Adobe Photoshop CS3, ble til et interaktivt grensesnitt. Det var her jeg lærte hvordan man “googler seg frem” til alle mulige løsninger som finnes på Stack Overflow, til og med kopiere masse jQuery-snippets som ikke fungerte i det hele tatt, men lot være i koden. “Det her er så sykt gøy!” tenkte jeg den tida.

Dessverre så ble jeg oppslukt med en annen interesse, som er film og video. Da jeg ble ferdig utdannet så jobbet jeg som videoredigerer og animatør.

«Etter 12 år er det fortsatt fantastisk å være utvikler; å kunne skape noe sammen med kollegaer som vanligvis ble til venner.»

Men da jeg flyttet til Norge i 2012 ble det en mulighet for meg å jobbe med programmering igjen. Heldigvis fikk jeg en sjanse og startet utvikler-karrieren min som webdesigner og -utvikler; det vil si at jeg lagde nettsteder helt fra scratch. Stort sett alene får man et prosjekt der man jobbet med prosjektledelse, logodesign, webdesign, innholdsarkitektur, UX, HTML, vanilla CSS, og CMS-integrasjon – alt på ca 20-50 timer.

Det var her jeg virkelig lærte mye om hele arbeidsprosessen, og selv om det var mye “context switching” så var det her vi ble kreative og lagde systemer og prosesser som gjorde at vi kunne fokusere på de tingene vi jobbet med akkurat der og da (takk Emil!).

Siden da har det egentlig bare vært en reise med å jobbe på forskjellige steder og se hvordan landskapet i industrien har endret seg; det å skille frontend fra backend, universell utforming, jobb som både konsulent og in-house, se hvordan tech oppdaterer seg og hvordan utviklere hopper inn i nye ting, scrum vs. kanban vs. agile, misbruk av fail fast, og ikke minst møte fantastiske og dyktige kollegaer.

Etter 12 år gjennom alt det der er det fortsatt fantastisk å være utvikler; å kunne skape noe sammen med kollegaer som vanligvis ble til venner.

Hva jobber du med? 💪

Jeg har nå nylig startet i ny jobb hos Distribution Innovation som Lead Frontend Developer.

Sammen med en annen lead frontend-utvikler jobber vi med å bygge opp frontend-stacken, sette noen tech-standarder, og gjøre det lett for andre utviklere å lage nye løsninger i Distribution Innovation. I tillegg så kartlegger vi behovet til selskapet; det vil si hva slags tech vi bør se på og hvordan skal vi strukturere kodebasene våres slik at det blir lett nok å hoppe fra et prosjekt til et annet.

Vi prøver også å lage en plan på hvordan alle som jobber med frontend kan samarbeide bedre slik at vi kan holde kodebasene våres up-to-date og up-to-standard.

Jeg har også en stor interesse for universell utforming og har da fått æren av å bli med på å snakke om det.

Arbeidsredskapen er en MacBook M3. 📸: Privat
Arbeidsredskapen er en MacBook M3. 📸: Privat Vis mer

Hvordan ser uka ut for deg? 📆

Jeg er en av dem som liker å være på kontoret siden jeg foretrekker den “context switch”-en mellom hjem og arbeid. Samtidig er det ganske kjekt å kunne raskere bli kjent med kollegaene mine, spesielt i ny jobb.

Vi har et Daily Standup-møte som virkelig funker som et standup-møtet; det varer ikke mer enn 15 minutter (og det er delt på 2 team).

Under korona-årene så tror jeg at folk bare brukte standup som sync-møter og vanligvis varer ca 1 time, men jeg tror at hos Distribution Innovation har de god kontroll på hvordan det skal være; “Hva gjør du? Trenger du hjelp? Neste person.” Hvis det er noe annet som må diskuteres skjer det utenfor Standup-møtet.

Akkurat nå så er det mye undersøking, proof-of-concepts, kartlegging, planlegging, og future-proofing for å kunne gjøre hverdagen våres lettere når vi faktisk kommer inn i produktutvikling. Jeg synes at det er veldig givende å kunne diskutere frontend-teknologi og å kunne bli med på å bygge kompetansen på huset.

Hva er det neste du har lyst til å lære deg eller bli bedre på? 🧠

Jeg har fått en stor interesse for interiør nå nylig etter å ha flyttet inn til mitt eget space og har da lyst å bli bedre på hvordan jeg kan få det maks fint hjemme.

Jeg har blitt veldig gira på å lage egne møbler også, men jeg kunne ikke snekret eller begynt med noe DIY for å redde livet mitt, så håper at jeg kunne få litt tid på å finne ut av hvor man skal begynne.

Det hadde vært nydelig å kunne lage noe fint hjemme; en stol eller et skap lagd av tre, for eksempel. Noe a la Carl Hansen eller Frederica. Evt. bare bli rik nok til å kunne kjøpe en Eames-stol, men det blir nok en annen gang.

Interessen for interiør er så stor at Dean har lyst til å prøve seg som møbelsnekker innimellom all programmeringen. 📸: Privat
Interessen for interiør er så stor at Dean har lyst til å prøve seg som møbelsnekker innimellom all programmeringen. 📸: Privat Vis mer

Innen programmering så har jeg begynt å se litt mer på Rust siden det virker ganske spennende. Jeg liker spesielt tankegangen med “borrowing”, men må innrømme at jeg ikke har kommet så langt enda.

Jeg har også sett på XState, som er et state machine bibliotek som jeg synes funker ganske bra. Det har også en visualisation-verktøy som gjør at det er lettere å forklare til andre «ikke-teknologere» hvordan flyten funker, evt. hva som må fikses. Det har jeg eksperimentert med litt for å håndtere et kompleks søknadsskjema og jeg mener at det funker ganske bra.

Hva er den mest utfordrende situasjonen du har stått i? 👀

Det som jeg synes er krevende som frontendutvikler som har stor interesse for universell utforming (UU) er å få folk til å prioritere universell utforming.

For de som ikke vet, UU gjelder absolutt alle; du som kanskje foretrekker dark mode over light mode, du som har alt for mye sollys som treffer skjermen, du som muligens trenger briller, eller du som er fargeblind.

«Som frontend-utvikler mener jeg at vi bør kunne lage løsninger som alle kan bruke, uavhengig av lovverket og målgruppen.»

Som frontend-utvikler mener jeg at vi bør kunne lage løsninger som alle kan bruke, uavhengig av lovverket og målgruppen.

Det jeg har opplevd er at initiativet for UU kommer fra designere, men det er jo frontend-utviklere som implementerer løsningene; dette er tross alt et samarbeid. Det jeg håper er at vi kan øke UU-kompetansen generelt blant frontend-utviklere, og å få selskaper å forstå at UU er viktig, uansett om lovverket dekker løsningene eller ikke; det handler om hvem som bruker løsningene uansett.

Hva ser du på som bransjens største utfordring akkurat nå? 🤖

Bærekrafig utvikling – nei, jeg snakker ikke om hvor mye strøm et dataspråk bruker, men det med å ha kodebaser som er skalerbare. Jeg mener at dette skyldes "feature-pushing"; å ikke ha nok tid eller retrospekt på hvordan koden kan forbedres.

Fra det jeg har sett når det kommer inn lovende og dyktige folk som er ivrige på å lære og lage nye ting, men når arbeidskulturen er å bare pushe ut nye ting hele tiden, så blir selve evnen til å bli bedre borte; da er vi tilbake til codemonkey-kulturen.

«Da er vi tilbake til codemonkey-kulturen.»

Man får masse ros på at man har utviklet noe kjapt, at selskapet har nådd et mål, men bak kulissene så er det kode som har fått masse “accidental complexity” og teknisk gjeld. Det jeg synes er vanskelig i tech-bransjen er at teknisk gjeld vanligvis ikke har en nedbetalingsplan etter at en feature er lansert.

Det blir jo enda tydeligere når man må lage nye features på toppen av den som allerede har blitt lagd, og da blir det vanskeligere og vanskeligere å fikse.

Det som hadde vært idéelt er å faktisk inkludere teknologer når man ser på hovedstrategien til selskapet, spesielt når man jobber med tech.

Hva er ditt beste tips til andre utviklere? 💡

Når det gjelder valget av tech, tenk alltid futureproof.

Det finnes ikke tech som er 100% futureproof, men det finnes måter å lage en kodebase futureproof nok slik at det er lett å erstatte teknologien som ble brukt.

Jeg har opplevd at vanligvis følger man et mønster som et bibliotek foreslår som gjør at kodebasen står fast når biblioteket plutselig må erstattes på grunn av enten sikkerhet eller noe.

Det å være kritisk til teknologien og hvordan den påvirker videreutvikling senere, spesielt når det kommer nye utviklere inn i kodebasen. Det kommer sikkert en bedre måte å gjøre ting på senere, og det kommer alltid nye utviklere som kan forbedre kodebasen (eller gjør det verre, men jeg vil gjerne være optimistisk).