I’m not going to sell you a “Clean Code” training course
A deliberately provocative title, but one that couldn’t be more serious. Why? Because learning Clean Code in 2 or 3 days is like reading a dictionary or the Node.js API from A to Z: nobody does that, because it doesn’t make sense.
Don’t get me wrong: Clean Code is a wonderful thing. I love Clean Code, I think Clean Code, I live by Clean Code, and I’m a fervent advocate of it. And yet.
Let’s start by noting that Clean Code is a set of widely accepted best practices because they contribute to writing code that is understandable by humans—and therefore, in principle, easier to maintain. These are considerations regarding naming conventions, function size, and, more fundamentally, the responsibility of those functions. We come back to it again and again, all the time: the Single Responsibility Principle, a foundational principle if ever there was one.
However, as Robert C. Martin himself admits, Clean Code is somewhat like a cookbook: reading it cover-to-cover would make no sense. You can flip through the book, admire the pictures, and dream of becoming a pastry chef, but you’re not going to try every recipe in two days. You try one, tweak it, tweak it again, make it your own, and after four or five tries, you can make it with your eyes closed—a recipe that, incidentally, might no longer be exactly the one in the book. The proof: “Have I ever let you taste my tiramisu?”
That’s called experience, and in my view, it’s the only way to learn. In my view—and that of Albert Einstein, who was never one to shy away from a pithy quote that brings everyone into agreement—“Knowledge is gained through experience; everything else is just information.”
Does this mean that training is pointless?
Of course not. It’s just that while functional programming and Domain-Driven Design present themselves as a logical sequence of ideas forming a highly coherent whole, Clean Code remains a juxtaposition of rather disparate ideas: SOLID principles, Object Calisthenics, KISS, YAGNI, design patterns, various “smells,” and so on.
Furthermore, it’s worth noting that this body of knowledge was formalized by developers working primarily within an object-oriented paradigm. Some considerations are directly applicable in the functional programming world (single responsibility, interface segregation, dependency inversion), others require adaptation (Liskov’s Substitution Principle), while still others are simply not applicable (open/closed principle). Thus, Clean Code remains heavily influenced by object-oriented programming. For those who prefer functional programming, training in Clean Code might prove challenging.
All of this is to say that these topics—essential for any developer worth their salt—are ill-suited to the constrained and rigid format of a 2- or 3-day training course. My program, structured in five phases, therefore does not include “Clean Code” training. I prefer to address this topic when I’m working with companies on a medium- or long-term basis. This allows me to introduce each concept at the exact moment when the person in front of me is facing the problem… and will generally intuit the solution themselves.
So I won’t be selling you a Clean Code training course, but we’ll talk about it a lot if we work together 😊