How to Master Software Engineering (From Junior to Architect)

Key Insights

1. 1

   Mastery is a feeling of control, not omniscience

   Joris described mastery as the ability to face a new problem without feeling overwhelmed — understanding the trade-offs of different approaches deeply enough to "get it right the first time." He was clear that this doesn't mean knowing every technology; new things keep arriving and that never stops.

2. 2

   Let real requirements drive your learning

   Rather than studying technologies for their own sake, Joris lets the needs of real projects decide what he digs into. Building an integration platform, for example, forced him to learn circuit breakers, retries, observability, and containerization — the work itself pointed the way.

3. 3

   Professional drive beats hobbyist curiosity

   Joris noted his motivation has always been professional ("we're going to solve this issue in the best possible way"), not a love of computers for their own sake. He gave quantum computing as an example of an interesting topic he won't sink time into because it isn't tied to his actual work.

4. 4

   Start with the basics of your language

   He sees many developers who never grasped the fundamentals of the language they use, which limits both what they can express and their ability to read others' code. Learning the basics properly is the foundation everything else builds on.

5. 5

   Read other people's code, especially good frameworks

   Joris credited reading the source of well-authored open-source frameworks (Spring, in his case) as teaching him a tremendous amount — not just how it works, but recurring patterns he could apply to new domains.

6. 6

   Don't try to be an architect on day one

   He argued juniors should start by building functionality and leave build, deployment, and operations to others at first, then absorb those layers over time as needs arise. Trying to think about everything at once is simply too much.

7. 7

   Pragmatism: match the solution to the context

   Joris stressed understanding the context you're in. A mission-critical system maintained for years deserves rigor; something that will be replaced in a year does not. Applying the same heavy principles everywhere is a mistake.

8. 8

   Communication only works when backed by depth

   Both speakers agreed you can't just be a good communicator — technical people have a "bullshit detector." Joris persuades experienced engineers by always explaining his reasoning and goals, getting people on board with arguments rather than mandates.

9. 9

   Ship something working early — that's why big projects fail

   Joris said big projects fail because teams are "80% there" for months. Getting something working early lets you iterate, build confidence, and bring skeptics along in baby steps. He's even stopped estimating individual stories on his integration project.

10. 10

    Outsourced expertise leaves you unable to verify the work

    He warned that organizations across government, healthcare, and IT have outsourced so much that they can no longer even verify the work they pay for. His takeaway: managers still need genuine hands-on understanding of what they manage.

11. 11

    Integration is where much of the work is heading

    Joris pointed to SaaS and AI providers hiring "forward deployed engineers" — essentially integration engineers. He framed integration patterns (sync vs async, HTTP/WebSocket, message-oriented middleware, pub/sub vs point-to-point) as a strong path from senior developer toward architect.

12. 12

    Own what you build — and deploy fast

    He argued you should be able to see your software running in production; companies that break that feedback loop cap your growth. He also challenged overvaluing pre-production testing: with good CI/CD and access, he fixed a production bug in about 20 minutes, and frequent small deploys are easier to reason about and fix than rare large ones.

Chapter Breakdown