I got a real beef with some popular programming guidelines and the way they are presented and interpreted by many of my industry colleagues. I’ll not dive into details about the concepts and ideas themselves (that’s for another post), but rather talk about how their communication can be harmful to the industry.
Concepts such as Clean Code, TDD and SOLID are frequently perceived as inflexible laws that dictates “how things should be done”, which can’t come as a surprise when we look at how these concepts are presented: a set of somewhat strict guidelines, almost as rules and even named as “principles” which is presumptuous at the very least.
This ideas are also presented in a way that sounds reasonable and simple without ever mentioning or considering any potential drawbacks or trade-offs, which should be the first red flag to any engineer. Though the experienced engineer can smell the problems with such dogmatic recommendations, this is not true to the unexperienced one.
When learning this concepts while being new at the craft it’s easier to accept something as a general rule or good practice, especially when its communication is designed to sound like a dogma. This can be especially appealing to young developers, since this ideas can bring some relief to one of their biggest angst, which is “how to have a way of identifying if the code I’m writing is right”.
New developers also lack the necessary experience to be able to reason about an idea while considering the whole context. Consider a young developer who never had to debug a program. He is able to understand and reason about some practice or idea only to the extent of his experience, so he’ll fail to consider the implications that this said practice has in debugging.
With such fit, many young developers start using this ideas as rules to follow and goals to achieve when writing code, and equipped with inflexible adages they start to trap themselves without even noticing. Suddenly it’s not about solving a problem, but about following all dogmas without breaking any sacred rule.
As a tangible result of this all this non-sense, young developers will often forget that the program is just a main function. They’ll go straight into using fancy abstractions before solving any problem, which leads to unnecessary complexity. And when the code starts to get unmanageable there will always be someone near to say that beautiful fallacy: “Oh, you just failed to use the concepts in the right way”. Yeah, right.
My take here is that this ideas should not be presented as dogmas, but I can’t change that, so I must equip new developers with the necessary tools to prevent them from falling into shiny traps. New developers should work on their craft, and that includes their ability to critique, suspect, question and understanding different points of view. We should be aware that our craft is new and that it’s rapidly evolving, so all “rules” and guidelines about it should be questioned so that we can evolve.