Bo FreseThe first question isn't just what and how.
I also ask why we're writing it, who it serves, and whether there's a simpler path. That's not a separate conversation — it happens at the keyboard.
The question nobody's asking
Business stakeholders express problems specifically. That's their job — they know what they see on the screen, what the user complaint said, what the competitor shipped. What they don't see is whether solving that specific problem is the right move, or whether there's a simpler and more general solution underneath it that's faster to build and easier to maintain in three years.
That gap is where I work. The first thing I want to know when I pick up a ticket isn't how to implement it — it's why it exists. Who does this help? What would happen if we didn't build it? Is there a simpler version that gets 90% of the way there?
If the answer isn't in the room, I find out who has it.
Sometimes what gets built changes. Sometimes it doesn't. But the question always matters — because a codebase built on unchallenged requirements is a codebase full of solutions to the wrong problems.
Getting better products faster doesn't come from developers typing faster. It comes from questioning what you're building — and finding the simpler path.
— Bo Frese
The abstraction skill
Business requirements are always specific. "Make it behave like this, on this screen, for this user." That specificity is right — it's what they can see. The developer's job is to extract what's underneath: the pattern, the generalisation, the concern that can be separated from the rest.
Finding the right abstraction is not a formula. It's an art that takes a long time to develop. I've seen less experienced developers eagerly build large frameworks to solve simple problems. I've seen developers who solve only the exact problem in front of them, leaving the codebase slightly more tangled each time. The judgment to know which is which — when to generalise and when not to — takes decades to calibrate.
Two examples, both old enough to name:
Working with the Hubble Space Telescope programme, I built a web-based toolkit to make astronomical data available to European astronomers. At the Space Telescope Science Institute in Baltimore, a team of ten had been working on the same problem for years — their solution required special hardware on the user's end. A web-based alternative hadn't been tried. The head of development later told me mine solved 80% of their problem.
At the Danish Post, the architect had modelled the solution on what they could see from their desk: the mail distribution centre next door, with individual letters sorted into envelopes and routed through stages. The integration reflected that metaphor — workflows, XML envelopes, dedicated servers, custom error handling. We replaced it all with a database import and an outer join. Months of work by several people, replaced in a few days.
I can't name recent examples. Most current work is under NDA, and I simply don't disclose client details regardless. But the pattern is the same: I tend to see problems and solutions where others don't. Probably because I've been exposed to every part of product development since early in my career. Probably because connecting the dots across layers — business goals, architecture, code — comes naturally. Probably because I've always wanted to understand the world I'm embedded in, not just the ticket in front of me.
I have deep experience in a number of domains — and I genuinely love landing in a new one and learning it from the inside. That's one of the things I enjoy most about this work. But there's something else I bring alongside it: a pattern library built across very different contexts. Most innovation isn't new invention — it's a solution from one domain, recognised and applied somewhere it hasn't been tried. I've worked across finance, telecom, broadcast and IPTV, healthcare, transportation, energy, engineering, and science/astronomy. Deep domain knowledge is essential, and I work best alongside people who have it. What I add is a different kind of seeing: the current problem in the light of a dozen others.
AI amplifies what's already solid and compounds what isn't. I work with AI-assisted development where it helps, with the discipline to know where it doesn't. And whatever the tool produces, it's us — the human developers — who have to understand it, own it, and take responsibility for it. That doesn't change with the prompt. That judgment — like the abstraction judgment — doesn't switch off when I'm in developer mode. It's always in the room.
What real teamwork looks like
The best work I've done has never been solo work. It's been inside teams where ideas emerge from conversation and nobody can honestly claim ownership of the result — the only true thing you can say is "we did it."
Getting there is cultural work. In many teams the default is individual contribution: my ticket, my code, my estimate. Shifting that — to a team that completes each other's sentences, challenges anything, feels genuinely safe to do both — takes time. Sometimes it's a large shift. But it's where the real gains live, and where I do my best work.
I bring 35 years of experience across every layer. I still write production code. I don't come in with a framework to impose or a methodology to sell. I come in as a developer who also understands what the code is for, who it serves, and what the organisation around it is doing to help or hinder it. The architecture question and the product question belong with the people writing the code — not handed to someone else to decide.
Who this is for — and who it isn't
Some organisations want a developer who executes quietly. Someone who takes the ticket, builds what's specified, and doesn't ask uncomfortable questions about whether it's the right thing to build or the right way to build it. I understand that need. I'm not the right person for it.
I'm the right person for a team that wants to build better — not just build more. That's willing to have the why conversation before the how one. That's ready to be challenged, and to challenge back.
If that's where you are, we'll do good work together.