# Make mistakes!

> Mistakes as a teaching principle: they’re necessary for a deep understanding of problems, and they give meaning to best practices.

- Author: Mathieu Eveillard
- Published: 2022-07-20
- Updated: 2025-09-20
- Tags: Coaching, Learning
- Canonical: https://www.mathieueveillard.com/blog/pedagogie-de-l-erreur/
- Translation (fr): https://www.mathieueveillard.com/fr/blog/pedagogie-de-l-erreur.md

![Make mistakes!](https://www.mathieueveillard.com/blog/2022-07-20-pedagogie-de-l-erreur/pedagogie-de-l-erreur.webp)

What does Warren Buffett have to do with this? You’ll soon understand.

“We learn from our mistakes”: we’re all on board with this idea, even if it’s sometimes a little hard to swallow in the moment 🥲 Warren Buffett is said to have remarked, not without a touch of mischief: “It’s good to learn from your mistakes. It’s better to learn from the mistakes of others.”

That guy’s no fool.

So mistakes are useful. This means that if they happen, we need to learn from them. But does that mean we should actually want them to happen? Should we go so far as to provoke them? 😵‍💫

My answer is “yes.” Well, “yes” to a certain extent. **In a safe environment, making mistakes is desirable because it helps us recognize the difficulty** and encourages us to articulate the problem we’re trying to solve. After all, why Test-Driven Development (TDD)? Why functional programming? Too often, we turn to these concepts simply because they’re considered best practices, without ever truly feeling the need for them on a _deep_ level ourselves.

You have to have spent four hours hunting down a bug and having to unravel everything to understand the need for rapid feedback on the code (hence the importance of type checking, hence the importance of TDD). You have to have introduced regressions in production to understand the importance of programming without side effects and to learn to write pure functions, not because you _have_ to, but because you _want_ to.

But let’s take it a step further: ideally, we should even be on the verge of reinventing a concept in order to truly understand its necessity. Galileo put it better than anyone:

> You cannot teach a man anything; you can only help him discover it within himself.

So there is no learning without error, or at least no learning without trial and error, and the instructor must take advantage of this by encouraging it to happen. But not just any old way, of course. It’s out of the question to do this on production code; that’s what coding exercises (katas) are for.

The [Diamond](https://github.com/mathieueveillard/diamond) kata is the perfect illustration of this. After a few successful TDD exercises ([FizzBuzz](https://github.com/mathieueveillard/fizzbuzz), [Leap Year](https://github.com/mathieueveillard/leap-year), [Fraction](https://github.com/mathieueveillard/fraction)…), confidence sets in, along with the idea that all we have to do is let the methodology guide us and things will fall into place on their own. And that’s when disaster strikes. I won’t say any more (it’s up to you to experience it for yourself), but this kata is a trap. An essential trap for truly understanding what TDD is and what it can offer you.

At the risk of sounding categorical, I would therefore say that **as long as there has been no mistake, there has been no learning**. In poker, we talk about “beginner’s luck”; in software, we say “it works, don’t ask me why.” In both cases, we haven’t learned anything.

In the coaching sessions I offer, I make sure that developers experience the difficulty firsthand. In other words, I push them to make mistakes. Once they’ve experienced the difficulty and formulated the question, the answer becomes obvious.

But then again, someone said it long before I did:

> If I had an hour to solve a problem, I would spend fifty-five minutes defining the problem and only five minutes finding the solution.

— A. Einstein