A problem, a solution
A train leaves Paris at 6 a.m. and travels at 56 km/h. Another train leaves Lyon at 8 a.m. and travels at 69 km/h. Given that the distance between Paris and Lyon is 512 km, at what time will the trains pass each other?
This problem is beautiful—too beautiful. No ambiguity, a single solution. That’s what we’re taught from first grade through senior year. Yes, we do need to teach some mathematical basics—how to set up an equation and then solve it. And then systematically assign a grade. That’s more debatable, but that’s not the point.
Except that real life is the exact opposite.
Moving Beyond School-Based Thinking
Your daily life, like mine, looks more like this:
- We know there’s a problem but can’t quite put it into words (e.g., meeting GDPR requirements without breaking system-wide modularity);
- We don’t know if there’s a solution. In fact, there’s always one—or even several—but they don’t satisfy all the constraints and require serious compromises.
- And so you don’t know which one to choose.
With all that, we’re still nowhere near a solution. And the fact that the two trains pass each other at 11:12 a.m. isn’t going to help us much!
So after years of laying the groundwork—which remains essential—the main challenge of higher education is de-schooling. In other words: learning a less academic way of thinking, in order to prepare for a VUCA world.
The whole challenge lies in analyzing the problem: identifying the components at play, the levers for action, and prioritizing based on business imperatives. Pragmatism then becomes an essential quality.
In the end, we always come back to Einstein, who said it all before anyone else:
“If I had an hour to solve a problem on which my life depended, I’d spend the first 55 minutes figuring out the best question to ask myself, and once I’d found it, it would take me just 5 minutes to answer it.”
Taking the Collective Dimension into Account
Let’s add the collective dimension at this point. Perhaps solution A is better than B in absolute terms. But if there’s no consensus on it, it’s useless, and maybe solution B is better than no solution at all.
This is very evident in a codebase: there’s no single solution—just divergent practices, like “that’s Martin’s code” and “that’s Martine’s code”. Taking over someone else’s code then becomes very difficult.
It’s therefore better to have a shared practice—even if it’s imperfect—than divergent practices: it will always be easier to refactor. The best solution is, above all, the one that works for the individuals and the team.
When I coach teams, I focus on fostering an organizational and technical consensus (regardless of my own opinion on the matter). My role is to facilitate decision-making, even if the decision isn’t the one I would have preferred.
If a developer does TDD (Test-Driven Development) “because the coach asked me to”, that would be a failure in my book (see Martin Fowler’s excellent article on this subject). I’d rather be told “honestly, it’s not my thing”—at least then the discussion is open.