I have seen a lot of bad programming practices from teammates, classmates, and myself. If anything, I have fallen guilty of many of these practices. That is why I have come to appreciate how costly they are not only me but also my work as a developer in the future. They become habits when constantly repeated, and this is when it becomes even harder to change them.

“You can’t keep doing the same thing and expect to get different results.”

‘I’ll fix it later”

Oh, how I am guilty of this one. When a problem comes up, fix it. Don’t push it aside and keep going one because another one will come up, and another one, and another, and before you know it, you have a pile of problems that will take you back a day or even a week of your timeline. Also, the more you ignore fixing a problem as it comes up, the higher the chances that the next problem will be caused by the first problem. Like a domino effect. Just fix it first.

Copy-Pasting

This could very well be something every software engineer has done in their lifetime. Looking for how things are done on the internet is okay. Using someone else’s code is okay, to a point. There is the risk of not being able to understand what this person did, or how they came up with their logic. So technically if you use their code, you shouldn’t claim credit for a “working” feature because you don’t understand how it is actually working.

When this becomes a habit, it becomes difficult to be able to write your own logic as a software engineer or to ‘think like a computer scientist’. Many, if not all software engineering job interviews test for this. Making a habit of copy-pasting other developer’s code into your work slowly tarnishes your problem-solving skills. Anyone can copy-paste but not everyone can think like a computer scientist.

Not documenting

Unless you write code that will be locked in a box somewhere and thrown in the middle of the ocean never to be used again, this is a horrible practice. Always code with the future in mind. Other developers will read your code, future you will read your code. 2 years from now, or even just a few months from now you will not know what exactly you were doing in your own code. Comments will help you and other developers get through your code faster and more efficiently. They will also like working with you and using your work for reference. Documentation is one of the best habits to have as a developer. If you don’t know how to do it, or where to start, this can work as your guide.

Turning a blind eye on issues

“As long as my code works, I don’t need to look into this issue” News flash! You will have to deal with that issue eventually. Maybe tomorrow, in a week, a month, or a year, but you will definitely come back to it.

Why? Sometimes, despite errors and or bugs, code runs like it’s supposed to. These issues may be invisible to the person using your website or whatever you’ve built, at first. But eventually, they will cause something that already worked fine to fail somewhere along the way. It may be in a long time or in a short time. If you wait too long between the time the issue comes up and when something fails, you may have forgotten that it even existed and this will cause you a nightmare, lots of hours, and frustration in debugging.

I came to learn this in an assignment I did recently where all the tests passed, but I wasn’t meeting one of the requirements in the instructions that caused my program to fail in the next assignment.

Not asking for help

I’ll say this a hundred times. Asking for help does NOT mean you’re stupid. It means you take your work seriously enough to want to keep being better at it. When you have a bug you can’t fix, when you’re not sure how to approach something, ask someone for help. Could be a colleague, a classmate, a fellow developer, your mentor, a stranger on the internet. Just ask, and keep asking. If someone doesn’t want to offer their help, ask someone else. The world is full of software developers.

Not asking for help will drag you behind, take a lot of your time, and make you plain miserable. I’m lucky to have colleagues who are always willing to help each other, and a class forum with students who are always online.

Messy code

In this case, I mean having variables or functions in your code that don’t do anything. They just fill up the page. You’re not done with a task or project until the last commit you did was for cleaning up what was unnecessary in your code.

Also Read This: How to write clean code

Bad indentation

I came to learn this when a developer once looked at my code and the first thing that came out of his mouth was, “what is wrong with your spacing”. To me, it looked fine. I didn’t know that there was a standard way to indent and space your code to make it easier for someone else and yourself to read as well as to debug. You can set your preferred tab spacing on the text editor you use, but the standard one is 4 spaces for tab space. Know when to use tabs, and when to use spaces, and remember to always match the level of your opening and closing tabs.

Coding immediately

Once you have a task or problem at hand, the first step is planning it out. Break it down into little sub-tasks, design what it would look like on paper, get opinions and suggestions from your teammates and get feedback during this planning phase from the potential user of your system. Contrary to what people may think, this is part of your job as a software developer.

Not taking some time to plan will force you to make so many changes that could have been avoided from the start. It will also make the users lose faith in your ability because you may build something they do not want, or will not use. Your time and theirs will have been wasted.

Refusing feedback

Not everyone knows everything, but someone will always know better than you. Many times your code will need improvement, albeit working fine. Taking feedback from more advanced developers is a means of learning how to be better at your job. Take it, humbly. Use it where necessary, and if it isn’t, listen to it still. You may get a different better idea just from listening to it.

There is always room for improvement and growth. Don’t keep doing the same thing over and over and expect different results.

What are some of your bad programming habits?