Først og fremst vil jeg trekke frem evnen til å utfordre etablerte sannheter.

Mange yngre programmere kommer inn med en innstilling om at ting burde være mye mindre komplisert enn det er. Hvorfor fungerer dette gamle CMSet på denne tungvinne måten? Hvor skjønner ikke kompilatoren at denne variabelen ikke kan være null, siden det da ville bli kastet exception i linjen over?

Svarer er vel egentlig stort sett det samme, det er bare ikke lagt ned nok innsats enda i å lage alle mulige produkter superenkle. For oss har blitt litt satt og vant til tingenes tilstand, er det en fin måte å røske litt opp i tankegangen vår. Vi erfarne kan fort tenke at "slik har det alltid vært, og sånn er det."

La oss ta et lite eksempel.

Som mange programmerere vet, er Kotlin et objekt-orientert språk svært likt Java, med endel forbedringer som særlig er nyttige for oss utviklere.

Jeg har hørt flere erfarne programmerere uttrykke skepsis. Tvilen går først og fremst på om disse relaltiv små nyvinningene Kotlin i det hele tatt gir noen merkbar verdi. Vil et prosjekt ha større suksess om man gjør

var name: String
var title: String?

, enn å skrive noen ekstra Java-linjer som gjør all nullhåndteringen for deg?

Her tenker jeg at man bommer om man tenker slik. Det er litt farlig for en utvikler å ikke sette pris på de små tingene som kan gjøre den kognitive lasten litt mindre.

Gjør som de unge, kast deg over mindre endringer som kan gjøre livet litt lettere.

Av og til får jeg spørsmål fra yngre utviklere om konsepter som jeg selv lærte for lenge siden, men kanksje ikke sitter like godt i minnet som det en gang gjorde.

Ett eksempel var at jeg fikk spørsmål om forskjellen på en .ear og .jar . Jeg vet det jo, men jeg har ikke hatt særlig behov for å forholde meg til detaljene om
dette de siste årene. Dette ga meg en god mulighet til å søke litt, og gjenoppdage kunnskapen.

En av de beste måtene å bli god til noe på, er å lære å forklare det til andre. De beste programmerene jeg kjenner har evnen til å forklare et konsept - ikke bare på ett nivå, men på flere, de kan tilpasse forklaringen sin til om det er Bestefar på 83 hvis teknisk kunnskap om å betjene en TV er det mest avanserte han forholder seg til, eller til Gunhild som har doktorgrad i et nærliggende tema.

Skal man sette sammen et team, tror jeg det er en god ide å ha teammedlemmer fra ulike aldersgrupper om mulig. Så kan vi erfarne som har lagt til oss våre særheter stadig bli satt litt på plass av de fremadstormende.