Programmers are generally very good at their craft. They know what to do, pay attention to the details and they are great at staying the course until everything is perfect. But as with any job, we all have those niggling little habits that can creep up from time to time and make our performance, well, less than perfect let’s just say.
The first step is admitting you have such habits, the second step of course, is trying to break free of them. You’ve come to the right place! Here are my observations regarding some of those poor programing habits that it’s definitely time for you to break!
1. The ‘sweep it under the rug’ strategy
Maybe you’re ignoring exceptions, or maybe you’re using a library that doesn’t report an error, whatever the flaw here, it isn’t going to just fix itself. Don’t ignore the errors, record them and then revisit them with a fresh perspective later.
2. Sticking to a Flawed Plan
You know it just has to work! You’ve been at it for hours, this is the plan, this is the one. And yet, something simply isn’t adding up. Talk to your team, get their opinion—don’t stick to a plan because you’re afraid to start with a new one.
3. Useless optimizations
Okay so you want your site to be functional and faster, but optimizing just for the sake of optimizing may not be the best approach. In fact, it may just be a big fat time waster. Go back at project’s end and then see what you may be able to do as far as optimization is concerned.
4. The Loner Syndrome
Yes, maybe you do have the best plan, the most innovative ideas, but your team is there for a reason. Their insight and advice could add a whole new dimension to your approach. You don’t always have to go it alone you know.
5. It’s Okay to “Google It”
If you hit a brick wall, it is okay to go to the almighty Google once in awhile. It became an actual verb for a reason. There are certainly more in-depth resources such as Stack Overflow, but Google can be a great start to get some new insight on a problem that has you stumped.
6. Best Practices are Important
Programming has been around for awhile, as such things like code reviews, and test-driven development have had their place in this particular arena. Don’t ignore them! In fact, learn them. Make yourself conversant with these best practices, your programming only stands to shine because of it.
7. Don’t Get Too Cocky
Hand in hand with not being a loner, is not being too arrogant as regards your personal coding style and techniques. Your team can be invaluable and you need to learn to work harmoniously with them. If it’s all about insisting that things are done your way in accordance with your practices, the situation could get a bit touchy.
8. Don’t Just Say “I’ll fix it later”
Fix it now, otherwise you can easily get caught up in other things and lose sight of what the problem or error was to begin with. Implement “to do” comments so that you can keep careful track of exactly what needs addressing.
9. Dismissing Styling Issues
These are extremely important. I have seen too many developers dismiss styling issues or consider them negligible. Do not postpone these types of things as they can derail your code.
10. There’s a Right Tool for Every Job
And also, be open to new tools; whether libraries or languages, use what is best for that particular job. Some programmers are so stuck on one tried and true set of tools they fail to see that there is a better way and thus, in the end, shortchange their own code.
11. Give Feedback
Feedback is critical. Whatever the industry it lets us know we’re doing a good job, that we are adding value. You need to let your team members know what is working and what, subsequently, is not. This prevents wasting time and ultimately creating a program that has major flaws.
12. Blaming Others
Just as you should not exhibit arrogance, you also need to refrain from blaming others for your issues. It’s okay to make mistakes—in fact, as you are (I hope) human, it’s inevitable. Admit it, address it and move on!
13. Do Not Ignore Those Error Messages
You can’t just assume that you understand the problem. Read the error message carefully. The more you know about the problem at hand the easier it will be to solve. And of course the more time this is going to save you!
14. Don’t Overwrite Code
Meaning you don’t have to reinvent the wheel every single time. Use available code. It’s not taking the easy way out--it’s the smarter way. You’re saving time so that you can focus on the new code that you do in fact have to create.
15. Refrain from Copying/Pasting
Along these same lines thought, don’t simply copy and paste code. You need to understand the code before you integrate it into your program. Think of it this way, by taking the time to understand it, you are actually gaining some valuable knowledge in the process.
16. If You’re Stuck, Ask for Help
It’s a fairly simple concept really. You don’t have to handle every situation on your own, especially those you may be struggling with. It’s not a sign of weakness to ask others for help, in fact it shows that you’re taking initiative and trying to better your own skillset and knowledge level.
17. Take the time to learn how things work
Learning more, experimenting with code, tapping into the understanding of others—these are sometimes a programmer’s best bet. It only makes you better at what you do and ultimately able to create programs faster and more efficiently than before. Don’t just worry about the end result all the time, savor the process!
18. You Must Performance Test
I’ve seen too many programmers skip this critical step. Not acceptable. Test at each critical juncture of the project to ensure that all of the moving parts are coming together as they should.
19. Having excessive confidence in your own code
Just because you wrote the code doesn’t mean it is where it needs to be. Look at how you’ve progressed as a programmer, look at your older code, learn from mistakes and build on your skills.
20. Consider Design Trade Offs
When you use certain products, you learn about them. You gain insight into them. And subsequently, you may fall in love with it. But always consider the trade offs. Is this the best thing for your program…Carefully evaluate everything you use.
What bad programming habits are you trying to break? Join the discussion in the comments below!
