A Common Mistake Beginner Software Developers make, and How to Avoid it
I was just one month into my job as a software developer, fresh out of college. I was warming up to contribute to my team. Somehow, I caught myself having very interesting thoughts while going through the existing code base. My team had built this code base over months and years of effort.
As my first task, I had a small bug fix that would help in stabilizing future versions of the service. My team explained the architecture of the service to me and where do we fit in the grand scheme of the larger project. It was on me to find where the code had to be added/deleted or modified to make the bug fix.
I started digging through the code base, most of which had been created in the last two years. By no standard, it was legacy code. As I went deeper and deeper into it, I found myself with quite profane thoughts. To say that code was not aesthetically pleasing, would be a mild way to put it. This is how I reacted to my team’s code base:
This sucks!!!
Yuck, there is two hundred line function here.
Who wrote this crap!
Oh God, there is an if-else block inside an if-else block.
This code is a big hairy mess! eff it.
This needs to be rewritten from scratch.
I was furious. As I was having these thoughts, a part of me was wondering, could there be a way to make some sense of all this? Were there some things I didn’t know that these senior guys on my team who wrote most of this code. I began to find out.
I grabbed the senior guy on my team for a quick chat and started throwing my questions at him.
From what I came to know after the discussion was very enlightening for me. The team was aware that code had some maintenance problems. However, the existing code base was in the shape it is for a few reasons. As he went on to explain those reasons to me, I could see why this post makes sense.
Read on to find the answer to why when you ask any software developer the quality of code they are working on, the default response is: “It’s a mess”. And also, why building things up from the ground is not a solution in most cases.
Code is written for a different reason
Most people new to software development, including me, think that code is written for machines. Wrong. Nada. It was written for humans. The machine doesn’t even see the JavaScript code that you write, all they see is a sequence of 0s and 1s. And as the service for my team was being built up, there were real deadlines with deliverables that had to be delivered. Software developers are already very mentally taxed. Somewhere in the pressure to deliver, getting the code to work takes priority over writing super aesthetically pleasing code.
A large chunk of code is easier to write and explain to a fellow developer in person, as opposed to hopping from one file to another to make sense of things. These decisions then can remain around for a long time.
Production code is battle tested
My team gets a lot of incident reports, which sometimes lead to critical bug fixes in the code. An error handling if-else clause here, a try-catch there, and suddenly, the whole code base has grown hairs. This is how code base starts to get messier despite best intentions.
This is exactly why rewriting code from the ground up is such a naive idea. This would result in throwing away all the bug fixes and improvements that were made. These were accumulated over the course of months and years, possibly by a user having some real issue. A developer might have spent several hours to fix these bugs once they were reported.
What works is the way
In the world of business, where there might be clients depending on your product or service. No one cares if your code is refactored to the best possible extent. Every line of code is written to solve a business problem. Ask yourself, what value will your refactoring efforts create? Possibly none, and they might end up introducing more bugs. Plus, is it the best use of your time?
The antidote
The first step is to recognize the problem. The issue was my ego was thinking it could do a better job than these senior developers who clearly didn’t know how to write production level code. This is a very naive way of thinking, and I have been burnt sufficient times in the past to avoid it now.
Just by acknowledging your ego’s presence, you gain a huge advantage over it. Suddenly, it has no place to hide. Acknowledging the problem is one thing, and solving it is another. Below is my way of getting around this knee-jerk reaction. If you have a different way, write it down in the comments section.
Get Curious
Start to ask why!
Why was this piece of code written this way? Who wrote it? Is that person still around, and can I ask this to him/her. What do these guys know that I don’t? What is the problem that that this feature solves?
Most of the times, you will be surprised by the answer.
Develop Humility
This is not a difficult task. In all likelihood, you still have huge amounts to learn no matter where you might put yourself on the ladder.
Adopting a growth mindset is what allowed me to put myself in the right state of mind. It liberated me to ask questions without the fear of looking stupid. When you know that you are not supposed to know all the answers, but learn all the answers, asking questions becomes just a triviality.
Conclusion
It is very easy to think your way of writing code is best, and everyone else’s sucks. Ask three people on how they would split a string into an array of characters, and all would give three different ways of doing it. Probably, all of them are equally good, and something can be learned from all of them.
As to dealing with the bad quality code, throwing it away is definitely not the solution. The more business-friendly way would be to start eating the elephant one bite at a time and refactor your way through the code.
