OftenIt

Common Habits That Kill Developer Efficiency

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! 

  1. 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. 

  1. 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: 

If you answered “no,” fix things before calling it done. 

If you answered “yes,” then provide the necessary information before calling it done. 

  1. 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. 

  1. 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

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.

Exit mobile version