Discipline in programming

Having worked for about a year now on big software projects in collaboration with other developers I realized that activities requiring discipline should be avoided.

Usually these kind of activities maintain software quality and/or correctness of the program. The first one that came to my mind was following best practices, guidelines or conventions.

The problem with code conventions for example is that writing them down is no guarantee that they will be followed. First it requires developers to know that they exist and to understand what they are about. Second one needs discipline to remember and apply them.

Conventions can easily get abandoned due to new developers joining the team or some time passed and developers forget about them, but it can also just be a lack of concentration.

If we require discipline working with computers, we failed to let computers do the work for us.

Computers are better at discipline than humans. Some people put it like this: “good programmers are lazy”. Instead of betting on the programmer’s discipline we should automate. You can for example enforce a coding style by linting code before pushing with tools like ESLint.

There are other activities that require discipline as well, like managing state, memory, manual code splitting or handling concurrency. One of the reasons we still have these kind of problems is that our tools have not evolved as quickly as our machines. Required discipline in programming is caused by a lack of explicitness in our tools. We are doing the work manually because our tools don’t give us the ability to automate them.

In a dynamically typed language for example, a lot of tests are written to ensure that the program behaves as intended with the correct types and handles errors if wrong types are passed. These kind of tests are also excercised discipline that make the solution explicit by stating it twice differently, because the language does not provide a way to do so in the first place.

Fortunately there are statically typed, memory safe and concurrent languages. Nevertheless possibilities to further improve languages and tools to remove the programmer’s discipline as a factor for code quality exist. Unison for example is a very interesting concept. It is a combination of a new programming language and an editor that prevents incorrect input, because it knows the language as well as the already typed code.

In conclusion, best practices are a symptom of tools that lack the ability to explicitly express solutions. We as programmers should improve our tools to eliminate activities that require discipline.