Den pragmatiske programmereren

The Pragmatic Programmer er en anerkjent bok som først kom ut i 1999 og fikk senere en jubileumsutgave i 2019. Boken inneholder en rekke gode triks og tips om hvordan vi som utviklere kan jobbe og tenke. I sin essens handler The Pragmatic Programmer om å være en god håndverker. Mange av holdningene, prosessene og metodene som presenteres er like aktuelle i dagens KI-drevne utvikling som de var i 1999. Spør du undertegnede så burde alle nyutdannede utviklere få den av sin første arbeidsgiver.

Det å være en god systemutvikler er ikke å løse Advent of Code problemer raskest og mest effektivt. Det handler mye om holdninger og fremgangsmåter.

Her er et par takeaways fra boken som forhåpentligvis gjør at du blir fristet til å lese den.

Katten spise kildekoden min

Når vi utvikler komplekse programmer og informasjonssystemer er det ikke et spørsmål om det vil skje feil, bare om når. Det kan blant annet være misforstått forretningslogikk, en uforutsett infrastrukturhendelse eller et bruksmønster som ikke er tatt høyde for.

Under tittelen The cat ate my sourcecode forteller forfatterne at det som skiller den pragmatiske utvikleren fra andre er ikke at de aldri gjør feil. Men de håndterer feil profesjonelt og anerkjenner og tar ansvar for feilen. De bruker ikke energi på å legge skyld. I stedet fokuserer de på å finne løsninger når situasjoner oppstår.

Den pragmatiske utvikleren er ærlig og og innrømmer feil og begrensninger i egen kunnskap. Ærlighet og åpenhet er med på å skape et miljø med tillit og trygghet.

Essensen av god (programvare-) design

Som utviklere liker vi ofte å diskutere og sammenligne forskjellige paradigmer og designprinsipper. Når vi starter å programmere lærer vi en rekke regler. Blant annet You Aren't Gonna Need It, Don't Repeate Yourself og Keep It Simple, Stupid.

Men:

Hvorfor skal vi foretrekke komposisjon over arv? Fordi det gjør endringer enklere.

Hvorfor skal vi ha veldefinerte domenegrenser? Fordi dersom et domene endrer seg vil ikke endringen ha påvirkning på de andre.

Hvorfor er Single Responsibility nyttig? Fordi hvis det kreves en endring så er det kun en plass den skal gjøres.

The Pragmatic Programmer fremhever at det som virkelig teller er at "Good Design Is Easier to Change Than Bad Design". God design er kode som er enkel å endre: Easier to Change (ETC). Alle som har noen år bak seg som utvikler vet at krav, forretningslogikk og teknologi stadig forandrer seg. Easier to Change (ETC) er en grunnleggende prinsipiell verdi og ikke en spesifikk regel. Når du spør deg selv om fremgangsmåten du løser et aktuelt problem på åpner for å enkelt gjøre endringer senere, vil du fort innse om du er på spor av en god eller dårlig løsning.

I en hverdag med KI-verktøy blir dette ekstra viktig. KI kan gi fart, men også fristelsen til å akseptere unødvendig kompleksitet og være lat i kvalitetssikring. Som gode håndverkere må vi fortsatt være i kontroll og sørge for at vi følger ETC-prinsippet.

The Pragmatic programmer