Discipline within Software Engineering

When one of the people I look up to, Jocko Willink, was asked the question, what is the definition of discipline, he had a beautiful answer. He answered: “Doing what you should do.”. Great podcast episode with Lex.

Beautiful, harsh truth.

At first look, it doesn’t seem like something special, but if you think about it, you understand how true it is and how often we fail it.

This definition applies to all aspects of life, from eating healthy, exercising, reading, and developing software.

Discipline is a habit. If we nurture it, it will come easy to us. If we don’t, we won’t do what we should do.

Discipline in Software Engineering

To succeed as an individual, as a team and as a company we have to nurture it. And when motivation fails us, we have to rely on discipline. Otherwise, quite quickly we can find ourselves in trouble. Usually in form of technical dept.

It's hard, it's annoying and painful. But, it can be equally and more rewarding.

What does that mean for us Software Engineers? When you are tempted to take that shortcut to make it happen fast, don’t take it. When you start telling yourself and Tuesday 13:00 that you should have deployed these changes yesterday, don’t take the shortcut. Usually, it’s just an hour or two maximum of an investment. All those: “The release will be soon”, “I’m late”, “Oh look at the amount of code, I can’t write tests for that”, etc. are lies! At that point, our brain is just lying to us, trying to trick us to take the shortcut!

What do we get from that? Technical debt. What does that mean? Because we were too lazy to spend one more hour cleaning up or doing it right, over a period of time there will be a compound effect of those decisions. Then we will start feeling slow, not contributing properly or just plain unhappy. As one of the speakers, I listened to would put it:

Write those tests!

You know that feeling when you have some code and you really feel like not testing it?

That is exactly when you should write them. Go for a walk, go for a coffee and relax, and come back and ace it! Why? Because you before all, but also your colleagues will be very grateful for it. You will find logic, design flaws and bugs. Above else, you are going to be very proud of yourself! It will help you infinitely when refactoring comes.

Forming discipline for the non-obligatory things

There is another form of discipline you can nurture. You know that moment when you browse through code, and you spot a small segment of code that is, well, bad? It could be something even you wrote a year ago. It could be an outdated team convention. An ugly for-loop I guess? Instead of just skipping it, stop and dedicate 5–10 minutes for some quick safe refactorings. Rename that variable. Rename that method. Extract that if statement. Inline that method.

A safe refactor is usually something we can completely rely on our IDE to do. For example, renaming a variable or a method. The IDE will take care of it without you going around clicking ctrl+c ctrl+v.

In the same way, you have a compounding effect with bad decisions, you will have one with good ones. If each member of the team does this (even if you start that's amazing), PR-by-PR your code will be cleaned up! And you know what comes into play here? Tests! If you wrote those tests and weren't lazy, you are going to want to kiss yourself here for having a safeguard for refactors.

---

Everything is a habit. Bad decisions, good decisions. We are defined by the small actions we take each day, they all sum up in the end and reward us.