Why Do Developers Write Code That Slows Them Down

I’ve been seeing some “not-so-good” everywhere and that made me wonder – Why do developers write code that slows them down later on?

When I started asking this question myself, I started getting various reasons for the not-so-good code. I made a note of these reasons. And today I’ll elaborate on each one of those. I guess you will relate to these and feel free to share your views on the same.

Let me start with the reasons that I think make developers write “not-so-good” code…

Not So Good Developers

This is kind of obvious, right?

I don’t like speaking out loud but it’s a reality. There are good programmers and then there are… not-so-good programmers. The not-so-good programmers don’t really know what is the impact of their code. They just take the task at hand, put some conditionals and loops with some major code smells and push it to the production.

They don’t try to learn the consequence of their code. Also, it is really hard to explain it to them because they don’t see it as a problem so there’s nothing much you could do about it. They don’t want to reason about the code, they just think their code is king.

Their code is filled with smells and it’s hard to discuss logically with them. They will pull you down to their level and slap you hard.

I started ranting so I will leave it here because you all might have experienced such developers and you know the story. If not then its time to sit back and think 🙂

And the bitter truth is that this type of code is allowed to reach to the production servers 🙁 This brings me to the next reason.

Lenient Coding Standards

When the team’s coding standard is not standardized then things like personal preference and beliefs play a stronger role. This is another thing that I came across.

There is a right way of writing code and then there is a personal preference. It’s all good as long as you are the only person working on the code (your personal code) but when it comes to enterprise-level, there are standards and guidelines that must be respected and followed.

When there are no standards or guidelines set then devs are free to write whatever the way they like. That causes bad code to go to production because “personal preference” prevails.

I’ve come across developers who find it easier to write 100s of lines of code in a single method because they prefer that way.

I’ve come across developers who put the code with major smells to production because they get attached to the code they write. They think what they have is a mater-piece but in reality it’s crap.

I’ve no problem with that. It’s your preference and maybe you enjoy writing big methods with complex logic. May be smell doesn’t bother you. But is it really helping anyone. This is something that slows the team down.

Code is not written for self. Code is written for others.

When coding standards are fixed, transformation happens. I’ve seen a transformation in self and others regarding code. Every day you open your laptop to write code in the hope to learn something new. That drives the developers. Nothing average is permitted. That builds up knowledge and motivation to adhere to the standard and in the process, you learn.

There are discussions on the structure of the code all the time. And every member put forward logical points in support of their views and respect others’ opinions. There is no talk about personal preference or sentences like “I prefer to do it this way”.

“I prefer to do it this way”

This sentence should be frowned upon.

The moment you say that “I prefer to do it this way so it should stay” means you are trying to put forth your authority. Don’t do that. It’s not good.

There are no preferences.

There needs to be set guidelines and standards that everyone will have to follow (without exceptions). And if you want to deviate from that or you are finding it difficult to implement it then you must raise the concern. Usually, this never happens because you work in pairs and things work out the best.

Low Expectations

When new graduate joins the team, they are expected to write some poor code.

This mindset leads to bad code. The coding standards should not change based on the developer’s experience. Coding standards should be a requirement and everyone should par the bar.

By keeping low expectations, you are inviting low standards and restricting the possibilities to struggle and learn.

Doing this you are making life miserable for other developers who do care about the craft and love to write quality code.

Why do new grads write bad code?

Well, first of all, this is not always the case but mostly the case. This is because they come out of the college/university and in college, they are not taught to focus on the design patterns or code structure or code quality. Universities and colleges teach them how to formulate logic (DSA) and put them in code using basic programming syntaxes.

This is good in college but doesn’t work out at the enterprise level.

I know this because I’ve been through this. I learned quite a lot after reading a lot of good library code and books.

Books are your friend mate.

Some of the books that I personally recommend are listed below:

• Gang Of Four Design Pattern
• Effective Java
• Refactoring: Improving the Design of Existing Code
• Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software
• Head First Design Patterns (A Brain Friendly Guide)

Fear of Confrontation

This happens a lot. Especially among the senior engineers.

Sometime some senior engineer writes bad code, and other seniors in the team knows its bad but they don’t speak out because they don’t want to confront. They don’t want to point out the obvious.

Or maybe sometimes they point out and its not taken well so they just keep it to themselves.

Nobody wants to feel that their opinions are not heard so instead of raising voice they stop speaking. This happens a lot in workplace.

And this tension between developers stays inside of them for months and comes out in the form of micro-aggressions that is sometimes clearly visible within the team.