The Embarrassing Questions
You’ve been programming your whole life. You’ve been working professionally for 20 years. You’ve become an expert, by necessity. And yet, there are a few topics you’re supposed to know everything about—and they scare you. You’re not comfortable with them, your intuition isn’t there, and you’ve been avoiding them—your whole life.
Over time, these questions have become something to be ashamed of. But who can you ask without revealing your ignorance? Luckily, there’s Claude Code! Luckily, there’s Codex!
In fact, it is this guilt, above all, that we should examine, because it is based on implicit beliefs about what it means to “be an expert.” These beliefs are never stated outright: no one would rationally argue that an expert must have an answer for everything. Yet many of us, at times, find it difficult to say, “I don’t know.”
Belief #1: An expert must have an answer for everything
That’s the first myth to debunk. To become an expert, you have to be willing to focus on one subject at the expense of all others, because you can’t be an expert on everything. So, even if you did have an answer for everything, that could only be true within a very narrow field of knowledge. As for me, I’m completely hopeless at fixing the printer, as I’m traditionally asked to do at Christmas…
But even at the heart of their area of expertise, should we expect an expert to have an answer for everything? I believe that would be a mistake. What we expect from them is that they ask the right questions and weigh all aspects of the problem without overlooking any. This is all the more true given that they are rarely the ones who make the final decision.
Belief #2: Once an expert, always an expert
This is all the more true given that expertise becomes outdated. This has always been the case, but it’s a reality we’ve been experiencing on a daily basis since late 2022 with the advent of LLMs, which are redefining software professions and revolutionizing the Developer eXperience (to put it neutrally).
On that note, what are we to make of experts who have abandoned—some for decades—any hands-on development work? It’s hard to say anything meaningful without daily practice. This brings us back to the concept of the “thinker-doer,” so dear to Silicon Valley and perfectly articulated by Vincent Lextrait.
I believe that knowledge-sharing activities (training, but also consulting and coaching) should not be pursued full-time, or at least not over a long period. Knowledge sharing without creation quickly becomes sterile, as knowledge is no longer nourished by experience. Conversely, knowledge transmission provides creation with a reflective perspective that is difficult to obtain by other means. But when they go hand in hand, creation and knowledge transmission enrich one another.
Belief No. 3: An expert is never wrong
In mathematics, we construct proofs. In physics, biology, and even the humanities, experimentation reigns supreme (the conditions under which it is conducted may be disputed, but not its interpretation). In science, consensus is therefore possible, until a broader theory encompasses or invalidates the previous one. And there is no need for experts: there are no experts in mathematics, only mathematicians.
But software development isn’t a science; it’s a practice that draws on various sciences, starting with theoretical computer science. That’s why there’s room for personal judgment and, ultimately, a need for expertise. While the benefits of practices such as Test-Driven Development are widely recognized, everyone is free to use them or not—only the result matters. There is no single truth, no single right way to work. There is nothing to demonstrate, nothing to prove. Thus, everyone can contribute their personal opinion and exert their influence—for the better (Robert C. Martin, Martin Fowler, Alistair Cockburn, Sandi Metz…) as well as for the worse (I’ll refrain from naming names).
Few problems have a single, unequivocal solution. Most of the time, we’re navigating a gray area, weighing pros and cons. There is no certainty, only expert opinions. It’s no coincidence, in fact, that decision-makers often seek advice from multiple experts to ensure greater diversity of opinion and neutrality. This is particularly common in the insurance and psychiatric fields (expert opinions vs. second opinions). In short, experts are needed precisely because certainty is impossible.
If the expert doesn’t know everything, becomes outdated, and makes mistakes, what good is he? Precisely to make sense of uncertainty: where no one else can, he sees problems before others do, asks the right questions, and makes fewer mistakes.
It’s up to each of us, then, to find our own niche. And to align our professional activities with it, year after year. This may be the only shameful question worth asking out loud.