Wat onderscheidt een goede programmeur van een goede software engineer?

Question

Accepted Answer

Een **goede programmeur schrijft werkende code**. Een **goede software engineer lost het juiste probleem holistisch op** — met eigenaarschap over vereisten, ontwerp, afwegingen, onderhoudbaarheid, testen, operations en de zakelijke context rond de code. Engineering is code plus oordeelsvermogen plus verantwoordelijkheid over de hele levenscyclus.

## Waar de lijn werkelijk ligt

Code schrijven die de tests doorstaat is het makkelijke, leerbare deel. Het moeilijkere, waardevolledere deel is alles eromheen: bepalen *wat* je gaat bouwen, *hoe* het in het systeem past, en *wat het later kost* ermee te leven.

- **Een programmeur vraagt** "Hoe zorg ik dat dit werkt?" en stopt wanneer het werkt.
- **Een engineer vraagt** "Welk probleem lossen we eigenlijk op, wat zijn de beperkingen, en wat is het goedkoopste ontwerp dat verandering overleeft?"

## Waar de engineer eigenaarschap over heeft buiten de code

- **Vereisten** — verduidelijkt de echte behoefte, stelt vragen bij de spec, brengt randgevallen naar voren voordat ze incidenten worden.
- **Afwegingen** — weegt snelheid tegen eenvoud, bouwen tegen kopen, nu tegen later, en maakt de keuze *expliciet*.
- **Ontwerp & onderhoudbaarheid** — schrijft voor de volgende lezer, houdt de impactzone klein, vermijdt toevallige complexiteit.
- **Testen & operations** — denkt na over faalscenario's, observeerbaarheid, terugdraaien, en wat er gebeurt om 3 uur 's ochtends.
- **Communicatie** — legt beslissingen uit, documenteert ze, en neemt anderen mee.
- **Zakelijke context** — koppelt het werk aan resultaten, niet alleen aan gesloten tickets.

## Een nuttig nuance

Dit gaat **niet** om anciënniteit of functietitel — veel "engineers" programmeren, en sommige "programmeurs" engineeren. Het is een **mentaliteit**: verantwoordelijkheid nemen voor het resultaat, niet alleen voor de output. De verschuiving is van *"mijn code draait"* naar *"dit systeem vervult zijn doel, betrouwbaar, en zal degene die het volgende aanraakt niet straffen".*

## Waarom het belangrijk is

Gesprekspartners en teams waarderen de engineer boven de programmeur omdat **bugs, storingen en onderhoudsonvriendelijke systemen zelden voortkomen uit code die niet compileert — ze komen voort uit ontbrekend oordeelsvermogen**: de niet gestelde vraag, de genegeerde afweging, het niet geteste randgeval. Aantonen dat je nadenkt over de hele levenscyclus — en kunt uitleggen *waarom* je voor het ene pad boven het andere hebt gekozen — is wat aangeeft dat je kan worden vertrouwd met echte systemen en echte gevolgen, wat precies is waar groei in dit vak om gaat.