Et spørsmål som til stadighet dukker opp i ulike former er: Hvordan kan vi som utviklere holde oss oppdaterte når det skjer så mye nytt hele tiden?
Det kommer stadig vekk nye språk, databaseløsninger, dataformat, rammeverk, designbibliotek, metoder, utviklingsmetoder- og ideologier mm. Og alle krysskombinasjonene av disse på toppen. Det er helt klart vanskelig (les: umulig) å holde følge.
I denne teksten vil jeg dykke ned i hvordan jeg har valgt å tilnærme meg dette.
Obs! Dette er ikke en tekst med så mye konkrete teknologi-spesifikke løsninger som det er oppfordringer til kontekstualisering og kritisk tenking generelt sett. Og ikke minst et håp om å kunne roe ned pulsen på de mest bekymrede der ute.
Denne teksten kan forøvrig være vel så relevant for selskapene som rekrutterer som det er for den enkelte arbeidstaker.
La oss dykke ned i moroa!
Er alt verdt å lære seg?
Som med de fleste store temaer og problemstillinger forsøker jeg å angripe de ved hjelp av elimineringsmetoden og en dæsj grunnleggende økonomi-prinsipper.
Det vil for oss her si: Kan det være slik at ikke absolutt alt som dukker opp er verdifullt nok å lære seg slikt at avkastning blir stor nok i forhold til investeringen?
Og hvordan kan vi kontrollere dette for å komme oss i retning ønsket mål?
Personlig så mener jeg - og jeg tror ikke dette er veldig kontrært - at mange av endringene vi møter i vårt fagfelt ikke alltid er fremskritt, nytt eller relevant.
Tror AI overtar mye: «Vær problemløser, ikke kodemaskin!»
Om å ikke være fremskritt
Vi har lett for å tenke på teknologiske endringer som forbedringer. Hvorfor skulle ellers dette nye lages?
Men heller enn å automatisk tenke på at enhver slik endring flytter oss i en tilnærmet perfekt retning mot en optimal fremtidig tilstand la oss heller se endringene som vektorer eller forflytninger i et hyperdimensjonelt mulighetsrom; Det er - forenklet sett - mulig å bevege seg frem eller tilbake langs en eller flere akser.
Noen av aksene i dette "rommet" kan sees på som; smidig utvikleropplevelse, oppfattet responstid, faktisk responstid, ressurseffektivitet, sikkerhet, fleksibilitet mm. Akkurat hva disse er er ikke så viktig akkurat nå, poenget er at en overgang fra et verktøy du kjenner til det nye kule vil by på en forflytning i dette rommet som ikke nødvendigvis tar deg i den reelle retninger du håper på. Eller trenger.
Personlig tenker jeg på teknologivalgene vi tar i bransjen i sin helhet litt som en biesverm (obs! jeg har egentlig ikke peiling på bier, men håper det gjør det lett å visualisere hva som foregår): Det er høy intern entropi hvor hver og en endring internt er uforutsigbar, men som helhet forflyttes det seg i en hovedretning.
Slik er det for oss også: Vi gjør tusenvis av eksperimenter, og over tid trender vi mot noe.
Hva akkurat dette noe't er for noe, er en annen diskusjon :)
«Vi gjør tusenvis av eksperimenter, og over tid trender vi mot noe.»
Om å ikke være nytt
Det aller meste av tilsynelatende ny teknologi vi ser fra dag til dag er en vri på noe gammelt. Gjerne med en dæsj av noe som er kult i tiden. Det være seg hopp mellom mainframe -> PC -> mobil -> sky -> edge osv, eller hvordan vi nå jobber med å gjenskape 90-talls UI-kapabiliteter via nettleseren.
Kanskje flytter vi bare tid eller sted noe kalkuleres. Kanskje endrer vi hvordan dataene flyter/distribueres. Kanskje gjør vi det samme med annen kode, språk eller algoritme.
Dere tar tegningen!
Det betyr ikke at endringene aldri tilfører verdi, men heller at vi over tid ser visse mønstre danne seg. Med dette opparbeider vi noen kognitive hjelpemidler for å se dette nye som en ny-kombinasjon av i hovedsak preeksisterende kapabiliteter. Slik gjør vi det lettere å gjøre tidlige magefølelsesvurderinger om relevans og nytteverdi opp mot hva du selv jobber med.
Ja, jeg bruker magefølelse som begrep her her. Vi bør søke etter å konkretisere potensielt utbytte før vi gjør signifikante endringer, men før vi kommer dit så er det nyttig å kunne ekskludere så mye som mulig fra å i det hele tatt måtte vurderes.
Til syvende og sist leser, manipulerer og skriver vi noe data på ulike steder til ulike tider med - ideelt sett - den hensikt å løse noe for en sluttbruker. Og vi ønsker selv å ha det godt på veien mot dette.
Bruker bare én enhet i CSS: «Du trenger ikke andre!»
Om å ikke være relevant
Som utviklere er vi gjerne involvert for å løse gitte problemer innenfor gitte rammer. Nøyaktig hva disse rammene er vil variere. Over tid og mellom domener, nisjer og brukergrupper. Uansett; vi lager noe for å løse noe.
For å sette det i sammenheng: Vil dette nye [sett inn rammeverk/språk/modul/konsept/...] bety noe signifikant opp mot dette du ønsker å oppnå? Vil det med en høy nok sannsynlighet hjelpe deg, ditt team eller dine brukere i merkbar grad?
Og ikke minst; er denne forbedringen større enn summen av alle eventuelle negativer den drar med seg? Med andre ord: oppnår vi en netto positiv endring?
Det hjelper kanskje ikke om utvikleropplevelsen blir bedre hvis det samtidig innebærer at brukeropplevelsen blir verre?
Eller å spare noen prosent ekstra utviklingstid initielt sett bare for å sette seg i signifikant større risk noen uker/måneder senere?
Heldigvis er mye av det vi driver med ikke nullsumspill, men vi må se på totalbildet for å se om vi går i netto pluss.
Lær deg det grunnleggende
Vi kan rett og slett ikke være på toppen av alt, så kompromisser må tas. Ideelt sett mener jeg en først og fremst bør lære seg de grunnleggende sannhetene innenfor ens interesseområder - det finnes alltid noen relativt sett "førsteprinsipper" en kan søke å tilnærme seg. Både for utvikling generelt, og for ditt primære fagområde spesielt.
Deretter kan en jobbe for å utmerke seg innen et eller noen få spissere felt av interesse. Være seg om grunnlaget for disse områdene er personlig lidenskap eller øyeblikkelig ansettbarhet.
Merk at jeg sier "tilnærme" da jeg ikke tenker at alle skal starte med universets unnfangelse men heller holde det til det mer praktiske "bygg kompetanse om det omkringliggende".
Har du dette på plass så vil det i mange tilfeller være relativt enkelt å enten:
- A) pivotere til andre særområder, eller
- B) øke den allerede eksisterende ekspertisen der du er på vei.
Lager eget rammeverk: «Skal være så enkelt som mulig»
Blir vi kvitt støyet
En retningslinje jeg for det meste følger når jeg går inn i noe nytt er at jeg søker å bli godt kjent minst ett "lag" dypere - og ha en arbeidsforståelse for hva som er to lag dypere - enn det jeg skal være produktiv på.
Tar vi her utgangspunkt i et vilkårlig frontend-rammeverk så betyr det at jeg også vil være god på HTML, JavaScript og CSS, og ha en god arbeidsforståelse for browsere og signifikante protokoller og overføringsformater (f.eks. HTTP og JSON, kanskje også TCP).
Dette er naturligvis ganske forenklet da lag-analogier ikke er spesielt gode hva teknologi angår.
"Divide and conquer" er et kjent konsept i både kamp såvel som i algoritmefaget. Og det har også vært nyttig for meg i utøvelse og kompetanseheving som utvikler generelt. Blir vi kvitt støyet, så sitter vi igjen med signalet.
«La oss fokusere mer på hva som ligger innover - heller enn utover - i teknologibuntene våre.»
Slik trenger det ikke være
Vi kan selvsagt ikke utelukke enkelte paradigme-endrende eller på annet vis fundamentale endringer - men de er det langt imellom - og må uansett håndteres spesifikt. Jeg har vel kun opplevd èn skikkelig slik i min tid bak et tastatur her på denne planeten.
Jeg mener det er en misoppfattelse at vi som utviklere må være på toppen av alle teknologier og vilkårlige teknologibunter.
Slik trenger det ikke være. Slik bør det ikke være.
Det er verken verdiskapende eller bærekraftig i lengden, verken for individet eller bransjen. La oss fokusere mer på hva som ligger innover - heller enn utover - i teknologibuntene våre.
Lykke til på utviklerreisen!
