Mikroblogg, side 8

Og da er jeg tilbake.

Det kommer en lengre artikkel om saken etterhvert, men veldig kort og enkelt fortalt: den gamle nettsiden min brakk i vinkel. Det var en kombinasjon av gammel versjon av Next, gammel versjon av React, gammel versjon av den gamle next-on-netlify-pakken som ikke ville samarbeide, samt et gammelt build image hos Netlify som virkelig ikke under noen omstendigheter ville la seg oppgradere før jeg hadde fikset resten.

Kombinert med det at jeg ikke egentlig var så veldig fornøyd lenger med Cosmic som headless CMS ble beslutningen ganske enkel: nå lager jeg hele sulamitten på nytt fra bunnen av med litt mer moderne verktøy.

De moderne verktøyene av valg er Sanity som headless CMS og SvelteKit som utviklingsrammeverk. Merk at ikke alt er helt på plass ennå, og at forbedringer trolig kommer i løpet av romjulen eller kanskje litt over nyttår. Men jeg er altså tilbake. Og godt er det, nå som Twitter blir mer lik en brennende søppelfylling for hver dag som går.

En gang for lenge siden var jeg i jobbintervju til en jobb jeg veldig gjerne ville ha. Det visste jeg fordi jeg hadde jobbet i nøyaktig den stillingen som konsulent en liten stund, og jeg likte både stedet, folka, arbeidsoppgavene og utfordringene. Da stillingen ble utlyst snublet jeg nesten over mine egne bein på jakt etter knappen for å sende inn søknad.

Jeg ble kalt inn til førstegangsintervju og fikk snakke med folka jeg allerede kjente, og visste at de kjente godt til meg og mine kunnskaper og ferdigheter. Det var det første intervjuet der jeg følte at jeg hadde en nerdeprat med noen fremfor å bli utspurt, og den første gangen jeg virkelig følte meg hjemme et sted.

Så kom andregangsintervjuet ikke lenge etter, og jeg fikk i den forbindelse et case jeg skulle løse: en skjematjeneste. En helt enkel, simpel skjematjeneste. Som grunnlag for en diskusjon om hvordan man jobber, sant? Det er jo egentlig det caseoppgaver er, man lager noe for å vise hvordan man tenker, og det trenger ikke være kjempepolert fordi man kan snakke om hva man hadde gjort om man hadde mer tid.

Det var bare det at denne gangen orket jeg ikke å kode. Litt fordi jeg nettopp hadde vært gjennom en tøff tid i karrieren min der jeg var utbrent og deprimert i noen måneder etter en bestemt hendelse, men også fordi jeg virkelig var helt blank på hvordan jeg skulle gå frem. React? Skulle jeg ta frem React etter å ha lagt det i skuffen i så lang tid? Ren HTML? Det virket som en enorm oppgave å skulle skrive ren HTML og CSS for å lage denne skjemaløsningen. Jeg hadde lite lyst til å lære meg et annet verktøy på tampen; jeg kunne jo ikke komme til et andregangsintervju med en løsning jeg knapt hadde oversikt over hvordan var skrudd sammen.

Til slutt bestemte jeg meg for å gjøre noe jeg ikke hadde gjort tidligere i et teknisk intervju: jeg droppet å kode.

Hvorfor ikke, sant? Caseteksten sa at jeg sto fritt til å velge hvordan jeg ville løse og presentere caset; jeg kunne kode, designe, skrive prosa til og med! De hadde jo allerede sett meg kode, jeg hadde allerede vært inne som konsulent og fått anerkjennende nikk da jeg gjorde utbedringer i løsningene deres. På en måte var jeg over det hinderet allerede, iallefall i min egen personlige mening.

Så jeg bestemte meg for å papirprototype en løsning.

Papirprototyping er en av mine hemmelige evner. Det er også en av mine favorittmetoder for problemløsing; det er kjapt, enkelt, overhodet ikke teknisk, absolutt ikke finmotorisk arbeid, og innbyr til kjappe iterasjoner fordi man kan lage en skisse på fem minutter og kaste den om man ikke er fornøyd. Jeg satt med papir og blyant (litt fordi jeg er gammeldags og litt fordi jeg har verdens fineste trykkblyant som jeg bruker så ofte jeg får muligheten) i noen timer og itererte. Satt og sammenlignet idéer og løsninger og fant til slutt ut hva jeg mente var beste løsning å gå videre med. Foredlet på finere papir med tusj og la i en mappe, klart for presentasjon.

Dagen for det tekniske intervjuet kom. Jeg ble tatt med på det største møterommet i etasjen der utviklingsavdelingen satt, og fikk møte den nye direktøren for digitalisering; en ruvende skikkelse som åpenbart hadde enormt med erfaring. Har du med deg en laptop som du vil koble til HDMI, spurte han med en spent tone i stemmen.

Jeg tok opp mappen min fra sekken, usikker helt inn til beinet på om dette egentlig var riktig valg. Her hadde jeg fått sjansen til å komme på intervju til en stilling jeg virkelig ville ha i en bedrift der jeg virkelig ville jobbe, og så hadde jeg ikke utviklet noenting for å vise at jeg var en god utvikler når det først var teknisk intervju? Er du helt noldus, Vegar? Helt premieløk? Det var et interessant blikk jeg fikk fra andre siden av bordet da jeg presenterte. Jeg forklarte hvordan jeg hadde jobbet, hvordan jeg hadde iterert, betraktningene jeg hadde tatt i utvikling av grensesnittet. Fortalte om gjenbruk av data fra andre kilder, universell utforming og hvorfor man skal sy sammen løsninger slik som jeg hadde sydd sammen løsningen min.

Det var helt stille i rommet mens jeg holdt den lille dissertasjonen min. Det virket som om de kastet blikk til hverandre i håp om at noen andre skulle begynne å prate først, for ingen virket helt sikre på hva de skulle si til meg. De ventet nok en teknologisk demonstrasjon. Og de ventet nok at jeg skulle blåse dem til himmels med kunnskapen min om frontendutvikling. Men det kom ikke noe sånt. Ikke denne dagen. Bare noen ark med noen tusjstreker og en lang monolog om hvorfor det var sånn.

Det endte for øvrig med at jeg fikk jobben.

Og da jeg begynte, ble min første oppgave å implementere det samme skjemaet jeg hadde laget i caseoppgaven. Det viste seg at de selv hadde kommet frem til at den løsningen jeg presenterte var best, før jeg i det hele tatt var der på intervju. Prosessene hadde ledet oss til samme sluttresultat.

Jeg vet ikke om det er noen moral i denne lille historien fra gamle dager, men det er en jeg liker å fortelle for å understreke et viktig poeng: å utvikle er mer enn å kode. Noen ganger holder det i lange baner med blyant og papir for å komme frem til gode løsninger. Det hender til og med at man kan få seg en jobb på den måten.

Elise Kristiansen har skrevet om gatekeeping i IT-bransjen og hvorfor verden blir et vanskeligere sted når folk i bransjen oppfører seg som, vel, idioter.

For øvrig har Elise helt rett. Jeg jobbet en kort stund - hele to uker - i et konsulentselskap i IT-bransjen. I løpet av de to ukene var hver eneste person, og jeg mener virkelig hver eneste person, i en slags kampmodus der jeg ikke kunne snakke om fag eller prosjekt uten at jeg skulle prøves på ting. Og om jeg klarte å svare for meg, gravde de bare dypere og dypere til de fant noe å ta meg på. Jeg tapte kampen, de vant, jeg følte meg som en dritt, de følte seg sikkert sykt bra. Overlegenhet er litt av et dop. Hvem visste at det ikke er lov til å snakke om REST-APIer om ikke du har lest de nitten beste bøkene om temaet? Eller at du ikke kan snakke om React uten å minst ha jobbet med det i tre år?

Så om ikke vi skal ha en eldrebølge innen faget vårt som følge av at de gamle er eldst og de yngre slutter og finner seg andre ting å gjøre fordi IT ikke er bærekraftig over tid, må vi slutte å holde på sånn. Jeg sier "vi" fordi det er et bransjeproblem og om vi skal få bukt med det, må vi også ta de som holder på sånn i ørene og be dem ta seg sammen med litt Atle Antonsen-stemme.

Masse kudos til Elise for en god og velformulert tekst om temaet!

Jeg hadde en drøm i natt.

Og jeg vet jeg har snakket om drømmene mine før, for jeg husker dem alltid, selv om noen er mer levende enn andre. Denne var spesielt levende, ikke så mye for innholdet, men mest på grunn av hvordan jeg følte meg.

De som kjenner meg passe godt vet at barneskolen og ungdomsskolen var en prøvende tid for meg. Jeg hadde det egentlig ganske dritt, sagt rett ut. Jeg var enkel å plukke på og erte, tok meg nær av alt som ble sagt om meg, hadde like liten lunte som sosiale antenner, og var en nerd med bolleklipp og Harry Potter-briller før Harry Potter var kul.

Drømmer der jeg er tilbake på barneskolen kommer nå og da. Som regel kommer de ikke med en negativ følelse forbundet med dem, det er nok mest fordi det er omgivelser og bygninger jeg kjenner godt og som underbevisstheten min klarer å sy sammen en drømmemodell av ganske enkelt.

Jeg har lite drømmer om ting som skjedde på barneskolen. Ingen vonde følelser eller drømmer eller minner om de jeg gikk i klasse med, eller ble undervist av. Det er en artig betraktning; i våken tilstand er det menneskene jeg husker først, mens i drømmene mine er menneskene nesten aldri der.

Denne gangen var de der. De aller fleste av dem.

Læreren min, for eksempel, som jeg forgudet de første par årene, men som hadde en bitter ettersmak de siste par årene. Gutten som alltid satt og tegnet digre, kompliserte våpen og maskiner i timen og ofte hang seg på de andre selv om han ikke startet noe. De to jentene som jeg var halvveis venner med, men som i smug holdt en logg over alle tingene jeg sa og gjorde som de kunne ta meg på senere. Jeg fant boka i åttende, to år etter vi først ble "venner".

Gutten som hadde malt seg en blink på ryggen min allerede fra første klasse var der også. Han som hele tiden pirket på hvor vanskelig jeg var i matveien spesielt; han fant knappene mine kjapt og trykket på dem dagen lang, så ofte han kunne, og viste villig andre hvor knappene satt. I ettertid har jeg forstått at han nok ikke hadde det enkelt hjemme, og at han nok var under- eller umedisinert, og at utageringen nok ikke var hans feil i all hovedsak. Jeg må fortsatt leve med lyden av stemmen hans i hodet mitt, enda han er voksen i dag.

Og de andre, såklart. Guttene jeg var venner med fra barnehagealder men som til slutt ble lei fordi jeg nok ikke var så enkel å ha som kamerat. Jentene som gikk mer og mer over mot å være ungdomsskolejenter med tiden, med oppførsel deretter, deriblant at de tok kraftig nytte av at jeg var litt vel enkel å tirre for litt vel enkle ting. Alle andre også. Jeg var ikke like involvert med alle, naturlig nok.

Jeg hadde glemt lukten av det gamle klasserommet vårt til i natt. En blanding av gamle bøker og skrivebøker, gamle melkekartonger, støvete linoleum i kraftig vårsol etter en lang vinter. Den grelle gulfargen og de harde, brune plaststolene. Pultene med klistremerker og lapper teipet på, der hjørnene manglet fordi vi alltid skrapte bort med nålen på passeren.

De røde og blå papparkene som fortalte verden hvilken gruppe vi tilhørte, pluss et barnehagebilde og bursdagen vår skrevet på med tusj. Julius, klassebamsen vår, var i skapet der vi oppbevarte ting og tang, og han ble tatt frem i ny og ne for å gå noen runder hjem til oss alle så vi måtte skrive og tegne i Bamseboka om hva vi hadde gjort.

Følelsen av å gå inn i klasserommet igjen, selv om det bare var en drøm, var uvirkelig. Stemmene og lydnivået var så kjent. Den vante summingen avbrutt av noen som brått snakket litt ekstra høyt så jeg myste og spant meg i litt umiddelbar redsel for at det var meg det skulle handle om. Plassen min, nederst på gruppa med fem, vendt mot kateteret og tavlen. I hjørnet kunne jeg se klasse-PCen, den store lysegrå boksen som til nøds klarte å kjøre Vikingbyen og DX-Ball som noen hadde smuglet inn på diskett.

"Vet du hva?" Spørsmålet kom fra læreren min, hun sto i en mørkeblå kjole med blomster og holdt i en liten bunke med papirer.
"Jeg hører så mye fint om hvordan det går med deg, Vegar!" Stemmen hennes var munter denne gangen, hun smilte som om hun virkelig mente det hun sa. Det var lett å avsløre henne på det, selv som barneskoleelev; noen ganger smilte hun bare fordi det var det rette å gjøre eller fordi det falt seg naturlig med temaet, eller kanskje bare fordi hun helst ville ha oss til å samarbeide og gjøre som vi fikk beskjed om.

Ikke så denne gangen. Hun la bunken med papirer ned, og jeg kunne bla gjennom. Det var et bursdagskort der, med Sonic the Hedgehog. Et par ark jeg kjente igjen som forsiden av bacheloroppgaven min. Et par ark med en masse svada og kommunevåpenet til Skedsmo kommune, der jeg jobbet en gang i tiden. Og en kopi av feedback-skjemaet vi bruker på jobben nå om dagen i forbindelse med year-end review. Og noen andre ting jeg ikke husker, annet enn at jeg kjente det igjen på en vag, trygg måte.

Og der sto hun og så på meg, nikket anerkjennende mens jeg så gjennom, som om jeg hadde fått tilbake en prøve eller en særoppgave med god tilbakemelding fordi jeg hadde vært flink til å lage kildehenvisninger og bruke bilder og tekst flittig. Jeg satt der, som en skolegutt, ikke engang kommet i stemmeskiftet, og så over ting fra mitt voksne liv til lyden av våpentegnegutten som halvbrølte en av sangene til Diablo for n'te gang den morgenen.

Jeg må ha vært tett på å våkne, for jeg husker at jeg tenkte over saken.

Du hører ikke til her, Vegar. Ikke nå lenger. Klasserommet er for lengst pusset opp, barna for lengst voksne, læreren sikkert pensjonert og gutten med bolleklippen finnes ikke mer. Ikke sånn som han var den gangen, der han satt på skolen dag inn og dag ut og fantaserte frem et liv i en verden der folk i det minste forsto ham og han hadde kontroll, anerkjennelse og fotfeste.

I dag morges våknet jeg ti minutter før klokka, i en verden der jeg har kontroll, anerkjennelse og fotfeste.

Etter å ha skrevet om mine personlige "ti bud" innen frontendutvikling, var jeg så heldig å få teksten publisert i kode24. Det har siden kommet veldig mange hyggelige tilbakemeldinger på det jeg skrev, og det varmer et gammelt nerdehjerte. Desto mer er jeg glad for god respons siden det betyr at mange kanskje kjenner seg igjen, og det gjør meg trygg på at det er flere der ute som er som meg. Fantastiske er dere, alle som én.

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.