I have worked with a lot of developers over the years. Over the years, I have noticed a pattern. Some developers light up when they talk about the internals of a programming language. A new feature in the type system, a clever way to handle concurrency, an elegant pattern they discovered. The technology itself is what drives them.

Other developers are different. They care less about how the language works under the hood. What gets them going is the customer's problem. They want to understand what hurts and build something that makes the pain go away. The programming language is a tool. A means to an end.

Two ends of a spectrum

These are extremes. Most developers sit somewhere in between, and where you sit probably shifts depending on the project, the phase, or even your mood that week. But most people I have met tend to lean the same way over time.

You can probably think of more axes like this. How someone relates to teamwork versus solo work. Whether they prefer building from scratch or maintaining existing systems. It is probably more of a star with many points than a single line. But the technology-versus-problem axis is the one I keep coming back to.

We need both

The technology-focused developers push things forward. They understand the tools deeply, find better ways to use them, and build foundations that others rely on. Without them, we would all be stuck with blunt instruments. Take virtual threads in Java. Someone had to rethink how the JVM handles concurrency, redesign the scheduling, and make it all work without breaking existing code. That is impressive, deep technical work. I am glad they did it. But I just want better threads. I want my application to handle more concurrent users without falling over. How the JVM achieves that is not what keeps me up at night. The customer's problem is.

The problem-focused developers make sure we are building the right thing. They ask the uncomfortable question: does anyone actually need this? They sit with customers, listen to what is going wrong, and translate that into something a team can build. The risk is building impressive systems that nobody asked for.

Where universities come in

Universities teach computer science. They teach algorithms, data structures, programming languages, compilers, operating systems. They are good at this and it matters. Students need a technical foundation.

But universities do not have customers. They do not have a business that depends on understanding what a specific group of people actually need. They cannot simulate the experience of sitting in a room with a frustrated user who cannot articulate what is wrong, only that something is not working. That kind of learning happens on the job, if it happens at all.

The result is that universities end up producing developers who lean toward the technology end of the spectrum. Not because that is what students want, but because that is what a university can teach. The problem-solving orientation is harder to teach in a classroom. Students solve exercises with well-defined inputs and expected outputs. They do not get to sit with a confused customer who knows something is wrong but cannot explain what. Some people pick it up through experience or bring it with them from previous careers. Some never develop it at all.

My concern

I think we are short on problem-focused developers. The industry celebrates technical skill in visible ways. Conference talks about language features, open source libraries, clever architectures, new frameworks. Job postings that list specific technologies rather than the ability to understand a business domain. The signals all point toward the technology end.

Meanwhile, the developer who spends an afternoon with a customer, figures out that the real problem is different from the one described in the ticket, and saves the team two weeks of building the wrong thing? That work is mostly invisible. It does not end up in a tech conference talk. It rarely shows up in a performance review. You might hear about it at an agile conference, but I stopped going to those. They used to be about agile software development, with technical practices on the agenda. That does not seem to be the case anymore.

I place myself closer to the problem end. My background in Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) has pulled me there over the years. Both practices force you to think in concrete examples, and those examples have to come from somewhere. They come from the customer domain. When you write a test that says "a customer with an expired subscription should see a renewal notice," you are not thinking about the programming language. You are thinking about what the customer needs. The technology becomes secondary to getting the behaviour right.

I do not have a solution. I am not going to tell universities what to teach. But the imbalance is there. When you hire, think about what your team actually needs. When you mentor junior developers, help them see that understanding the customer's problem is a skill, not a distraction from "real" programming.

Where do you sit?

If you are reading this, you probably have a sense of where you fall on the spectrum. Neither end is wrong. But if you have never thought about it, maybe take a moment. And if you find yourself always reaching for the technology, try spending a day just listening to what the customer actually needs. It might change how you think about the code you write.

Resources