Why Becoming An Uncompromising Clean-Code Fanatic Is Probably Good For The Morale Of Your Team

Technical Debt is REAL, regardless of your disbelief, ignorance or your kind opinion.

First, let’s get a few things straight,

1. Technical Debt is REAL, regardless of your disbelief, ignorance or your kind opinion.
2. More than the will or desire to write clean code, at some point, writing clean code becomes a matter of getting opportunities to do so.
3. Clean Code and Clean Architecture and one and the same. If you think, one can exist without the other, then probably there is something wrong somewhere.

Nobody wants to write messy code, not even the person who writes it, and yet most of the time I see pieces of code scattered around on the screen that should not have even existed in the first place. Many a time I have heard developers telling me, “I don’t like the code that I am writing”. How can you even expect them to create islands of serenity within the chaos of a tangled mess?

Have you ever accounted the number of hours you team wastes just to understand the existing code and conveying the intent of their faulty code to their fellow developers, or endless KT sessions on “Bad Code”?

If you think that the coding standards documents are a means to get developers to write clean code, then you are falling into the trap of misguided reductionism. How can a philosophy of clean code be reduced to a set of mindless rules? I cannot even remember my 20 line shopping list, let alone the 20 page rules on how to write code, which no one follows anyway. If you are concerned about your Camel Cases or Pascal Cases, let the automated code checkers plugged into the CI pipeline handle that. We live in the age of automation.

Contrary to popular opinion, Architecting a solution is a continuous activity. Many times you will not get things right in your initial design. You need to pause, think, restructure, re-factor and re-organize.

Development is an activity that is best performed when the developer is in the state of Flow.

The Zone

Development is an activity that is best performed when the developer is in the state of Flow. The amount of information that the developer has to hold while developing is tremendous. When you disturb the flow, you push the developer’s reset button. The developer will take an hour again to get back into the zone. The “Bad Code” is the major distraction. It leads to an endless flow of fellow programmers stopping by and asking clarifications on the code, and it gives rise to endless code walk-through sessions, and calls for endless meetings on “why the hell things are not working?”.

Understand that when a developer comes in and out of the flow a number of times due to disturbances or is never allowed to reach the state of flow, it drains him out of his cognitive resources and that leads to procrastination. How many times have you heard “Will do it later” and the later never comes?

Organised In Code = Organised In Mind

It’s as simple as it sounds. If you give a proper structure to anything, your mind absorbs it effortlessly. If your code is properly structured, and every line looks like it has been cared for, and every line has a meaning, will it not reduce the communication within the team?

Clean code gives way to more clean code.

Respect your teams’ desire to learn

Most programmers by nature crave learning. Clean code opens up their minds and they start seeing things in the right light, and this gives them opportunities to learn how to do things the right way. It helps them expand and apply their Tool-set. Software Engineering is at the intersection of art and science. Sometimes the solutions will have the predictability of classical mechanics and sometimes the problems will take your thinking to the level of an Artist’s. Clean code gives you and your team opportunity to do the latter without indulging in nasty workarounds. It is the artistic aspect that keeps you interested and sane. Clean code gives way to more clean code.

Giving people a sense of purpose and meaning is the best way to keep them motivated towards a common goal.

A Sense of Purpose

Giving people a sense of purpose and meaning is the best way to keep them motivated towards a common goal. Meaning makes work more fun. It makes the journey interesting. Give your team something they can talk about. Give them an architecture they can boast in the company of developers and feel proud.