Learning Software Architecture: Build First, Read Second
The post
matklad's essay on learning software architecture made the HN front page this week — 147 points at the time of writing. The thesis is straightforward: architecture isn't a thing you learn by reading books about hexagonal patterns and CQRS. You learn it by shipping something, watching it fail in a specific way, and noticing the same shape of failure when it shows up again later.
Why this is the right framing
Books teach the vocabulary; production teaches the consequences. A junior engineer who can recite the difference between event sourcing and CRUD has knowledge. A senior engineer who can tell you, in 30 seconds, why event sourcing was the wrong call for the project they shipped two years ago has understanding. The gap is closed only by exposure to outcomes.
Why this matters for KYAX clients
We see this gap most acutely when clients hire for "senior architect" roles. The job description usually lists patterns ("must know microservices, event-driven, DDD"). The actual need is judgement — knowing when to *not* split the service, when to *not* introduce the message bus. Our hiring advice: weight a candidate's "tell me about a system you shipped that failed in production" answer over their "tell me about your favourite pattern" answer. Read matklad's post for the case made well.
---
*Source: [matklad (via Hacker News)](https://matklad.github.io/2026/05/12/software-architecture.html) — matklad, 2026-05-12. Commentary is original to KYAX.*