From Junior to Architect: Joris Kuipers on Mastering Software Engineering

What does it actually mean to master software engineering when the field never stops changing? On the Beyond Coding podcast, host Patrick Akil put that question to Joris Kuipers, CTO and hands-on architect at Trifork with more than 25 years in the industry. The answer wasn't a list of technologies to memorize — it was a way of working, learning, and thinking that compounds over a career.

Here are the threads worth keeping. Everything below reflects what Joris and Patrick discussed in the episode.

Mastery Is Control, Not Omniscience

Joris defined mastery as the feeling of being in control when a new problem lands on your desk — not overwhelmed, but able to map out alternatives, weigh their trade-offs, and "get it right the first time." Crucially, he was emphatic that this does not mean knowing everything. New technologies keep arriving, and that pressure never goes away. What changes is your disposition: a deep core gives you the confidence to absorb the new without drowning in it.

He tied that confidence to a specific habit — diving into a topic until he genuinely understands it, a pattern he's had since learning enterprise Java in 1999, when you had to learn a lot just to build something simple. The combination he kept returning to was curiosity plus persistence, "a piece of discipline and comfort in being uncomfortable."

Let the Work Decide What You Learn

One of the most practical ideas in the conversation was letting real requirements drive your professional development. Joris contrasted his current job with earlier consulting work where downtime left him staring at "5,000 things I could research" with no signal about which mattered. Today, building a large integration platform with 40-plus backends naturally tells him what to learn next: circuit breakers, retries, observability, dashboards, containerization, Kubernetes.

He was honest that this is partly temperament. He's professionally driven, not a hobbyist who wants to learn every language for fun. Quantum computing came up as a genuinely interesting topic he still won't invest heavily in, simply because it isn't connected to his actual work. The lesson isn't to ignore curiosity — it's that professional requirements are a better compass than curiosity alone.

Start With the Basics, Then Read Real Code

Asked where a newcomer should begin, Joris didn't hesitate: the fundamentals of your language. He sees too many developers who never grasped the basics, which limits what they can express and makes reading other people's code harder. And reading other people's code — especially well-authored open-source frameworks like Spring — is one of the things he credits most for his own growth. It teaches patterns: you notice the same approach applied across different domains and internalize it.

He also pushed back on the pressure to be an architect immediately. Thinking about code, builds, deployment, runtime, and observability all at once is too much for a junior. A natural path is to start with functionality and absorb the other layers over time, because eventually no one else is there to handle them for you. He warned specifically about juniors at tiny startups who "do everything" and end up broad but never deep.

Pragmatism and the Bullshit Detector

If mastery was the first pillar, pragmatism was the second. Joris insisted on understanding the context: a mission-critical system maintained for years earns rigor, while something destined to be replaced in a year does not. Applying heavy principles everywhere is its own mistake.

That pragmatism extends to how you persuade people. Both speakers agreed that communication alone isn't enough — technical people have a finely tuned "bullshit detector," and if you don't have real depth, they'll know. Joris's approach, honed while telling 25-year veterans at a Dutch financial regulator how to work differently, is to always explain his reasoning and goals and bring people on board with arguments, not mandates. The fastest way to win trust, he said, is to get something working quickly and iterate, rather than disappear for months. That's also why big projects fail: everyone's "80% there" for months until it collapses.

Expertise You Can't Outsource

A recurring worry in the conversation was the hollowing-out of expertise. Joris described how governments, healthcare, and IT have outsourced so much that organizations sometimes can't even verify the work they pay for — managers treated as generic process managers who don't need to understand what they manage. His counterpoint: even as a CTO, you need genuine hands-on experience of what it means to work in IT, or you simply can't lead it well. The same applies to sales — you can't credibly sell custom software you don't understand.

Where the Work Is Heading: Integration and Ownership

Looking forward, Joris sees integration as a growing center of gravity. SaaS and AI providers are hiring "forward deployed engineers" — integration engineers by another name — who embed in organizations to make systems talk to each other. He framed integration patterns as a strong route from senior developer to architect: synchronous versus asynchronous, HTTP and WebSockets, message-oriented middleware, point-to-point versus pub/sub. Cloud has made much of this a toggle (Kafka, RabbitMQ, managed queues), though he cautioned that easy infrastructure also tempts teams to over-engineer resiliency they don't need.

The episode closed on ownership and speed. You should be able to see your own software running in production, Joris argued; companies that break that feedback loop — where developers can't even view production logs — quietly cap people's growth. He also challenged the instinct to over-invest in preventing every production issue. With solid CI/CD and the right access, he fixed a real production bug in about 20 minutes before a holiday. Frequent, small deploys are easier to reason about and fix than rare, large ones, which makes fast deployment a form of resilience, not a risk to it.

The Takeaway

Mastering software engineering, in Joris's telling, is a long and sometimes hard path — but a learnable one. Build solid fundamentals, let real work guide your learning, pair depth with honest communication, own what you ship, and put yourself in environments where interesting problems and generous colleagues let your growth compound. As he put it, once you're past the basics, learning the next thing only gets easier.

---

Originally published on Beyond Coding. Watch the full episode: https://www.youtube.com/watch?v=pNtkOZuWetg