Your code is sloppy (unless you’re a computer scientist)

Why does every developer think they are writing perfectly understandable code? Why is that same developer unable to decipher someone else’s code, lest maintain it?

Because they’re all writing sloppy code that works. That is, code that works now but that is not very expandable or versatile due to its messiness. Except for Computer Scientists — they write beautiful code that doesn’t work.

Reason 1: For Computer Scientists, coding is an art. For everyone else, it’s a tool

Computer Scientists code because they want to code. Everyone else codes because they want to get something done.

An average developer will structure a program based on the first idea that comes to their mind. They will then build on that idea until they have something like an MVP. Usually, they won’t even think about alternative approaches.

In contrast, a Computer Scientist will consider every option of implementation and weigh out the pros and the cons of each. Weeks later, they’ll have a beautiful piece of code that still isn’t fully functional because the Computer Scientist hasn’t decided on the format of the output yet.

A lot of sloppy code gets produced because developers start with an easy tool and grow the code organically. In contrast, Computer Scientists often start setting up a structure and then working within it.

The organic approach is best to avoid Coder’s Block and deliver things on time. However, if you want to write code that lasts, you might want to put structure first.

Reason 2: Developers don’t always write with the reader in mind

Even in collaborative projects, developers tend to write code with only its function in mind. While doing so, they forget about the fact that code also needs to be maintained.

The problem is that this mindset backfires. When the developer wants to add a feature three months later, they might be unable to understand their own code. This happens more often than you think!

And it gets even more complicated when a different developer is asked to implement a new feature. Depending on the size of a project, understanding somebody else’s code can take a few days to several weeks.

Reason 3: Style is a thing

Everyone codes differently. Some people hate in-line comments, others love them. Some people comment their functions above its first line, some below. Some people love switch cases, others loathe them.

That’s why a piece of code might seem horrible to one person, but just fine to another.

This is no problem when you’re working alone. But these days, a lot of software is built-in collaboration. So it’s important to fix a style guide in the early stages of a project.

And of course, you’ll need to ensure that all developers keep to it. Otherwise, you’ll end up with code that is messy because it’s a jumble of different conventions.

Reason 4: The fallacy of instant rewards

Have you ever felt the high when you’ve been stuck with a problem for days until you finally found a fix to solve it? It’s an extremely motivating moment.

The problem is, when a developer chases quick fixes, they often end up ignoring long-term problems. For example, they might fix a bug or add a feature, but not realize that the structure of the code is outdated.

This means that every time they add a new feature, they will have to put in more work. In contrast, restructuring the program once would make it easier to add more features in the long run.

If you prefer doing quick fixes rather than addressing the underlying problem, you’re not alone. The human reward system is more susceptible to short-term fixes than long-term changes. But this way, you’re racking up technical debt. And that can cost you a lot in the long run.

Dangers of cleanliness vs. messiness

Developers who claim that they always write clean code are either lying or overestimating themselves. That being said, there are a couple of reasons why you don’t want to write code that’s too clean:

• If your goal is to write squeaky-clean code from scratch, you’re increasing your chances of getting Coder’s Block. To keep a major blockage from happening, it’s best to grow your code organically at the beginning. This applies especially if you’re a beginner.
• Some developers spend entire days cleaning up their code for no other reason but aesthetics. Of course, this can be useful if there are many other collaborators or if the code will be presented in any kind of way. But more often than not, polishing your code is about as effective as plastic surgery for general health care — it might look nice but it doesn’t fix any deeper problems.

On the other hand, you don’t want to get your code too messy either. Too much of a mess makes your code unmaintainable. Lack of maintenance leads to code rot, and in the long run projects will be discarded since they’re doing more harm than good.

So what is needed is a healthy balance between quick results and maintainable code. Most developers fall hard on the messy side, so increasing cleanliness is the way to go. The good news is that a few good habits can have a huge impact on the cleanliness and productivity of a developer.

Hack 1: Test early and often

Some developers have so much faith in their craft that they build an entire project without running tests. But unless the task at hand is completely trivial, this backfires.

As soon as they try compiling or executing the program, the screen fills up with error messages. Or, worse still, errors go undetected until months later, when users realize that the program doesn’t behave as expected.

These are bad practices. If working in tech has taught you anything, it should be this:

Never assume that something works as expected if you haven’t tested through all scenarios.

Try to build something executable as soon as possible. Even if it is very, very simple. And test it as soon as you get the chance to. This way you can fix bugs as soon as they’re created.

Hack 2: Structure well and format sloppily

Chasing quick fixes is fine as long as the underlying structure of the code is good. What happens, in reality, is that developers try to implement quick fixes in a code that has a messy or outdated structure.

In that case, it’s better to invest the time to restructure the code. If the fix isn’t properly commented on or there are some cryptic variable names, that won’t be the end of the world. But trying to build a clean feature in a buggy code is a waste of time and resources — you will probably have to rewrite a lot of it anyway.

Therefore, a good compromise between cleanliness and speed would be to keep the underlying structure clean and updated and be as messy as necessary in the details.

Hack 3: Allocate time for refactoring

Every time you’re being messy, you’re creating technical debt. Like monetary debt, the longer you leave it, the more expensive it gets.

On the other hand, spending days or even weeks cleaning code doesn’t sound very inspiring to the average developer. That’s why it can be useful to establish a routine to pay off a little debt every single day.

A good way to start is by using 15% of your time each day for refactoring. I call this the time rule. You’ll be surprised at how much code you can improve!

Hack 4: Leave code cleaner than you found it

I call this the toilet rule. If everyone left public bathrooms at least as clean as they found them, they would be in an impeccable state.

Judging by the state of most public restrooms, reality doesn’t work this way. Keeping a rule like this requires discipline from every developer — which in turn requires an excellent manager.
But the discipline is worth it since the rewards over time can be enormous. You don’t achieve the impossible by doing impossible things — you achieve it by making some good decisions, and doing small steps towards them every single day.

Hack 5: Ask for reviews!

Sometimes, a code is messy because the developer doesn’t know how to do it better. For example, a code might employ a switch statement where a map would be much easier. In this case, the advice of senior developers is key.

Establishing a routine of code review can help create a feedback loop. This leads to an improved learning curve for young developers and fosters a culture of healthy discussions.

Like with the toilet rule and the time rule, routine is key. Asking for reviews should be a habit for junior developers, and giving advice should be an integral part of the work of senior developers.
Ideally, review time should be part of the core processes of the developing team, and a summary of key pieces of advice should be part of every meeting.

Balancing structure and chaos

Too much cleaning can be a waste of time and resources. And writing sloppy code is a lot better than encountering Coder’s Block and not delivering at all.

On the other hand, sloppy code is inflexible and hard to maintain. The five rules will help to get your code a lot cleaner without wasting time. As in every part of life, good things are produced with a healthy balance of structure and chaos.

This article was written by Ari Joury and was originally published on Towards Data Science. You can read it here.