De verplichte literatuur van Carl

De meeste artikelen op deze lijst staan er omdat ze een punt maken dat ik belangrijk of inzichtelijk vind over het creëren van goede software. Sommige punten versterken mijn eigen mening over bepaalde zaken (bijvoorbeeld dat ORM's slecht zijn en frontends simpel zouden moeten blijven). Je zult het er misschien niet mee eens zijn, maar hopelijk haal je er iets waardevols uit, al is het maar dat je concludeert dat je het precies anders ziet.

Deze artikelen zijn technisch; als je geen programmeur bent, zul je ze waarschijnlijk niet interessant vinden. Omdat deze lijst overweldigend kan zijn, heb ik mijn favoriete artikelen gemarkeerd met een ster (⭐) en een korte samenvatting geschreven van waarom ik elk artikel belangrijk vind.

Coding practices

  • ⭐ The Grug Brained Developer

Als ik slechts één artikel aan zowel beginnende als ervaren programmeurs kon aanbevelen, dan zou het dit zijn. Complexiteit is slecht.

  • The Wrong Abstraction

Het is erg verleidelijk om codeduplicatie te zien en deze onmiddellijk te willen elimineren door het te consolideren. Dit essay is aangepast uit een presentatie uit 2014 over het herstructureren van objectgeoriënteerde code en bespreekt situaties waarin dit wellicht niet gepast is. Je moet dit begrijpen om effectief tegenstand te bieden aan coding agents die overal gemotiveerd zijn om een "single source of truth" te creëren.

  • Complexity Budget

Wanneer projecten te complex worden, lijkt de voortgang plotseling stop te zetten. Dit essay gaat over het begrijpen van dit fenomeen en het proberen uit te stellen zolang mogelijk.

  • Locality of Behavior

Programmeurs (en coding agents) proberen vaak Separation of Concerns (SoC) te bereiken of hergebruik van code te elimineren door talloze helperfuncties te maken. Er is een afweging tussen dit en Locality of Behavior, een principe dat ons aanmoedigt om het gedrag van code zo duidelijk mogelijk te maken wanneer men alleen naar die ene unit kijkt.

  • Yagni

Het creëren van speculatieve functies met het oog op de toekomst is in principe altijd een slecht idee.

  • Parse, Don’t Validate

Dit vereist wat inspanning om te begrijpen, maar het basisidee is dat als je zeker weet dat een stuk data een bepaalde eigenschap heeft, je die eigenschap direct in het type van het object moet coderen. Hierdoor zullen codeaanpassingen die de bewering schenden typefouten geven tijdens het compileren, in plaats van waardefouten tijdens de runtime.

Platform

  • ⭐ Steve Yegge’s Google Platforms Rant

Hier staat een enorme hoeveelheid goede informatie in, vooral over toegankelijkheid en het inrichten van softwareorganisaties. Ik raad niet aan dat elk bedrijf het "Bezos-mandaat" afdwingt, maar je moet kritisch nadenken over de vraag of je de functies van je service op een programmatische manier beschikbaar kunt stellen aan andere teams. Bovendien is het simpelweg leuk om te lezen.

Frontend

  • ⭐ HATEOAS

In webapplicaties wordt de status (state) vaak gecodeerd en opgeslagen los van zowel de frontend-markup als de backend (bijvoorbeeld met useState in React). Vaak is het logischer om de state en de toegestane acties van de gebruiker direct op te slaan in en af te leiden van de HTML die aan de gebruiker wordt geserveerd. Dit is nauw verbonden met het oorspronkelijke concept van een REST-API (de meeste moderne "REST"-API's volgen de REST-beperkingen overigens niet echt). Ik heb ook kort over HATEOAS geschreven op mijn eigen site.

  • Components and Hooks must be pure

Het grootste probleem dat ik zie wanneer mensen overstappen van backend-code naar React, is dat ze proberen de frontend imperatief te schrijven. Dat wil zeggen: ze proberen de computer stap voor stap te vertellen wat hij moet doen. Dit gaat meestal gepaard met overmatig gebruik van state en side-effects, wat gebruikelijk is in objectgeoriënteerd programmeren. In plaats daarvan zou de frontend declaratief moeten zijn; je vertelt de computer wat je terug wilt krijgen. Om dit te ondersteunen is (modern) React ontworpen rond een functionele programmeerstijl. Elk component is een functie, en state en side-effects worden vermeden, behalve waar ze echt noodzakelijk zijn, in welk geval hooks vereist zijn. Ik raad aan alle React-documentatie te lezen, maar als je je op één ding wilt concentreren, is dit de beste.

  • Understanding useMemo and useCallback

useMemo en useCallback zijn de meest misbruikte hooks in React (naast misschien useEffect), en zowel agents als mensen plaatsen ze graag overal. Dit artikel dient als gids voor waar ze daadwerkelijk noodzakelijk zijn.

  • Hypermedia Systems - Components of a Hypermedia System

Als je een goede frontend wilt schrijven, is het zeer waardevol om het model te begrijpen waarop HTML is gebaseerd. Dit is een geweldig hoofdstuk uit een geweldig boek dat je helpt het ontwerp van de browser optimaal te benutten, in plaats van HTML te zien als "een onhandige, verouderde markuptaal die met tegenzin moet worden gebruikt om gebruikersinterfaces te bouwen in webapplicaties die steeds vaker volledig op JavaScript zijn gebaseerd."

Databases

  • ⭐ The Vietnam of Computer Science

Ik ben een gecertificeerde ORM-hater. Ik vind ze verleidelijk voor nieuwe projecten, maar ze veroorzaken snel prestatieproblemen en verwarring. Kijk bijvoorbeeld naar dit OpenAI-artikel over het schalen van Postgres: "Veel van deze problematische queries worden gegenereerd door Object-Relational Mapping frameworks (ORM's), dus het is belangrijk om de SQL die ze produceren zorgvuldig te controleren en ervoor te zorgen dat deze zich gedraagt zoals verwacht." Dit is het beste essay tegen ORM's dat ik heb gelezen en, hoewel het lang is, raad ik het ten zeerste aan.

  • Wikipedia - The Object-Relational Impedence Mismatch

Nog wat munitie voor mijn anti-ORM-campagne. Dit is technischer maar beknopter; als je alleen op zoek bent naar de kernpunten, raad ik dit aan.

  • Introduction to PostGIS - Geography

PostGIS (en geospatiale databases) vereisen wat gewenning. Het is goed om de nieuwe datatypes te begrijpen waar je mee werkt wanneer je een kaartgebaseerde datavisualisatie bouwt. PostGIS is een geweldige database en het fundamentele datatype is geography.

  • Postgres Docs Chapter 14 - Performance Tips

Dit is een geweldig artikel om gelezen te hebben wanneer je database begint te vertragen. Weten hoe je EXPLAIN en EXPLAIN ANALYZE gebruikt, is naar mijn mening net zo belangrijk als weten hoe je een debugger gebruikt.

  • Paging Through Results

De meeste mensen gebruiken LIMIT and OFFSET bij het bouwen van pagineringssystemen. Als je door veel data pagineert, worden deze traag (vooral bij het laden van pagina's met hoge nummers). Dit is een goed overzicht van enkele andere opties om dit probleem op te lossen. Ik bespreek dit ook op mijn site.

Asynchronous programming

  • A Conceptual Overview of asyncio

Veel mensen worden zomaar in asynchrone programmering geworpen zonder echt te begrijpen wat er gebeurt, en leren het gaandeweg. Dit leidt vaak tot gênant basisachtige asyncio-fouten, zoals het maken van blocking calls binnen async-functies. Dit is een goed artikel uit de documentatie dat duidelijk maakt wat asyncio onder de motorkap doet, en je zo leert hoe je het het beste kunt gebruiken.

  • What Color is your Function?

Bob Nystrom is een van mijn favoriete programmeurs-auteurs. Dit is een voorbeeld van hoe asynchrone programmeringssystemen vaak fundamentele gebreken hebben. Er is niet veel aan te doen (behalve een andere taal gebruiken), maar dit leert je ten minste dat sommige beperkingen van asynchrone programmering fundamenteel zijn en niet simpelweg een gebrek aan vaardigheid.

Encoding

  • The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Als ik dit eerder in mijn carrière had gelezen, had me dat honderden uren bespaard bij het onjuist parsen van data die van het internet was verzameld.

Books

Deze boeken hebben de manier waarop ik denk over programmeren, ontwerp en het beheren van softwareprojecten gevormd.

  • The Design of Everyday Things

Veel mensen lijken te denken dat "design" betekent dat dingen er mooi uit moeten zien. In werkelijkheid gaat design over het anticiperen op de behoeften van je gebruiker en het zo goed mogelijk vervullen van die behoeften met je product. Vaak staat deze tweede betekenis van design haaks op de eerste, en in die gevallen moet je voor de tweede kiezen. Het vroege voorbeeld van "Norman-deuren" in het boek is hier een geweldige illustratie van, samen met de ironische observatie dat de deuren waarschijnlijk een designprijs hebben gewonnen, ook al kan de auteur niet uitzoeken hoe ze werken.

  • Designing Data-Intensive Applications (O’Reilly)

Het leuk vinden van dit boek is bijna een meme geworden, maar het is echt fantastisch. Het is ook een van de weinige programmeerboeken die goed werkt als audioboek. Mijn favoriete hoofdstukken zijn 7 (Transactions) en 10 (Batch Processing). Hoewel sommigen het er niet mee eens zullen zijn, vind ik dit een geweldige introductie tot databases die je dwingt hard na te denken over wat je daadwerkelijk wilt optimaliseren in je datasysteem (zelfs als je geen miljarden gebruikers bedient).

  • Crafting Interpreters

Dit is een geweldig, bemoedigend en leuk boek dat je leert hoe je een interpreter bouwt, eerst in Java voor de eenvoud en daarna in C voor de prestaties. Hoewel je het boek kunt volgen en de Java-code direct kunt schrijven, vind ik het nog beter om te proberen de interpreter in een andere taal naar keuze te implementeren, zodat je je brein meer moet gebruiken. Ik heb Rust gebruikt.

  • Category Theory for Programmers

Hoewel dit boek wat hardcore is, is het de beste introductie in categorietheorie die ik heb gezien (al moet je, als je van rigor houdt, wellicht zelf sommige formele definities googelen). Lees dit als je goede functionele code wilt schrijven en tegelijkertijd indruk wilt maken op je collega's door termen als "functor" en "monad" te gebruiken.

  • The Mythical Man-Month

Dit boek werd gepubliceerd in 1975 (!!) en voor het laatst herzien in 1995, maar het is nog steeds ongelooflijk relevant. Sterker nog, nu programmeurs bewapend zijn met AI-tools, lijken sommige hoofdstukken (zoals hoofdstuk 4, Aristocracy and Democracy in System Design) relevanter dan ze in 1995 waren. Lees dit als je een programmeerproject wilt beheren en wilt dat het slaagt.