Mikroblogg, side 8

Hvordan blir man en god frontendutvikler?

Jeg har tenkt at jeg burde skrive litt om dette en stund, men først i dag kom jeg i en skikkelig tankespiral om temaet da jeg satt og fylte ut en kompetansematrise på jobb. Vi bruker mye energi på å definere hva en god frontendutvikler er, men veldig ofte handler det om rammeverk og verktøy og hvor lenge man har brukt nevnte rammeverk og verktøy. Om det er en god målenhet for hva en god frontendutvikler er, vet jeg ikke. Men jeg tror ikke det.

Det siste året har jeg jobbet med å finne min ikigai. Det er et japansk begrep som definerer ens hensikt her i livet, skjæringspunktet mellom fire ting: det man elsker, det man er god på, det verden trenger fra en, og det man kan leve av. Jo lenger jeg jobber som frontendutvikler, jo mer innser jeg at min ikigai er å jobbe med designsystemer og universell utforming - en grensesnittspesialist, for å kalle det det. Men vi kaller det frontendutvikling allikevel, for det er enkelt å forstå i en teknologihverdag.

Så hva gjør meg egentlig til en god frontendutvikler? Jeg har fundert på det, og landet på ti sentrale ting jeg synes definerer en god frontendutvikler. Ti bud, om du vil. Konseptet med bud og leveregler er enkelt å forstå, så derfor vil jeg snakke om mine personlige ti bud når det gjelder fagområdet mitt.

Merk at dette er mine ti bud. Dine ti bud, eller noen andre sine ti bud, kan være helt forskjellige. Det er lov å synes at mine bud er dumme og verdiløse, om du har andre bud som gir mening for deg selv. Men min ikigaisom frontendutvikler sentrerer seg rundt følgende enkle leveregler:

1: La teknologien gjøre de tunge løftene for deg.

Webteknologi har kommet langt de siste årene, og vi får flere og flere nyvinninger nå som browsere blir mer evergreen. HTML har fått et vell av semantiske tagger, av nyere tid et dedikert <dialog>-element til å lage modaler med. Vi har CSS grid, variabler, container queries og :has()-selektoren på stylingsiden. JavaScript modnes i et forbløffende tempo med ES-moduler og top-level async/await og andre features vi bare kunne drømme om tidligere. På tilgjengelighetsfronten blir det stadig lettere å lage løsninger som kan brukes av alle. Skriver du semantisk HTML, har du kommet langt på vei. Kjenner du til aria-attributter og hvordan de skal brukes, er det stadig vanskeligere å lage noe som ikke er universelt utformet.

Dessverre kaster vi altfor ofte disse verktøyene til side. Vi implementerer egne valideringsløsninger, enda HTML5 sin constraint validation fungerer utmerket i veldig mange tilfeller. Vi lager egne nedtrekksbokser, enda vi vet med sikkerhet at en native <select> fungerer mye bedre. Vi surrer med tullete spesialdesignede løsninger når vi ikke må. Og det må vi stoppe med. Bruk webstandarder og nettleserens styrker for alt det er verdt. Ikke jobb hardere - jobb smartere.

2: Skriv alltid minst mulig kode for å komme i mål.

Frontendutvikling har en del til felles med matlaging på høyt nivå. Slår du på et program med Gordon Ramsay, kan du innen fem minutter høre ordene "clean, simple flavors" uttalt med klar og tydelig røst. Ser du på en episode av Top Chef, kommer noen til å få smekk på lanken for å bruke for mange ingredienser, for mange smaker.

Sånn er frontendutvikling også. Ikke gjør mer enn du må for å komme i mål. Skriv akkurat nok HTML til at det gir mening semantisk, og suppler med aria-attributter bare dersom du må. Skriv nok CSS til at det ser riktig ut, og ikke overstyr styling om ikke du trenger det. Aldri gjør en JavaScript-komponent mer komplisert enn du trenger. Hold deg til basics. Det er lettere å utvide om det er behov senere, enn det er å skalere ned når koden har blitt uhåndterlig.

3: Kjenn dine nærmeste, og gjør deg kjent for dem.

For at en frontendløsning skal være god, må landskapet rundt ligge til rette for det også. Designere må forstå hvordan en nettleser fungerer slik at de kan lage layouts og komponenter som lar seg implementere uten magi og hacks. Backendutviklere må forstå hvordan en frontend kommuniserer gjennom APIer og asynkrone handlinger slik at de kan lage tjenester som lar seg konsumere enkelt. Produkteiere og prosjektledere må forstå hva som tar tid og hva som er enkelt å gjennomføre slik at de kan få forutsigbarhet i sin hverdag.

Men vi som frontendere må også forstå designerene, backendutviklerne og prosjektlederene. Det er en øvelse som går to veier, og som man kan og bør avsette dedikert tid til. Sitt med en designer og se hvordan de jobber, og la designeren se hvordan du jobber tilbake. Sett opp parprogrammerings-sesjoner med en backendutvikler for å åpne for forståelse. Ta en kaffe med produkteieren og senk skuldrene, se dem rett i øynene, og still alle de dumme spørsmålene du har. Forvent å få det samme tilbake.

4: Ikke ekskluder andre, men inkluder dem på rett vis.

Lag aldri tjenester som ikke er tilgjengelige for alle typer brukere. Men ikke forvent at alle typer brukere har godt av å benytte det samme grensesnittet på samme måte. Er en kartløsning eller en opptegnet graf det beste for en skjermleserbruker, eller bør dataene heller tilgjengeliggjøres på en annen måte, for eksempel i en utlisting med en søkefunksjon? Er undertekster i en video alltid riktig løsning, eller vil det fungere bedre med et transkript som gjør at brukeren ikke trenger å spille av videoen i det hele tatt?

Ikke tenk likhet i at alle skal bruke den samme løsningen, men heller likhet i at alle skal delta på likt grunnlag. Det kan bety at formatet noen ganger bør være annerledes.

5: Tenk forvaltning, ikke bleeding edge.

Webteknologi endrer seg i et slikt tempo at det er vanskelig å henge med. Rammeverk og verktøy kommer på løpende bånd, og reklamene skriker på fullt volum om at dette bare må du se på, ellers er du helt utafor! For bare noen små år siden var React nytt og hett. Nå er det praktisk talt en gammel traver, og nye rammeverk har kommet på løpende bånd siden det. Først var det Vue, så kom Elm, deretter Svelte, og i morgen er det sikkert noe annet.

Dette er ikke sunt for frontendutvikling som et fagfelt. Det er sunt at teknologien utvikler seg, men det er ikke sunt for oss som lever av å skrive kode og må lære oss helt nye ting annethvert år for å holde tritt. Det er ikke sunt for selskapene som bruker løsningene og sitter med teknisk gjeld til pipa fordi vi lager ting på forskjellig måte hver gang vi lager ting.

Dette er etter min mening det største "samfunnsproblemet" innen utvikling per i dag. Gammel som jeg kanskje høres ut når jeg sier det: vi må tenke forvaltning først, og utforskning etterpå. Spesielt innenfor det som er forretningskritisk. Ikke gi etter for reklamene om de skinnende nye verktøyene når de gamle fortsatt fungerer godt.

6: See one, do one, teach one.

Sitatet kommer fra Akutten og handler egentlig om medisinske prosedyrer, men det er en like god tilnærming til kode og teknologi. Skal man lære noe nytt, enten det er et kodeproblem, en komponent man skal lage, en pipeline som skal settes opp, eller hva som helst annet: se først på noen som kan gjøre det, gjør det deretter selv, og lær det bort til noen andre. Gjenta etter behov. Det er en pedagogisk måte å lære på selv, og sikrer også at andre får nyte av det du har lært.

7: Se hva som skjer.

Du vet ikke hvordan en løsning fungerer før du har sett noen bruke den for første gang. Det er derfor vi som frontendutviklere må involvere oss i brukertesting og se hvordan sluttbrukere jobber med det vi lager.

Mange synes dette egentlig er jobben til en tester, en designer, en UX-er. Og det er kanskje sant, på en måte, men det er ingen grunn til at ikke vi som jobber med koden skal se hvordan den tas i bruk i virkeligheten. Det er et godt verktøy for å oppdage bugs, og et enda bedre verktøy for å få mer kontakt med produktet, og ikke bare koden som driver produktet.

Ikke ta deg nær av det brukerene sier, eller av at det kanskje ikke funker. Det er ikke brukeren som har feil. Det er bare du som må skru om koden litt.

8: Hør hva som skjer.

De fleste brukere, og også utviklere, har et normalt fungerende syn. Derfor er det så vanskelig å forstå hvordan IT-verdenen fortoner seg for noen som ikke har det. Det er et problem, for det vi lager skal også fungere for de som ikke ser internettet - men hører det.

Derfor må vi bruke skjermlesere mer.

For mange er skjermlesere en stor, ildsprutende drage. Vi har hørt myter og sagn om hvor store og skumle og farlige de er, og hvor vanskelige og umulige de er å temme. Derfor skyr vi unna dem og dytter problemene over på andre og sier noe sånt som at "dette burde nok testes med en skjermleser men det kan ikke jeg gjøre noe med" før vi assigner saken til en stakkars UX-er i Jira.

Men skjermlesere er lavterskel. Alle får tak i en skjermleser. macOS kommer med en innebygget, og vi har dem på telefonene våre i form av VoiceOver på iOS eller Talkback på Android. Vi kan laste ned NVDA til Windows helt gratis. Det er bare programvare, og det finnes kursmateriale på nettet. Av alle hjelpemidler er dette det enkleste å få tak i; prøv bare å forestille deg hvordan det ville være å få tak i en leselist i stedet for.

Slutt å syte. Sett opp en skjermleser og begynn å leke deg rundt, så er du i gang.

9: Ikke overkompliser utviklingsmiljøet ditt.

Sist jeg så på en annen utvikler sin VS Code-installasjon, begynte jeg å kaldsvette. Vi har verktøy for absolutt alt, fra formattering av kode og linting, til sjekking av commit messages, kjøring av tester, utlisting av commit-historikk i Git... VS Code er en fantastisk editor på grunn av alt du kan gjøre med den for å sette opp et utviklingsmiljø som passer deg.

Min VS Code har et custom fargetema. That's it.

Om det er krav til kodestil og formattering, installerer jeg Prettier om jeg må. Jeg installerer også ESLint om jeg må. Men bare om jeg må. Hvorfor? Fordi det kludrer til for meg når jeg vil skrive kode på en effektiv måte, og extensions jeg har installert plutselig blander seg inn. Det skaper støy, jeg mister tråden, og jeg bruker mer tid på å ergre meg over det verktøyet som skal hjelpe meg kontra å skrive velfungerende kode.

Jeg har skjønt fra diskusjoner med andre utviklere at jeg er sær på grunn av dette. Det er greit. Så er jeg sær. Sær fungerer fint for meg, og koden jeg skriver er god uansett. Og det er dét som er det viktigste: at man har et miljø som fungerer. Bare ikke overkompliser fordi du tror du må. Det er lov å kutte ned på distraksjoner.

10: Vær tålmodig.

Dette, av alle bud, er det jeg minner meg selv på oftest.

Vi lever i en verden der teknologien går veldig fort fremover, og ofte er det en stor oppgave å sette seg inn i noe nytt. Andre skjønner seg kanskje på Remix og Astro bedre enn meg, og har skjønt at Vite er det nye hotte hva gjelder utviklingsmiljø. Jeg har ikke landet der ennå, men jeg jobber med saken. Jeg må bare være tålmodig.

Jeg kan ikke rase avgårde i prosjektet jeg sitter på fordi designdelen ikke er klar. Joda, jeg vet kanskje innerst inne hvordan det kommer til å fungere og se ut, men jeg setter meg ikke ned og begynner å kode før noe er klart allikevel. Da må jeg bare gjøre arbeid på nytt, av all høy sannsynlighet. Vær tålmodig.

Jeg har tjue tusen ting jeg må gjøre på jobb hver dag. Skrive logg, skrive timer, skrive velutformede commit messages, skrive kode som ikke brekker i vinkel om noen sitter med Internet Explorer. Tyngden av de tjue tusen tingene er voldsom, noen dager mer enn andre. Jeg kan ikke gjøre alt på en gang, og jeg må prioritere ut fra min egen tid og energi. Det er sånn det funker. Men jeg kommer over alt sammen til slutt. Bare jeg er tålmodig.

Tålmodighet er et konsept med mange fasetter. Det har seg bare sånn at tålmodighet som regel er det rette svaret uansett problem. Tålmodighet med prosessene, med andre, og aller mest seg selv.

Til slutt

Det å være en god frontendutvikler handler ikke bare om teknologi. Ofte handler det slett ikke om teknologi i det hele tatt. Men disse ti budene er det som driver min ikigai og det som holder meg i senter. Det er mange andre ting også, naturligvis, men disse er de viktigste og mest generelle. Noe er fag, noe er ikke fag. Sånn er det alltid. En annen gang skriver jeg kanskje om ti andre bud også.

(Basert på en sann historie.)

Du vet du ikke er helt korrekt skrudd sammen når hjernen din prøver å gi deg stressrelatert hjerteinfarkt 3-4 dager etter en stor greie. Underbevisstheten min må ha ett eller annet sadistisk trekk jeg undertrykker i det daglige, og når jeg sover, bestemmer den seg for å ta igjen.

Hjerne: Hei, jeg vet det er en stund siden vi hadde release og at ikke en sjel i verden har begynt å gjøre noe med denne koden ennå, men om rundt 5 minutter kommer jeg til å vekke deg med full panikk over en eller annen innbilt bug eller feature jeg tror jeg har glemt, så bare heng på, OK?

Kropp: OK, kult.

[Fem minutter senere, omtrent klokken 04:50 om morgenen]

Vegar: [Sitter opp i sengen, øynene store som middagstallerkner, tungpustet som en elg med astma]

Vegar: AAAAA PISTASJNØTTENE! JEG GLEMTE PISTASJNØTTENE!

De siste månedene har jeg jobbet med et veldig stort og veldig spennende prosjekt for et stort selskap, med mange forskjellige datasystemer og løsninger. Jeg anser meg selv som veldig heldig som har fått jobbe med noe av det jeg interesserer meg aller mest for: designsystemer.

Å lage et designsystem er en stor, fantastisk jobb. Det handler om å kombinere mange disipliner under én paraply - designprosesser, UX, programmering, kommunikasjon, samarbeid mellom team og endringer på organisasjonsnivå rullet inn i én stor bolk. Det handler ikke bare om komponentbiblioteker, men også om hvorfor vi lager dem, hvordan vi bruker dem, hvordan vi videreutvikler dem, og ikke minst at kode bare er en ørliten del av bildet.

Spesielt det tverrfaglige samarbeidet er spennende. Organisasjoner er gjerne delt opp i flere mer eller mindre organiserte bestanddeler; produktteam, avdelinger, faggrupper og seksjoner. Ikke bare er vi delt i siloer der utviklere, designere, UXere, arkitekter og prosjektledere sitter i hvert sitt fagområde der de skal ha en tilhørighet, men ofte blandes folk fra hver av disse inn i autonome, mindre team som har fullstendig ansvar for sin egen løsning.

Alle gjør ofte ting på sin måte. Det kommer an på hvem som sitter i teamene, og hvilken erfaring de har fra tidligere. Kompetansen er ofte vidt forskjellig, erfaringsnivået likeså. Metodologier blandes og måten vi jobber med løsninger på blir til slutt så forskjellig at det ene teamet aldri er det andre likt. Teknisk gjeld bygger seg opp på forskjellig måte fordi teamene må støtte forskjellige brukergrupper. Design bygges forskjellig fordi brukerene har vidt forskjellige fysiske enheter, og vidt forskjellige krav til for eksempel informasjonstetthet.

Løsningene er også mange. I en stor organisasjon kan det være titalls - hundretalls, i noen tilfeller. Ikke alle av løsningene har like stor brukerbase, men for den brukerbasen er løsningen kritisk og må fungere. De er laget på forskjellig tidspunkt, over forskjellig lest. Noen med React. Noen med Angular. Noen med JQuery i bunnen, noen uten noe JavaScript-rammeverk i det hele tatt. Noen løsninger er kun avhengige av et CMS.

Universell utforming blir stadig viktigere, også i interne systemer og fagsystemer, fordi ny lovgivning trer i kraft like over nyttår. Nå må også intranett og ekstranett være universelt utformede, og loven er streng. Avvik i løsninger må dokumenteres gjennom en tilgjengelighetserklæring. Vi kan ikke lenger trekke på skuldrene over universell utforming og si "vel, det gjelder jo ikke for oss så lenge det ikke er en publikumsløsning" sånn som vi gjorde i gamle dager. Og det er jammen på tide også.

Å jobbe med designsystemer er spennende fordi vi må hjelpe til med å løse alle disse utfordringene.

Vi må være med på å håndtere designutfordringer de ulike teamene har, uansett hvor store eller små de er, og uansett hvor liten nisjen de fyller er. Kan vi ikke hjelpe direkte, så kan vi bistå. En helhetlig brukeropplevelse krever at man ikke bare lager et fysisk produkt med tannhjul og knapper og små bestanddeler som sammen utgjør en større helhet - man må også tilby kunnskap om hvordan det skal settes sammen.

Det samme gjelder for kode, der vi skal lage noe som fungerer på tvers av løsninger, og som tilrettelegger for enkel bruk. Selv om vi ikke kan støtte alle rammeverk, teknologier og nettlesere som finnes, så kan vi lage en kodebase som åpner for videreutvikling og tilpasninger der det trengs.

Vi må også lage noe som gjør det mulig å lage tilgjengelige løsninger. Vi kan ikke garantere at løsninger vil være tilgjengelige bare fordi designsystemet vårt er det, og fordi komponentene våre møter WCAG 2.1. Så fort komponentene brukes i en kontekst, er det konteksten som må være universelt utformet. Men vi må bidra til å komme dit.

Stikkordet er tilrettelegging. Designsystemer handler om å tilrettelegge for å bygge gode løsninger i organisasjoner med mange forskjellige mennesker, løsninger, brukere og behov. Designsystemer er en tverrfaglig øvelse som handler om identitet, avsender, språk, form og farge, teknologi, tilgjengelighet, og så utrolig mye mer om hverandre.

I dag kunngjorde vi versjon 1.0.0 av designsystemet jeg har vært med på å bygge helt fra scratch, den aller første helt stabile versjonen. Reisen har vært lang, og den er langt fra over. For designsystemer er levende, pustende entiteter som må jobbes med og holdes ved like over tid om man skal ha noen nytte av dem. De som jobber med dem og bruker dem må være med på å bidra til evolusjonen.

Det er en komplisert øvelse, det å lage et designsystem, for det er nesten et livsverk i seg selv.

You Got This! er en veldig stilig læringsplattform for arbeid som ikke handler om domene, fagfelt eller rolle: rett og slett bare læring om hvordan man kan gjøre sin egen arbeidsdag bedre og mer givende for en selv.

I en arbeidshverdag der ting flytter på seg raskere og raskere er det fantastisk at noen har laget en plattform som dette. Jeg kommer til å se mange av disse videoene flere ganger.

En av mine beste venner tipset meg i dag om Marginalia Search og beskrev det på følgende måte:

Det føles virkelig som å være på nettet circa 2003, med nettsider som er superdedikerte til sine nisjer og har faktisk informasjon istedet for listicles og reklame

Og det er virkelig sånn det føles, en throwback til det "ekte nettet" før det ble overkjørt av algoritmer, kunstig intelligens og dyp læring; vi går tilbake til det som er hele grunnen til at jeg ble så fascinert av internett i det hele tatt. Det er en plass for alt, ikke bare det som tar opp mest plass, men også de små, fantastiske tingene.

Milde malunka, så lei jeg er av frontendutvikling.

Ta React. Du skal utvikle en app og tenker, hei, kanskje jeg skal bruke React? Joda, du skal nok bruke React også, men om du innbiller deg at du kun skal bruke React, da har du rotet deg bort. For det ingen forteller deg er at det å utvikle en app med React er som å kjøpe en ny bil.

React er bare basismodellen, nemlig. Ser pent ut, React - deklarativt og komponentbasert, akkurat som du har drømt om. Men så begynner alle utstyrspakkene å dukke opp. For hva med state management? Du trenger jo state management! For bare noen hundre ekstra kilobyte kan du legge på Redux Toolkit, som gir deg alt du trenger! Stores, reducers, actions, slices, thunks! Du kommer garantert til å trenge dette på vinterføre i norsk utvikling! Men klarer du deg med Redux alene, da? Hva med Saga? Du trenger vel også Saga?

Så du tar Redux Toolkit og Saga og ender opp med et enda større rot enn det du hadde. Det gir mening, det som står i de flotte introduksjonene om hvert av verktøyene, så du overser litt at du ikke egentlig forstår halvparten. Det gir mening etterhvert, hører du fra en annen utvikler. Han ser ut som om han vet hva han snakker om, der han går i flannelskjorte og briller med tjukke rammer, og en kopp kaffe rett fra presskanne han selv har medbrakt. Det er sånn de ser ut, de som jobber med sånne ting.

Men det stopper ikke der. For brått må du ta enda en bestemmelse. Hvordan i alle dager skal du bedrive styling? Kanskje styled-components? Nei, hva med Tailwind? Det er jo ikke som om noen skriver CSS selv om dagen, haha, det gjorde man i gamle dager, det! Så du tar inn styled-components, og begynner å skrive CSS-in-JS, for det er jo sånn man skriver CSS om dagen? Ikke sant...?

Hva med Apollo, da? For GraphQL er jo i vinden i disse dager! Du har hørt om GraphQL, det virker ordentlig kult å kunne skrive queries på frontenden uten å måtte gå via gammeldagse REST-APIer og denslags krimskrams. Og han som sitter og jobber med backenden du skal operere mot, han virker som en likandes kar der han sitter, smått overarbeidet med nervøse rykninger. Han holdt en intern bedriftspresentasjon om GraphQL for en måneds tid siden, og beslutningstakerne nikket anerkjennende da de fikk høre om hvor effektive alle skulle komme til å bli med denne nye flotte teknologien. Han sukker litt oppgitt av at du prater med ham, men sier at joda - det stemmer, det. GraphQL er det nye store. Can't go wrong.

Så du tar inn Apollo også. Det blir bra, vet du, å få inn litt GraphQL også. Det blir jo en skikkelig moderne app, det her! Du begynner å utvikle litt, kommer i gang med å lage noen komponenter. Etterhvert kommer det mer ekstrautstyr også. Sånn som testverktøy. Du trenger jo det. Jest og Cypress er jo det alle bruker. Du finner ut at du er altfor sent ute med å sette opp en kodestil for prosjektet ditt, og ESLint og Prettier kommer på plass også. Du hører andre rundt deg snakke om NextJS og Remix. Noen av de ordentlige kule kidsa borte ved hjørnebordet i kantina, der ingen andre tør å sette seg, snakker om noe som heter Astro også.

Og før du vet ordet av det, sitter du der med React, Redux Toolkit, Saga, styled-components, Apollo, Jest, Cypress, ESLint og Prettier. Det føles fortsatt inadekvat fordi du ikke en gang har tenkt tanken på å bruke NextJS eller Remix. Det som var en enkel, pen React-app har blitt et sammensurium av kode, et gigantisk berg av dependencies som spytter ut åtte A4-ark med deprecation notices når du starter opp prosjektet i terminalen. 417 vulnerabilities (312 moderate, 75 high, 30 critical) lyser mot deg når du prøver å installere pakkene dine.

Dette er ikke en dystopi. Dette er virkeligheten, i norske bedrifter, dag inn og dag ut, enten vi vil eller ei. Det er ille nok at vi utdanner unge utviklere til å tro at denne måten å drive utvikling på er normal, for det gjør vi, men vi tror jaggu på det selv også.

Klart, det betyr ikke at jeg skal slutte å drive med frontendutvikling, for jeg er veldig glad i fagfeltet mitt. Jeg digger å lage ting som påvirker livene til andre, og jeg elsker å pusle med design og grensesnitt og kode for å gjøre ting bedre.

Men jeg har tenkt til å sette foten ned og si "nei" oftere når noen prøver å innbille meg at jeg må bruke React, Redux Toolkit, Saga, styled-components, Apollo, Jest, Cypress, ESLint og Prettier hver gang jeg vil lage noe nytt. For det trengs ikke.

I dag har Twitter kastet på meg en ny serie med annonser. Hver gang jeg får en serie med annonser fra Twitter, blokkerer jeg stort sett avsenderene, eller jeg bare sier tusen takk men nei takk, ikke interessert. Det hjelper dem sikkert med å profilere meg ytterligere men sant å si så er reklamen jeg får på Twitter den aller, aller verste, og jeg orker den ikke, så bort med den.

Men det er litt interessant å se hva Twitter tror at jeg interesserer meg for, så jeg liker å ta litt notat av hvilke annonser jeg får servert. Jeg registrerer at siden sist, har Twitter gjort følgende antagelser om meg:

• Twitter tror fortsatt at jeg er interessert i kryptovaluta og blockchain. Jeg vet ikke hvordan jeg skal fortelle Twitter at jeg synes at krypto er en menneskeskapt pest som må dø, men nå har jeg altså blokkert så utrolig mange sånne selskaper at en skulle tro de tok hintet. (Seks av disse, samtlige blokkert.)
• Twitter tror at jeg er interessert i å lese whitepapers om sikkerhet, cloud og forretningsutvikling. Greit, vi begynner å nærme oss fagfeltet mitt, men de fleste av disse annonsene er så åpenbart... Ikke helt objektive at jeg får litt mark av dem allikevel. Og noen av dem kommer bare på grunn av sånne ting som er helt fra siden! Er du interessert i å lese om markedsanalysene våre i Spania, Vegar? Nei, ellers takk, Twitter, men det er hyggelig å se at dere har fått med dere at jeg har brukt Duolingo til å lære meg spansk! (Fire av disse, samtlige blokkert.)
• Twitter tror at jeg er interessert i dating i Tyskland! Klaske meine schincke, det kan du ta deg en Aperol spritz på at jeg ikke er. (Gudskjelov bare én av disse, og jeg trenger virkelig ikke flere av dem i mitt liv.)
• Twitter tror at jeg liker Warhammer. De nærmer seg - jeg er veldig glad i dyr plast. Da er det som regel snakk om Warhammer, Lego eller tastaturdeler. Vi skal se ved neste veiskille om de har funnet ut hvem av de tre jeg er mest interessert i. Hint: det er ikke Warhammer. (Én av disse, ikke blokkert, men jeg takket pent nei til flere sånne annonser.)
• Twitter tror at jeg er interessert i en app som lar deg ta bilde av steiner for å se om det kan være skatter i nærheten. Jeg måtte drikke et glass vann og ta en pause etter å ha lest pitchen, så godt lo jeg. Jeg tror fortsatt denne appen har høyere reelt potensiale enn krypto. (Blokkert. Jeg bare kan ikke.)
• Twitter tror jeg er interessert i Postman, appen som gjør arbeid mot APIer enklere. God treff, Twitter. Av respekt lot jeg denne annonsen gå videre uten blokkering eller nei takk. Jeg må allikevel si jeg foretrekker Insomnia, rent personlig.
• Twitter tror jeg er interessert i franskspråklige tilbud fra Flying Blue, et flytibud som opererer i Afrika. Lang, lang, lang historie her, men denne gir mening. Jeg er ikke interessert, riktignok. En vakker dag skal jeg skrive om all mailen jeg får fra Afrika. (Blokkert, siden jeg uansett får dette nyhetsbrevet fra Flying Blue i innboksen min og bare ikke får til å unsubscribe. Om noen har fått det til, fortell meg gjerne hvordan.)
• Sist, men ikke minst: Twitter tror at jeg er interessert i "natural healing processes". De som tror på sånt må få lov til å tro på sånt, og jeg vet at noen av dem er påfallende nær det norske kongehuset, men for oss som ikke er blandinger av reptiler og romvesener og har råd til medaljonger til flere tusenlapper... Vel, vaksiner er veien å gå, mine damer og herrer. (Blokkert.)

Jeg gleder meg allerede til neste runde.

(Scene: digital lønningspils i Norsk programmering, der jeg og Marius diskuterer besøket jeg skal ta i mot denne uken.)

Vegar: Og så skal vi på surstrømmingslag på lørdagen.

Marius: Nei, faen, nå må jeg snart ta fra deg passet ditt.

Vegar: Jeg tror ikke man trenger pass for å dra til Fredrikstad.

[Lang pause]

Marius: ...Dette var en veldig uelegant løsning, Clas Ohlson.

[Scene: Vegar kommer inn på den fjongeste matbutikken på Skøyen. La oss for ordens skyld kalle den Maskemanns, siden det faktiske navnet ikke er til å uttale av noen som bor øst for Bygdøy.]

Ansatt: Hall-ooo! Hva kan jeg hjelpe deg med?

Vegar: Ja hei du jeg skulle gjerne hatt--

Ansatt: Ost, ja? Hva slags tenkte du?

Vegar: Hva? Nei, nei. Jeg ser etter Espelette, og så var jeg borte og så, men--

Ansatt: Åh, OK. Jeg tror kanskje ikke vi har den på lager nå, men la meg se i ostedisken.

Vegar: Det er ikke en ost. Det er et krydder.

Ansatt: Åh, ja-a-a... Så du vil ikke ha ost, altså?

Vegar: Nei, takk.

Ansatt: Jeg driver egentlig mest med ost, skjønner du.

Vegar: Ja, stemmer.

...For det skjønte jeg ikke i det hele tatt.

Jeg har skrevet et lite leserinnlegg i Kode24 om hvordan det er å gå fra studielivet til arbeidslivet, og de voldsomme følelsene som kan (les: kommer til å) dukke opp når man er ny og uerfaren.

Jeg husker godt selv hvordan det var å være ny i arbeidslivet, selv om jeg trodde jeg visste hva jeg gikk til og hvordan man ter seg i jobbsammenheng. Jeg skulle egentlig ønske at universiteter og høgskoler hadde en obligatorisk modul som gikk samtidig som bachelorprosjektet der man snakket om arbeidslivet og hvordan det fungerer å være nerd på fulltid.

Så jeg har forsøkt å nedtegne noen kloke ord til de unge lovende. Gratulerer og lykke til!