A Few Bad Habits I Suffered From As A Programmer
A few common mindsets that hurt you
While we are indulged in writing code we tend to make mistakes. Mostly we blame it on the urgency of the task at hand or the way in which the requirements come to us.
Much later in my career after making many mistakes, I realized if anyone is to be blamed is me and the bad practices I gathered along the way.
Long Functions and Classes
When indulged in programming we tend to write our code like a script. We all know the functions should do one thing and do it well.
New programmers write long functions and classes due to inexperience and experienced ones do this when they become too comfortable. I have done this mistake when I was a newbie and I still do this a few times.
To mitigate this I have added a step of self-review in my programming practice. Whenever I notice such a function or a class I break it down with no delay.
Overconfidence
We all have spoken these words and heard them as well:
It works on my machine.
or
My code works fine. Problem is in some other module/sub-system.
Statements like these show the overconfidence of the programmer. I have suffered from this confidence for years.
Not doubting yourself or your code adds friction between coworkers. It also increases the time and effort it takes to fix a problem or an issue.
After years of such struggle and taking inspiration from a few of my colleagues I thankfully understood this — Always doubt your code. As soon as someone says there is a problem, my reaction is “there could be, let me have a look”.
Not writing Unit tests
I have seen the benefits of TDD (Test Driven Development). It helps catch the bugs early in the development cycle and makes you feel confident about the code you have written. It saves time and money as well.
I had a tendency of starting a new project with TDD, but slowly I used to drift and on the way, TDD used to go down the drain.
In the back of my mind, I always have a tendency to skip unit tests if the feature I am developing is urgent. I do this even if it would not take a lot of time to add a few tests.
To counter this, I made a rule that no code goes (even for review) without unit tests. This rule has helped me and the team to keep TDD going.
Not using DRY
I don’t do this anymore. I always follow DRY (Do not repeat yourself). There was a time when I was not so adamant about DRY and had pieces of code repeated in the source code.
This generally happens when you are not diligent enough or you take shortcuts to complete the task at hand. A few times to reduce the test cycle I used to not follow DRY because it required changes in the existing code.
Now, I am quite ruthless about it. I make sure that I never repeat code.
No comments
When we are engrossed in coding we tend to forget to write comments. Comments help us when we revisit the code and save us time. I still don’t write enough comments.
I am not in favor of standards various organizations have for writing comments. I write comments where they are needed.
I write comments where the logic is complicated or I have made a few assumptions. I don’t write it for the functions and classes that are self-explanatory.
Not using Bug tracker properly
From what I have seen over and over again, many teams and managers find it tough to give the right priority to the bugs. And moreover, they spend a lot of time in bug scrubs and sprint planning.
I have been guilty of ignoring the bug tracker for a few days in a stretch, and not setting priorities diligently.
Many times severity is given more importance than a priority. The bug might be a nasty one but may not be a priority for the business now.
Bugs in the current sprint and the backlog need to be prioritized based on the business requirements at regular intervals.
No Documentation
Well, documentation is boring. Most of us don’t want to document our ideas and design. We ignore documentation for more exciting work.
Without documentation if someone else needs to look at the code you have written he would be lost in the code.
Proper comments in the code can be used to generate code documentation using various tools available. It is always good to document your designs for future reference. This helps others understand your design and helps you improve it based on their review.
Conclusion
All of us have our own bad habits and practices. I have listed a few I had suffered from for a long time. I keep a conscious check on these habits so that I don't repeat them.
What are the habits and practices that you have suffered from? Please write in comments.
Thanks for reading!
