Why does every developer think they are writing perfectly understandable code?
Why is that same developer unable to decipher someone elses code, lest maintain it?
Because theyre 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 doesnt work.
Reason 1: For Computer Scientists, coding is an art.
For everyone else, its 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 wont even think about alternative approaches.
It’s free, every week, in your inbox.
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 Coders Block and deliver things on time.
However, if you want to write code that lasts, you might want to put structure first.
While doing so, they forget about the fact that code also needs to be maintained.
The problem is that this mindset backfires.
This happens more often than you think!
And it gets even more complicated when a different developer is asked to implement a new feature.
This is no problem when youre working alone.
But these days, a lot of software is built-in collaboration.
So its important to fix a style guide in the early stages of a project.
And of course, youll need to ensure that all developers keep to it.
Otherwise, youll end up with code that is messy because its a jumble of different conventions.
Its an extremely motivating moment.
The problem is, when a developer chases quick fixes, they often end up ignoring long-term problems.
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, youre not alone.
The human reward system is more susceptible to short-term fixes than long-term changes.
But this way, youre racking up technical debt.
And that can cost you a lot in the long run.
Too much of a mess makes your code unmaintainable.
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.
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.
These are bad practices.
take a stab at 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 could fix bugs as soon as theyre created.
In that case, its better to invest the time to restructure the code.
Hack 3: Allocate time for refactoring
Every time youre being messy, youre creating technical debt.
Like monetary debt, the longer you leave it, the more expensive it gets.
Thats 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.
Youll be surprised at how much code you’ve got the option to improve!
Hack 4: Leave code cleaner than you found it
I call this the toilet rule.
Judging by the state of most public restrooms, reality doesnt work this way.
Hack 5: Ask for reviews!
Sometimes, a code is messy because the developer doesnt 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.
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 Coders 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 byAri Jouryand was originally published onTowards Data Science.
