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…
Table of Contents
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 standardised 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/university but doesn’t work out at the enterprise level.
I know this because I’ve been through this. I was very efficient out of the university, used to do things fast but dirty. I had to learn it the hard way; the long and boring way by reading a lot of good library code and design 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.
Favouritism
I’ve been a victim of this a lot many times now. I’ve also been the favourite guy (I know… but this is about bad code leaking into production so be with me). I’ve also been team lead a lot many times. So believe me when I say “Each team lead has their favourite person”. The person they trust the most and believe blindly.
In ideal world it shouldn’t happen but it does. It can happen in more than one ways; they both come from same origin, previously worked in the same company or team(s), has good camaraderie and so on… and that is totally cool by me.
But… when it starts interfering with the work then it becomes a hurdle results in a toxic culture and that’s where the bad code starts leaking into production.
I’m not telling you anything new here. Management – the people up the ladder – know this already. And if you’ve observed closely, you’ve probably noticed they don’t usually put two lead engineers (especially friends) in the same team. You might have heard that Two leads from different backgrounds can clash and slow progress, but the opposite situation isn’t exactly great either.
Why favouritism leads to code that slows developers down
Because once favouritism enters the picture, decisions stop being multi-perspective. The decision maker ends up operating from a single lens – their own perspective combined with the favourite person’s. And that makes almost everything harder than it needs to be.
You first see this during design discussions. The favourite person proposes something. The team starts commenting or criticising the design. Valid points are raised. And yet, the design still gets approved. Not because the concerns are wrong, but because the lead starts defending the proposal anyway. At that point, personal camaraderie takes priority over the work.
I don’t even know if I should be telling you this, but here’s what happened in one case.
I proposed a design doc, got approval from everyone, and delivered the code on time. During that period, I had a minor difference of opinion with a senior engineer from a neighbouring team.
And – believe it or not – this is what followed. Ego does make people do strange things.
When I went on leave the next week, the neighbouring team’s lead and my own team lead quietly created a ticket behind the team’s back. No one on the team knew about it. The ticket labeled the work as “poor design” and “code smells,” without explaining what was poor or where the smell actually was :D. They then assigned the work to a new developer who hadn’t worked on the feature at all and knew nothing about it.
When the ticket eventually reached one of my colleagues, he was furious. He told me. I was furious. The escalation that followed ended up exposing the entire mess that had been happening behind our backs.
Haha… work is fun sometimes.
But yeah – things like this only happen when leads do things simply because a favorite person asked them to.
This is also where code reviews start going off the rails. Reviews turn into an endless cycles: fixes, comments, discussions, more fixes, more comments – until they’ve either “won” or exhausted you. Only what they believe is correct gets approved, while anything valuable from the other developer is quietly ignored.
At that point, progress slows for the entire team. And when progress slows, management starts asking questions. When that happens, one of two things usually follows.
Either the lead starts blaming individuals by pointing at slow code delivery. Or they panic and start pushing things out faster than they should, which is how bad code leaks into production. If the lead had been neutral in the first place, neither of these outcomes would have happened.
My advice: if you see this happening, make noise. Don’t assume you’re imagining it just because you’re new. If it feels off, more often than not, it is.
Takeaway: when you become a team lead, be self-conscious and self-reflective. Don’t let favouritism become a decision-making shortcut. Stay rational at work, because once bias creeps in, it doesn’t just hurt people – it slows everyone down.