Book Review: The Pragmatic Programmer

Als engineer zijn er een aantal klassiekers die je op je plank moeten hebben staan. Een van die boeken is “The Pragmatic Programmer” van Andrew Hunt en David Thomas.

Het boek is een samenvatting van de inzichten die de auteurs in hun carrière hebben opgedaan.  Met gezamenlijk 40 jaar ervaring hebben ze dit boek aardig weten te vullen! Het gaat niet alleen over handigheden en tools, maar bijvoorbeeld ook over hoe je je als programmeur blijft ontwikkelen, de instelling die een goede programmeur zou moeten hebben en typische valkuilen die je in ieder project tegenkomt. Het boek leest vlot en stikt van de voorbeelden.

Kennis Portfolio

Wat ik leuk vond om te lezen is het stukje over de “Kennis Portfolio” van een engineer.

De belangrijkste bezittingen van een engineer zijn de kennis, kunde en ervaringen die hij heeft opgedaan. Omdat er in de IT in moordend tempo nieuwe talen, tools en technieken op de markt komen is het noodzakelijk om bij te blijven. Doe je dit niet, dan wordt je steeds minder interessant of zelfs irrelevant voor je klant.

Beschouw alles wat je weet over programmeren als je “kennis portfolio”. Beheer deze portfolio alsof het een financiële portfolio is.

Hoe bouw je een kennis portfolio op?

  • investeer regelmatig, ook al is het maar een klein beetje. Maak het een gewoonte om voortdurend nieuwe kennis op te doen.
  • diversificatie: je moet een basis hebben, een bepaald onderwerp waar je veel van af weet, maar stop daar niet. Investeer ook in andere onderwerpen. Als het ene niet meer populair is, dan ben je nog steeds relevant door je kennis van het andere.
  • buy low, sell high. Investeren in een opkomende taal of technologie voordat deze mainstream wordt kan zich terugbetalen.
  • evalueer. Omdat de IT zo dynamisch is, is het goed om af en toe stil te staan en te kijken of je nog goed bezig bent. Het kan goed zijn dat iets dat aan het begin van het jaar helemaal hot was, totaal niet is aangeslagen. Dan wordt het tijd om een ander onderwerp te zoeken.

Enkele concrete manieren om je portfolio op te bouwen zijn ook in het boek te vinden:

  • leer ieder jaar een nieuwe taal
  • lees ieder kwartaal een nieuw boek
  • lees ook niet technische boeken. Behalve met computers werk je ook met mensen, zij het klanten of collega’s. Ook kun je aan jezelf werken. Zie deze boekenlijst
  • volg een cursus. Als je bij een groot bedrijf werkt heb je vaak een cursusbudget en een intern opleidingsinstituut, maar er zijn genoeg alternatieven. Je kunt tegenwoordig via MOOCs een (vaak gratis) cursus volgen.
  • bezoek een meetup. In iedere stad zijn er wekelijks leuke meetups voor engineers. Tussen 18u en 21u heb je een interessante avond, met vaak nog een hapje en een drankje inbegrepen.

Leuke wijsheden

Het boek barst van de wijsheden, ik licht er hier een paar uit.

Don’t live with broken windows

Je kent dit fenomeen vast wel. Een gebouw wordt gesloten en na verloop van tijd wordt er een raam ingegooid. Nu het eerste raam is ingegooid volgt er al snel een tweede en volgt ook de graffiti. Kortom, een gebroken raam straalt iets uit dat leidt tot versneld verval. Alsof niemand meer geeft om dit gebouw. Dit verschijnsel is ook van toepassing op software, zodra je een gebroken raam aantreft in de code dan repareer of vervang je deze. Als je dit niet doet dan zal de code gaan rotten.

Abstractions Live Longer than Details

Christer van der Meeren heeft deze mooi verwoord in zijn review van het boek

Consider a requirement-oriented example: “Employee records should only be visible to their superiors” is not just a requirement; it’s mixed with business rules. “Employee records should only be visible to selected users” is a better requirement. The fact that the privileged users in this case are the employees’ superiors is a business rule which can change at any time. Implement it as metadata instead (e.g. as configuration) – you’ll be glad later on that you didn’t hardcode it into your design. But of course (and this is my opinion), as with the previous tip, abstracting everything just for the sake of it isn’t a great idea.

Conclusie

Aangezien de eerste druk uit 1999 stamt zijn sommige stukjes gedateerd. Veel van wat ze voorschrijven is tegenwoordig opgenomen in proces en pipeline. Al is dit een mooie validatie van hun visie, het komt toch een beetje oubollig over. Het opvallende is dat veel tekst nog wel van deze tijd is, dat maakt het boek lezenswaardig.

 

 

 

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *