Bad habits: we all have them or—hopefully, after this article—had them. Why do we have bad habits? Maybe we were taught incorrectly, or we were unaware of better solutions. Antipatterns are part of being human, but it’s never too late to unlearn them. For developers, bad habits can make you inefficient and cost you time and money. Below we’ll discuss four bad habits that many developers have, that aren’t too difficult to break!
- Saying YES to Everything
Saying yes to things comes from a good place: you’re trying to help others. But, saying yes too much usually means you’ve begun to stretch yourself too thin and this is beginning to harm your own tasks. This is understandably difficult, especially when part of your responsibility is teaching or giving solutions to other developers, it can be tough to say no.
Why should you say no?
You have to meet deadlines and write or fix your own code as well! My recommendation is to set certain times where you’re open to help others. This is much more efficient because you’ve cut down on interruption time. Each time you provide a solution you also have to refocus yourself in your own work, which can take longer than you expect. When people know there is a certain window to approach you, their queries are usually more thoughtful and therefore easier for you to work through.
Furthermore, if you give too much help to others, they may not be developing their own ability to solve problems. If junior developers are looking at you each time they’re unsure (which is probably a lot), helping them can actually stunt their growth. Sure, you could tell them what the best solution is, but then they won’t learn why that solution is the best and more importantly why other solutions are suboptimal.
- Convincing Yourself Something is “Done” When Really…
Why do we say something is ‘done’ when it’s not? Or it’s ‘done,’ but it could be better. Because we’re busy and if other more priority tasks are being piled on our shoulders, then it’s easier and even a good idea to just call it ‘done.’
Calling something ‘done’ also differs depending on the development methodology you’re following. Having different definitions for ‘done’ isn’t necessarily wrong, it’s only negative when your own definition of ‘done’ isn’t covering a few worthwhile but tedious tasks.
Before calling it ‘done,’ ask yourself the following:
- Will other developers understand your code?
- Did you test things yourself?
If you answered “no,” fix things before calling it done.
- Is documentation needed?
- Is there anything the tester needs to know before they begin? (this will often save them a lot of time!)
If you answered “yes,” then provide the necessary information before calling it done.
- Leaving Your Own Code Untested
Testing can be annoying. We are all guilty of not testing our own code sometimes, and the number one reason we don’t is laziness. Or we will only undertake happy path testing, which can come back to bite us.
What happens when you don’t test your own code? The tester spots a bug almost immediately. This was probably a bug you could have easily found yourself.
The tester will then inform you of the bug, which means you have to go back to the same piece of code and fix things. Once fixed, the tester has to retest to ensure everything is running smoothly. This is common practice, you will probably have to do this anyway. The idea is, you only want to fix bugs you couldn’t have found yourself. The more bugs that make it through to the next stage, the more efficiency you lose.
The problem with testing is that it feels like it prolongs development. Initially it does, but only initially. Long-term, testing things yourself will save you and others a lot of time. For every time you’ve not tested and got away with it, there will be another time that causes chaos.
Think of testing as part of your development process to stop you from thinking “job done” too early. The more you test and learn to test, the less tedious it becomes. Testing your own code is a great habit to instill and will set you apart from other developers.
- Making Large Commits
Commits shouldn’t be big. A big commit is confusing, annoying and again, lazy. A large commit shows a lot of changes, but makes it very difficult to understand why or how, because they’re hard to sum up.
The best thing to do is put yourself in the next person’s shoes: would you be happy reviewing this commit? If your honest answer is no, then think of ways you could split it up into smaller, cleaner commits. You’ll naturally make smaller commits if you commit early and often.
Why you should commit early and often:
- Committing early means you can better understand what was most important during a set of changes and keeps the set of changes more isolated.
- It becomes a lot easier to write, clear and descriptive commit messages. It’s easier to document what the diff contained and ensure long-term readability.
- Clearer commit messages makes it easier to trace changes within the entire commit history. Anyone can make sense of why and how a change was made. This becomes very useful when trying to pinpoint the root of a problem.
- An easily readable history makes it easier to revert a commit without affecting more of the codebase then needed.
- Smaller commits are easy to share, this comes in very handy when merging.
- Your commit history is easier to clean up.
Correcting these habits will do wonders for your efficiency. Getting rid of bad habits means you’re eliminating unnecessary problems from your development process. The bad habits and I’ve outlined here won’t actually take too much effort to correct. Simple changes, but lots of value!
Identifying and destroying bad habits is what progresses professionals in all industries. Your working environment itself can encourage bad habits and inhibit your productivity. It’s why a lot of experts are choosing to work in coworking spaces. Read here to learn how your Mondays will be more productive with coworking.
If you’re a developer (junior or experienced) that’s looking for software developer jobs in Kolkata, we encourage you to meet the hiring team at CodeClouds. They’re a global development company and are always looking for fresh talent to join their team.