From Executors to Problem Solvers: Rethinking Developer Training

We are taught to code as if we were assembling furniture with step-by-step instructions. A framework here, a recipe there. It doesn’t matter if it’s a bootcamp or a university degree: the script is often the same. Closed exercises, textbook projects, solutions that fit neatly into an exam. In the end, training developers often looks like producing executors who can follow a checklist.

The problem is that real life never comes with such clear statements. You don’t join a company to solve katas, you join to face an old system that’s been patched by dozens of hands over years. And there, syntax isn’t enough: you need to understand what the system does, why it does it, and what will happen if you touch it. Nobody prepares you for that feeling of opening someone else’s code and realizing you’re translating hieroglyphs.

The same happens with the fundamentals. Many bootcamps rush to teach React or Node and skip the basics: how JavaScript really works, what a data structure means, how to build the house from its foundations. And without foundations, the castle shakes. Some argue: “they’ll learn on the job, the important thing is to hit the market fast.” Fair enough, though it’s worrying to think we reduce training to a sprint when what we actually need is endurance.

Beyond technique lies the business, the logic that gives meaning to it all. Writing a login might be a fun exercise… until you remember it’s not the same to build it for a bank as for a cat forum. The function looks identical, but the decisions behind it are worlds apart. Without that information, the developer becomes someone nailing windows into a house without blueprints: the job is done, but what’s it for?

Some say devs shouldn’t worry about that, that’s what analysts and architects are for. Others believe that without context, creativity, quality and sometimes even common sense are lost. The question is not whether every developer should become an architect, but whether everyone should at least have access to the map of the building.

And then comes what is rarely mentioned: documenting, communicating, explaining. We’re taught to write code, not to make it clear for whoever reads it tomorrow. Yet the difference between a team that moves forward and one that sinks is often something as simple as a well-written README or a well-explained decision.

In practice, nobody trains you to translate technical into human language. And still, every project succeeds or fails as much by the quality of code as by the clarity of the conversations around it.

Here another tension emerges: should everyone do this, or is it enough if a few do it well? There’s no single answer, but the question matters. The same dilemma applies to value in software. What’s worth more: perfect code that nobody uses, or a messy workaround that solves a real problem?

Academia rewards technical elegance; business rewards working solutions. Where’s the balance? Maybe in accepting that code is not an end in itself, but a means. And that there’s also room for enjoying technical beauty even if it brings no immediate value. Sometimes we code out of necessity, other times for pleasure. Not everything useful is beautiful, but not everything elegant is useful either.

And finally, the most human part: questioning, asking, refusing to take things for granted. In classrooms, the ones rewarded are often those who repeat the “right” answer. But in real life, the best developers I’ve met are the ones who raise their hand and say: “I don’t understand, explain it again.”

Not to annoy, but because they know that behind every dogma might hide a mistake. Of course, too much questioning can stall a team, so the real debate is: how far do you question without blocking progress?

If there’s a paradigm shift, it’s not about jumping from one language to another or following the latest hype. Not microservices today, serverless tomorrow. It’s something deeper and simpler: stop training only executors, and start leaving space for problem solvers.

Not as an obligation, not as dogma, but as a possibility. Let some people just enjoy writing code without looking further, and let that be respected as much as the ones who need to grasp the business logic to feel involved.

Maybe the real change is cultural: giving developers access to the questions that give software its meaning. Not just tickets, but context. Not just obedience, but understanding. Normalizing—even valuing—that a dev raises their hand and asks: “why are we doing this?”

There’s no single right way. Some say developers should just code well. Others say without business logic all effort is wasted. Both are partly right, and it’s in that tension where things get interesting. The richness is in each team, each company, each person finding their own balance.

This is not a manifesto of absolute truths. It’s an invitation to think differently. To see developer training not just as transferring techniques, but as opening a space for curiosity, critique and diverse approaches.

Because in the end, what makes a dev team strong is not that everyone thinks alike, but that each brings different questions to the table.

And perhaps in that diversity of thought lies the true value of our profession.

R. Adams