Bad habits are hard to break and even harder if you donāt realize that what youāre doing is undermining your work. If you know but donāt careāthat would be the worst. But youāre here, arenāt you?
As a programmer, Iāve seen a lot of poor practices, not just around code, but also around teamwork skills. Iāve been guilty of practicing many of these bad habits myself. Here are my top 35 bad programming habits, organized into four categories: code organization, teamwork, writing code, and testing and maintenance.
Code organization
1. Saying āIāll fix it laterā, and never doing it
The habit of postponing code fixes is not merely a problem of priorities. Organizing your issue tracker might generate some progress, but you also need to have a way of tracking smaller issues that come up. Adding āTODOā comments is a quick way of making sure you donāt miss anything.
2. Insisting on a one-liner solution
Being obsessive about writing efficient, elegant pieces of code is a common trait of programmers. Itās like solving a puzzleāyou find a combination of functions and regular expressions that turn 20 code lines into 2 or 3. Unfortunately, it doesnāt always result in readable code, and thatās generally the far more important outcome. Make your code accessible first, then clever.
3. Making pointless optimizations
Another place where we often misplace our efforts is optimizations. It sounds great to reduce the size of your website a few bytes, but wonāt gzip make up for it anyway? And arenāt requests more important? Address optimizations at the end of a project, because more often than not, requirements will change, and your time will have been wasted.
āPremature optimization is the root of all evil.ā āDonald Knuth
4. Convincing yourself that styling issues are not that important
If Iāve learned anything over years of looking at other peopleās code, itās that dealing with coding style issues is the thing that developers are most likely to postpone. Maybe itās hard for inexperienced coders to see what good will come out of addressing styling issues, but over time it will become evident that once code quality derails, a snowball effect will turn any project into a complete mess. Be strict about best practices even if they seem negligible. Set up code checking and linting tools to give yourself space to worry about the more important things.
5. Sweeping things under the rug
Either by catching and ignoring exceptions, or by using libraries that donāt report errors (such as jQuery), there are many ways to sweep things under the rug. But when one of those errors becomes a priority, the challenge of fixing it will be many times greater, considering that you wonāt have a clue where to begin. An easy way to avert this is by logging those ignored errors so you can study them later.
6. Using names that donāt add information
Naming is hard, but thereās an easy way to make sure your variable and function names are at least of decent quality. So long as the names add some kind of information that the rest of the code doesnāt convey, other developers will have an easier time reading your code. The reason that naming is so important is that names can give a general idea of what the code does. It takes more time if you need to dig into the calculations to figure out what piece of code does, but a good name can help you understand what the code does in seconds.
7. Ignoring proven best practices
Code reviews, test-driven development, quality assurance, deployment automationāthese practices, and several others, have proved their value in countless projects, which is why developers blog about them constantly. A great reference for these best practices is the book Making Software: What Really Works, and Why We Believe It. Take the time to learn how to do them properly, and your development process will improve in all of your projects in ways that will surprise you.
Teamwork
8. Abandoning plans too early
A sure-fire way for making your system inscrutable is to not commit to a plan. You can always say, whenever your code is criticized, that the plan isnāt complete. However, having half-done modules will lead to tightly coupled code as soon as you try to make those unfinished modules work with each other. This kind of complication also comes up when a projectās leadership roles change and the new leads decide that having it their way is more important than architectural consistency.
9. Insisting on a plan that has little chance of working
Just as abandoning your plans can cause problems, so can sticking to a plan that doesnāt work. Thatās why you should share your ideas with your team to get feedback and advice when things get tricky. Sometimes a different perspective can make all the difference.
10. Working on your own all the time
You should strive to share your progress and ideas with the team. Sometimes you think youāre building something the right way, but youāre not, so constant communication is very valuable. Itās also beneficial for other people when you work with them. Their work often improves when you discuss ideas with them and mentor the less experienced members of your team, who are more likely to get stuck.
11. Refusing to write bad code
There comes a time in every developerās life when deadlines will force you to write terrible code, and thatās okay. Youāve tried warning your client or manager about the consequences, but they insist on sticking to the deadline, so now itās time to code. Or perhaps thereās an urgent bug that canāt wait for you to come up with a clean solution. Thatās why itās important to be versatile as a programmer and to be able to write poor code very quickly as well as good code. Hopefully, you can revisit the code and pay back the technical debt.
12. Blaming others
Itās no secret that arrogance is an all-too-common trait among developers and other technical professionals. Taking responsibility for your mistakes is a virtue that will make you shine among your peers. Donāt be afraid to admit that youāve made a mistake. Once youāre okay with that, you will be free to focus on learning why you made that mistake and how to avoid it. If you donāt own up to it, learning becomes impossible.
13. Not sharing with your team what youāve learned
Your value as a developer is not only placed on the code you write, but also on what you learn when writing it. Share your experiences, write comments about it, let others know why things are the way they are, and help them learn new things about the project and its intricacies.
14. Being too slow on giving feedback to managers/clients
One of the most valuable character traits of any craftsman lies in making sure that everyone is on the same page about the work, as much as possible. The reason for this is not so that your manager call fill spreadsheets. Itās for your own gain as well: You will have fewer insecurities and reduce uncertainty about the lifetime and future of the project.
15. Not using Google enough
The best way of solving a complex problem quickly is not having to solve it at all. When in doubt, Google it. Of course, you can bother the engineer next to you instead, but rarely will he be able to give a response as detailed as Stack Overflow, not to mention that youāll be interrupting his work as well.
16. Overvaluing your personal style
Always aim to coordinate your working style and environment setup with your team. Ideally, everyone on your team should be working under similar conditions and following the same coding style. Doing things your way can be more fun, but co-workers might not be used to your coding style, and if itās unusual, it will be harder for the next developer to work on what youāve built.
17. Having a personal attachment to your code
When someone comments on your code, donāt take it personally. Your code should stand on solid ground; that is, you should be able to explain why you wrote it that way. If it needs improvement, thatās only a reflection of the codeās correctness, not of yourself.
Writing code
18. Not knowing how to optimize
A good optimization strategy takes some experience to get right. It takes exploration, analysis, and knowing every system involved in a process. Inform yourself about these things. Learn about algorithmic complexity, database query evaluation, protocols, and how to measure performance in general.
19. Using the wrong tool for the job
You can only know so much, but the reason why you have to keep learning is that each new problem brings a different context and requires a different toolāone more applicable to the task at hand. Be open to new libraries and languages. Donāt make decisions based strictly on what you know.
20. Not bothering with mastering your tools and IDE
Each new hotkey, shortcut, or parameter you learn while using the tools you work with every day will have a more positive effect on your coding speed than you realize. Itās not about saving a few seconds by using a hotkey; itās about reducing the context switching. The more time you spend on each small action, the less time youāll have available to think about why youāre doing it and about what comes next. Mastering shortcuts will free your mind.
21. Ignoring error messages
Donāt assume that you know whatās wrong with your code without even reading an error message, or that youāll figure it out quickly enough. Having more information about a problem is always better, and taking the time to gather that information will save more time in the long run.
22. Romanticizing your developer toolkit
Sometimes your preferred editor or command line tool isnāt the the best tool for the job at hand. Visual Studio is great for writing IDEs, Sublime is great for dynamic languages, Eclipse is great for Java, and so on. You might love vim or emacs, but that doesnāt mean that itās the right tool for every job.
23. Hardcoding values instead of making them configurable
Always be thinking about what changes might come and how to deal with them. Technical debt will grow at a monstrous rate if you donāt separate the moving pieces from the rest of your work. Use constants and configuration files where appropriate.
24. Reinventing the wheel all the time
Donāt write code you donāt need to. Perhaps someone else has spent a good deal of time on your problem already, and he or she might have a well-tested solution that you can reuse. Save yourself some trouble.
25. Blindly copy/pasting code
Understand code before you reuse it. Sometimes you donāt immediately notice everything the code is doing on first glance. You will also learn more about a problem when you take the time to read the code in detail.
26. Not taking the time to learn how things really work
Always take the opportunity to expand your knowledge by thinking about how things work and reading about their underlying issues. You might save time by not bothering right now, but what you learn on a project will be more important in the long term than actually getting it done.
27. Having excessive confidence in your own code
Itās dangerous to assume that just because you wrote something, it must be great. You learn more about programming as you work on new things and gain experience, so take a look at your old code from time to time and reflect on how youāve progressed.
28. Not thinking about the trade-offs of each design, solution, or library
Every product has its fine points that youāll only learn about by using and analyzing it. Seeing a few usage examples for a library will not make you a master of it, nor does it mean that itās the perfect fit for every situation that will come up in your project. Be continually critical of everything you use.
29. Not getting help when youāre stuck
Keeping a short feedback loop will always be less painful for you. Asking for help doesnāt mean that youāre incompetent. The right people will see your effort and admission of ignorance as a drive to learn, and thatās a great virtue to have.
Testing and maintenance
30. Writing tests to pass
Writing tests that you know will pass is necessary. They will make refactoring and reorganizing a project much safer. On the other hand, you also have to write tests that you know wonāt pass. They are necessary to move the project forward and keep track of issues.
31. Disregarding performance testing for critical cases
Prepare an automated performance testing setup at about the middle point of a projectās development process so you can make sure you donāt have escalating performance problems.
32. Not checking that your build works
Itās rare when a build passes but doesnāt really work, but it can happen, and it might be troublesome to fix the problem the longer you wait to look into it. Quickly testing every build is an important habit to have.
33. Pushing large changes late, or leaving after making a large push
This is where overconfidence will get you, and it can take getting burned multiple times to learn why you shouldnāt do this, so take my advice now and make sure you are always there when your build eventually breaks.
34. Disowning code you wrote
Be willing to support code you wrote. You are the most suitable person for helping others understand it. You should strive to make your code remain readable to yourself and others many years from now.
35. Ignoring the nonfunctional requirements
When youāre trying to deliver something, it can be easy to forget about some important areas such as performance and security. Keep a checklist for those. You donāt want them ruining your party because you drew up your deadlines without thinking about these nonfunctional concerns.
What are your worst programming habits?
As itās often said, we are creatures of habit. Improving the way you work through habits is a great way to avoid having to think too much about every single situation. Once youāve assimilated a good way of doing something, it becomes effortless.
Note: this post was originally featured on TechBeacon.
ankcody.wordpress.com 