I programvareteknikk er det en utbredt oppfatning om at en ingeniør bare bør bruke et rammeverk når han eller hun forstår de interne mekanismene. Dette er en feilslutning.
Hvorfor må vi kjenne de interne mekanismene — spiller detaljene virkelig så stor rolle? Noen ville kanskje si at uvitenhet er lykke.
Bilmotor
La oss undersøke motoren i en bil:

Hvor mange virkelig vet hvordan motoren fungerer?
Kan du fortelle meg hvorfor det kalles en 4-takts motor?
Hva gjør hver takt?
Hva er forskjellen mellom en 4-takts motor og en 2-takts motor?
Noen?
Og likevel kjører vi bilene våre uten å tenke på “hvordan” bilen får oss til destinasjonen.
Vi bruker bilen ved hjelp av rattet, girspaken, gassen og bremsene.
Hvem bryr seg om hvordan det fungerer, så lenge det får oss til destinasjonen. Når bilen går i stykker, tar vi den til en ekspert.
Kjernekompetenansen til en bedrift

I næringslivet har et selskap spesialisert kunnskap som gjør det konkurransedyktig. Dette kalles selskapets kjernekompetenanse.
En kjernekompetenanse kan være en prosess eller et produkt.
For å forbli konkurransedyktig må et selskap uavlatelig forbedre sin kjernekompetenanse. Å bruke ressurser på aktiviteter som ikke støtter selskapets kjernekompetenanse svekker selskapets konkurransefordel. Dette åpner muligheten for konkurrenter til å overta selskapets konkurransefordel.
Denne ideen illustreres best med et eksempel.
Apple

Apple er kjent for sin enkelhet og sine vakre produkter. Man skulle tro dette ville være lett å kopiere, men det er det ikke, spør bare Samsung, HTC og Microsoft.
Hvorfor har disse selskapene mislyktes? Fordi enkelt er vanskelig og Apple er ekspert på enkelt.
Kjernekompetenansen til en person

Kjernekompetenanse kan også gjelde for personer.
Hva skiller deg fra andre?
For å ha utviklet din kjernekompetenanse, har du måttet fokusere strengt på ett område, noen ganger i årevis, og oppnådd innsikt og kunnskap som skiller deg fra andre.
Som i en bedrift, for å opprettholde din konkurransefordel må du kontinuerlig forbedre din kjernekompetenanse.
Bruke små biter

En programvareingeniør er ikke annerledes enn et selskap eller noen annen profesjonell. Vi må velge og vrake hva vi lærer for å holde oss i tråd med vår kjernekompetenanse.
Å forstå det interne arbeidet til hvert rammeverk vi bruker er ikke praktisk og er tidskrevende. Jeg forventer at rammeverksforfatter er en ekspert innen rammeverkets domene, derfor trenger jeg ikke å kjenne dets interne mekanismer.
Er ikke dette poenget med programvare — å bruke svartboks-funksjoner til å produsere et større og mer komplekst arbeid? Jeg tror det er det.
Til slutt handler det om fokus og tid, som begge er begrenset.
Forfatter: Chuck Conway er en AI-ingeniør med nesten 30 års erfaring innen programvareutvikling. Han bygger praktiske AI-systemer—innholdspipelines, infrastrukturagenter og verktøy som løser virkelige problemer—og deler det han lærer underveis. Koble til ham på sosiale medier: X (@chuckconway) eller besøk ham på YouTube og på SubStack.