“An alleged scientific discovery has no merit unless it can be explained to a barmaid.”,
Ernest Rutherford in Einstein, the Man and His Achivement by G.J. Whitrow
or
“If you can’t explain something in simple terms, you don’t understand it”
Richard Feynman
Some version of the famous quote has been attributed to a lot of different people.
Explaining things to other people is a wonderful way to test how well you understand it yourself and then to use that explaining task as a vehicle to learn more about the topic. Explaining things in a way which another person understands it is hard. We run into misunderstandings with fellow people all the time even in day-to-day life and when we shift the context to teaching, it becomes even more apparent.
Explaining being difficult makes it an excellent tool. I’ve noticed many times in my life that I’ve learned or achieved something, only to notice later that I didn’t actually learn it or understand how I achieved it. In my context, that is often software development. It’s very much possible to stumble into a right(-ish) solution without knowing why.
Sometimes that (-ish) part is what makes it scary. You might think you got it right but due to the lack of full understanding, you’ve introduced a hard to discover bug that can have major negative impact to users.
In 2019, I delivered a talk I teach, therefore I learn in multiple events. The talk was about how I had become a better software developer through the act of teaching others software development. We can think of teaching in a traditional classroom situation or as blogging, mentoring and delivering talks and the same truths apply.
The act of teaching (and more accurately, the act of preparing to teach) forces us to discover the knowledge gaps, fill them and improve our communication skills to a level where we know enough to confidently, comfortably and successfully transfer that knowledge from our mind to another mind.
Henrik Jernevad has a brilliant way of phrasing it in the blog post If you can’t explain it, you don’t understand it:
I think the magic comes when you need to put words to things. It is quite easy to have a vague picture of something in your mind without realizing how vague it actually is. Putting things in words exposes that vagueness.
This is spot on. Words make thoughts tangible. It’s easy to get fooled by the vagueness of ideas in your head but forging them into tangible words requires you to tame those thoughts and reveal the missing knowledge.
I consider writing notes a tool for thinking. Whenever I learn something new, I make a note of it. To be able to make a good note that’s helpful for me in the future, I need to turn my learnings from thoughts into words. It’s a great habit that ensures I’m capturing my learnings in more effective ways than just letting them pass into the wind once I’m done. I can then use those notes to write blog posts or refer to them when explaining them to a colleague or a mentee.
In December 2024 I spent once again a month writing explanations and notes for my Advent of Code solutions. I do it because I like to share my knowledge and learning and help other people to learn Python and puzzle solving and maybe get them excited about Advent of Code too.
The secret is, those explanations are my litmus test to see if I understand why my code produces the correct outcome. Or if I failed to reach a solution, I write to see if I understand where I fell short.
Even if you never explain the topics you learn about to others, start a habit of explaining them to yourself. Write those explanations down. If there’s something you can’t quite explain, research it more.
You can write them down to a paper notebook or a digital notes app. But it must be written down, otherwise it stays vague and your brain lies to you about how much it understood.
Once you start writing them down, you start building a personal knowledge base that will be helpful in the future. And the little extra effort you make to research to fill the gaps in your understanding strengthens your skills even if you never end up going back to that note in the future.
In Deliver Sessions: Outcomes, outputs, other things, Neil Vass sums up his experience of giving talks:
The act of just getting a talk planned helps summarise and bring together exactly what you’ve learned or would recommend about a topic. Years ago, I summed up all my best advice about stakeholder management in a “how to disappoint people” talk, and looking back at that still helps me remember lots of lessons that I learned years ago but had forgotten about. I’ve got similar reflections on how to use estimation, Objectives and Key Results, and other topics – even if I never gave these talks in front of anyone, the reflection and pattern-spotting from writing them was such a useful activity.