Ble hacket som 12-åring: – Har blitt den strenge på teamet

Hvorfor ble du utvikler? 👶

Min reise som utvikler startet som “webmaster” for en Habbo Hotel-fanside i 2009. 

Jeg var 12 år, og hadde ikke egentlig særlig peiling på hva jeg drev med. Jeg visste ikke noe om hva innrykk eller “clean code” innebar, men jeg fant ut at jeg hadde lyst til å lage en nettside hvor man kunne lage seg bruker og logge inn, skrive i gjestebok, publisere nyheter om og diskutere Habbo, samt tjene “poeng” for å være aktiv på fansiden. 

Jeg var inne i fasen som mange tenåringsgutter går gjennom, hvor man satt på rommet og glanet på PC-skjermen dagen lang, så det var mye tid til å fordype seg på internett. Jeg var utrolig fascinert av hva som var mulig å få til med PHP, HTML og CSS, selv om jeg på det tidspunktet ikke akkurat forstod veldig godt hvorfor ting fungerte.

Noe av det jeg husker best fra denne tiden er en del… sikkerhetshull som ble oppdaget på nettsiden av andre med samme interesse for programmering i Habbo-miljøet. Jeg visste jo tross alt ikke egentlig hva jeg drev med og var derfor ikke helt stueren med sikkerheten, og det endte opp med at nettsiden ble utnyttet med blant annet SQL Injections og XSS-angrep. Selv om jeg faktisk tross alt hadde hashet passordene i brukerdatabasen og de ikke fikk tak i selve passordene i seg selv, så benyttet hackerne seg av såkalte rainbow tables for å finne klartekstformen av passordhashene. 

Jeg skjønte jo selvfølgelig ikke på det tidspunktet at MD5 ikke akkurat var vanntett å bruke for hashing av passord. Det hjalp jo heller ikke at flere av brukerne på denne fansiden også brukte samme brukernavn og passord på selve Habbo Hotel-spillet, som var basert på å bruke ekte penger for å tilegne seg digital valuta og møbler... Det var nok en del som innså fordelen av å bruke unike passord på forskjellige nettsider i etterkant.

Denne erfaringen har satt spor, og jeg har fortsatt en sterk interesse for sikkerhet, selv om jeg ikke nødvendigvis jobber med det som spesialist. Jeg har nok en tendens til å være den litt strenge på teamet når det kommer til sikkerhet og tilgangskontroll, nettopp fordi jeg har sett hvor galt det kan gå om man ikke gjør det riktig fra start.

Driften av nettsiden tok opp litt for mye av fritiden etterhvert, så vi la den til slutt ned, og etter det var jeg ikke like aktiv innen programmering. Men tidvis lagde jeg litt hjemmelagde “mods” til Minecraft, spill i flash ol. Et frø var uansett sådd og det ble naturlig for meg å studere og etterhvert jobbe med det som har vært en av mine favoritthobbyer gjennom oppveksten.

Hva jobber du med? 💪

Som Data Engineer i Cognite jobber jeg hovedsakelig med vårt hovedprodukt, Cognite Data Fusion (CDF). Dette er en DataOps-plattform myntet på industribedrifter.

Vi satser tungt innenfor industrielle AI-agenter, og i sommer jobber jeg med datamodellering og implementering av agenter for flere av våre kunder i Japan.

Generelt jobber jeg tett på kundene, og hjelper dem med å lage integrasjoner mot våre API-er og andre løsninger som er spesialisert for deres bruksområder. Til dette så benytter jeg meg i hovedsak av Python, samt SparkSQL og GraphQL. 

Men som alle konsulenter er kjent med så er jo noe av det viktigste å kunne tilpasse seg hva kundene har behov for og/eller bruker fra før, så det blir også en del arbeid opp mot Azure Data Factory, Kubernetes, Java, mm.

Et av våre verktøy som jeg liker veldig godt og har jobbet mye med å implementere i år er Industrial Canvas. 

Dette er et slags digitalt whiteboard som lar deg hente inn og visualisere relasjoner mellom alle mulige typer data, som 3D-modeller, PDFer, tidsserie-data og annen metadata. Dette lar ingeniører og andre domeneeksperter gå rett inn og se på helheten av relevant data for å gjøre blant annet avansert feilsøking og planlegging av vedlikehold på utstyr.

Hvordan ser uka ut for deg? 📆

Siden jeg jobber mye opp mot kunder så blir arbeidsdagen veldig forskjellig fra dag til dag. Men en gjenganger er at vi har standups noen ganger i uka, en del 1-1 syncer, og ellers jobber vi mye asynkront. Som regel tilbringer jeg 3 dager i uka ute på kontorene våre på Fornebu, og resterende på hjemmekontor. 

Kundene og kollegaene mine sitter ofte på helt andre steder på jordkloden, så da er det greit å ha et par dager hjemme for å kunne ta unna en del videomøter, samt å sette av tid til å konsentrere seg skikkelig, spesielt når det er litt vanskelig med tidssoneforskjell og man noen ganger må ta et møte litt tidlig på morgenen eller på ettermiddagen. I tillegg har vi fått en kattunge i vår, så da har det vært praktisk å kunne være litt hjemme og passe på den på hjemmekontor.

Ettersom jeg har en del videomøter så anser jeg meg selv som veldig heldig med at vi som regel benytter oss i hovedsak av Slack. Jeg kjenner nemlig på vesentlig mindre stressnivå av ringelyden for Huddles på Slack sammenlignet med den i Microsoft Teams!

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

Fremover er målet å bli enda bedre på å ta i bruk nye og mer avanserte agentiske verktøy, jeg har nemlig for det meste klart meg med Github Copilot så langt.

 Målet er å prøve å ta i bruk Cursor etterhvert, og se om det blir noe forbedring i produktiviteten.

Ellers på privaten så går det mye i sykkel om dagen. Her er målet å få forbedret kondisen litt, så jeg klarer å henge med de andre medsyklistene i oppoverbakkene. Jeg håper også at jeg kan få til min første lengre sammenhengende tur på 100 km i sommer.

Hva synes du er mest krevende ved å være utvikler? 👀

Jeg synes noe av det mest krevende som utvikler er å holde seg oppdatert på og teste ut ny teknologi når det introduseres nye konsepter hele tiden. 

Selv droppet jeg av sporet som frontend-utvikler fordi jeg opplevde at nye rammeverk dukket opp hver dag, som alle skulle revolusjonere bransjen. Jeg opplevde nok rett og slett det de kaller “frontend fatigue”. 

Jeg synes man kan se litt lignende tendenser innenfor AI, hvor det til stadighet er et nytt verktøy man “må” bruke for å ikke “havne bakpå”. Men jeg prøver likevel nå å ha et positivt mindset om at jeg må prøve å finne måter å la AI effektivisere og automatisere bort det som er mer tungvint og repetitivt med jobben, og samtidig bruke det til å akselerere min egen forståelse for de mer komplekse og (og gjerne mer givende) arbeidsoppgavene.

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

Det blir jo nesten teit å nevne AI igjen siden de fleste andre også har tatt opp dette i denne spalten. 

Men noe jeg synes er et veldig interessant og komplekst aspekt ved LLM-er er den ujevne belastningen det medfører på strømnettet og den generelle samfunnsmessige kostnaden av å trene og gjøre kall til modellen.

Wendover Productions på Youtube hadde en veldig interessant video om dette temaet. Han går blant annet i dybden om hvordan strømnettet krever fullstendig balanse mellom produksjon og forbruk, men at eksempelvis trening av LLM-er fører til enorme fluktuasjoner i forbruk. Dette er belastende både for infrastrukturen og utstyr som er koblet til strømnettet. Atpåtil er det spesielt vanskelig å møte såpass fluktuerende forbruk med fornybar energi som vind- og solkraft, ettersom vi ikke kan kontrollere været og ikke enkelt kan skru opp eller ned strømproduksjonen med disse på kort sikt.

Et annet interessant aspekt er jo at mange er blitt godt vante med å svare høflig til AI. Sam Altman uttalte nylig at menneskers høflighet koster de flere titalls millioner dollar. Den pengemessige kostnaden for OpenAI er jo én ting, men enda viktigere er det jo at det kan oversettes til en kostnad i form av sårt trengte energiressurser.

Jeg tror derfor det vil bli veldig interessant å se fremover om det vil bli økt fokus på å prøve å minimere antall tokens når man gjør kall. 

Per nå føler jeg at man kanskje er i en fase hvor man prøver å få inn så mye som mulig kontekst for å maksimere ytelsen og presisjonen på svarene. Kanskje vil man se at dette ikke nødvendigvis er bærekraftig i lengden, og at man må være mer nøye med ressursbruken.

Motstykket til dette er jo at man faktisk også ofte observerer at svarene man får kan bli bedre av å spe på med litt høflighet, så kanskje er det verdt det likevel i en del tilfeller? Med kode så er det jo relativt enkelt å gjøre statiske analyser av plass- og tidskompleksitet for å se hvilken påvirkning løkker og datastrukturer man bruker har. Men jeg oppfatter det ikke som like enkelt å forstå (enda i hvert fall) hvor mye påvirkning en ekstra presisering av typen “You must absolutely never ever do X” i et prompt har på presisjonen til svarene man får.

Hva er ditt beste tips til andre utviklere? 🤖

Jeg tror det er viktig å alltid ha i bakhodet at koden man skriver skal kunne vedlikeholdes og videreutvikles av andre. 

Jeg har sett mange eksempler på at noen skal ta over en kodebase hvor noen (gjerne en enkeltutvikler / konsulent) har brukt et eller annet programmeringsspråk som kun et fåtall av utviklere har erfaring med. Eller kanskje de i praksis har laget sitt eget rammeverk for å løse et problem som allerede er løst av andre open source-pakker. 

Andre ganger har de brukt avanserte og uvanlige programmeringsmønstre som de selv synes er subjektivt bedre. Resultatet er jo ofte at man må skrive om store mengder av koden for å gjøre det enklere å vedlikeholde når noen skal overta det. Selv Python, som gjerne regnes som veldig enkelt, har mange programmeringsmønstre som kan gjøre koden mindre lesbar. 

Så jeg prøver selv å unngå å bruke for mye list comprehensions og lignende, siden det ofte fører til kode som er vanskeligere å sette seg inn i og vedlikeholde, selv om den jo kanskje kan se mer “elegant” ut.

Jeg tror det er veldig viktig å huske på at det enkle er faktisk ofte det beste, og du vil alltid være på nåværende prosjekt i en begrenset periode. Man kan ikke regne med at arbeidsgiveren / kunden din har anledning til å ansette noen som har akkurat det ferdighetsnivået eller akkurat din ekspertise i etterkant.

Om du ser at det kan være relevant å introdusere et litt mer uvanlig programmeringsspråk, for eksempel Go, til en ny integrasjon, kanskje det er lurt å først spørre seg selv om det faktisk er strengt tatt nødvendig? Mitt inntrykk er at veldig mye lar seg løse med litt god gammeldags Python, Postgres og React, og det er gjerne teknologier veldig mange har erfaring med.

Bytta butikkjobb med kodejobb: «God timing»

Etter et tiår i butikk begynte Ukas koder Børge Mastberg å studere utvikling. Og han hadde flaks med jobbmarkedet.