Good habits, good code quality

“Don’t expect to be motivated every day to get out there and make things happen. You won’t be. Don’t count on motivation. Count on Discipline.”
Jocko Willink

I love this quote, and I think about it everytime I feel lazy or tired and I don´t want to wake up early, workout, finish that course on Udemy, wash the dishes or whatever.
I love climbing and I would climb every day, but the sweating, screaming and going through the sore muscles of a full workout, well that sucks! But it´s important! And you can get all the benefits of it, once it becomes a habit.

In coding, we can be motivated in writing clean and good quality code because we just learned a new concept, or we found out a new cool trick, or maybe because we just started on a fresh clean repo or we just joined a new team, or project.

Or or or, if if if.

The truth is that over time we might get bored, and sloppier. And then we don´t care anymore if in that method there is a typo, or if we duplicated the same or similar thing ten times.

Copypaste is easier, Job done!

Other times, we might have good reasons, or good excuses that legitimate us from writing good quality code:

Deliver! Deliver! Deliver!

Well, this might all be true, but I remain still convinced that writing quality code is a good habit, and like most habits, it needs discipline and dedication. You have to commit to it, somehow force yourself into it.
Then it becomes an attitude, and you will find yourself writing good code without even thinking about it. Quite the opposite, it will feel very weird and difficult to write sloppy code.

Have you ever opened your IDE thinking:

Oh — I am in a hurry — let’s write shitty code — but let’s get shit done.

or

Good, sprint is planned, now I have plenty of time to design and implement things properly. Let´s do that sloooow and goood. Oh Yeah, baby!

I don´t think so. But both thoughts might be sneaky and underlying our coding style if we don´t have the discipline and right attitude.

If it takes us lots of effort to write good code, at the first opportunity, we will simply give up.

But that´s a prototype, code does not have to look nice!

Recently we worked on a prototype, and we were all very excited about the new project, we wanted to iterate fast, and we wrote lots of messy code.

But, what does messy code mean?

During a prototype phase speed is more important than quality.
The goal is iterating fast, and during iteration, you will change functionality and delete code all the time.
It might even be frustrating to throw away very good ideas, but it is how it is, that´s the point, trying out things, show them to the client, iterate. The idea ( and the piece of code that is shipped with it) might be awesome, but simply doesn’t fit the project, the client doesn´t like it or they have simply changed their mind and changed the requirements.

Keeping this in mind, allows you to take some shortcuts:

• you don´t fix all the linter errors before committing,
• you allow some ( /lots of) duplication,
• you hardcode some values or entire data providers,
• you can skip writing all the PropTypes for your React Component,
• you are allowed to style the component inline and so on..

There are high chances that everything will be thrown away anyway!

All this is ok, but you also have to remember that some code, won´t be thrown away. Over many years, I have never seen a prototype being used only as a proof of concept. As soon as the concept is approved, most of the time you start building other features on top of it.

Many parts of its codebase, therefore, will make it in the final project, so the better they are the faster you can refactor them, or build on them. Also, that code will become somehow the starting point — the standard — the reference of any code that will be written after, for all the developers to come.

So, even if it´s a prototype, don´t write shitty, sloppy code, just because it is a prototype. Have discipline, stick to quality code, somehow force yourself into choosing with awareness some shortcuts, but don’t allow the “don´t have time” excuse sneak into you.

But I need to be quick!

Another reason to not write sloppy code is that Yes!, you need to deliver fast, but that does not always mean that you are rushing into the deadline.
Most of the time the development team is involved in the estimation of when a feature could be ready. So the delivery date is not always imposed from above. You have the chance to ask for the right amount of time to not be stress and not be forced into writing shitty code.

In my career, I found many colleagues that during the code reviews, were saying,

I know that code is bad, but we will refactor it as soon we will get some buffer for Technical debt.

This will rarely happen.

Stakeholders will always push for features ( functional requirements ) vs Quality / Refactorings / Non functional requirements).
From the outside the application is working, why change it?
Why spend time just for gold plating, for something that is not visible from the outside and brings nothing to the end-user, when we could invest in new features, that will bring new users or more money?

But

without periodic and aggressive refactoring, we can’t produce sane, maintainable code. quote from The coding Horror

and without discipline, we will always find valid excuses
You have to plan for your tickets properly, sometimes you have to fight your way out of an accurate and reasonable estimation/delivery date.
You have to share with your colleagues and project managers the definition of done and consider as part of the feature unit tests and quality code.

You have to force yourself into all this practice. Some of it might be uncomfortable, or difficult, or plain boring, but with discipline, it will become a good habit.

Originally published at https://dev.to on September 7, 2020.