4 Habits That Make You an Inefficient

Developer
You’re not a bad developer, you just have some bad habits

We’ve all got them. Bad habits. No single person on this earth is

perfect.

Having bad habits as a developer can seriously hurt your efficiency.

They can also impact the people around you.

Jack Canfield says: “Your habits will determine your future”. If you

want to grow as a developer, you have to break your bad habits. If

you can do it your efficiency will grow dramatically.

Let’s go over the bad habits that you should try to break as soon as

possible.
Saying Yes to Everything
Let me start by saying that it’s admirably humble and unselfish to

say yes to everything. It means you’re willing to help other people,

probably at your own expense.

But saying yes to everything is a huge productivity killer. At the end

of the day, you probably have to deliver some code yourself.

I’m not saying that you shouldn’t help other developers. I’m just

saying it shouldn’t kill your productivity. Some developers tend to

ask a lot of questions — for every little thing they come over to your

desk asking for help.

Paulo Coelho nailed it when he said: When you say “yes” to others,

make sure you are not saying “no” to yourself.

If you find yourself having difficulties saying no, it might help you if

you only let people come to your desk at certain times — giving

yourself some “focus time” where you can get some work done.

This also forces other people to start looking for a solution

themselves, before they blindly march to your desk. If they really

can’t come up with a solution, they can write the question or

problem down. Eventually, they show up with a list of questions at

your desk. This saves you a lot of time because you will only be

interrupted once instead of being interrupted by each question on

the list one by one.

Your Definition of the Word “Done” Is Probably Not

Really “Done”
The reason that the definition of the word “done” differs for

developers and other people is probably that they have 10,000 other

things to do. When working in an agile team, for example,

developers want to finish the sprint. This is under a strict time limit.

Developers feel like they have no time to waste.

Although the definition of the word “done” differs, it probably

includes more than just writing a piece of code for a fancy feature.

Whenever you think that you are done, you should at least take the

following things into consideration.

Did you refactor your code? And if you take a critical look at your

code, do you think that other developers understand it? If the

answer to one of the questions above is “no ”— fix it!

What about documentation? Is it required for this feature? Did you

let the tester know how the feature can be tested? Are there any

prerequisites that the tester needs to know about?

Telling tester how a feature should be tested saves a lot of time for

both of you.

Did you know that, according to Gloria Mark, who studies digital

distraction at the University of California, it takes an average of 23

minutes to return to your original task after an interruption?

Last, but not least: did you test your work? By testing I mean not

only the happy-path scenario. Speaking of testing, that brings us to

the next bad habit.

Not Testing Your Own Code

The favorite part of being a developer is definitely not testing. Most

developers are even a bit lazy when it comes to testing their own

code. Clicking through the happy-path scenario is probably all you

get from most developers.

This bad habit will lead to a lot of extra time spent delivering the

right feature. If you don’t test your code the tester will probably find

a bug within a minute, which you could have easily sniffed out

yourself if you had just tested your code.

When the tester reports a bug you have to touch the same code

again. In addition, the tester needs to test the feature again once

you’ve fixed the bug. This is not very time-efficient.

“But testing increases development time.”

No, it doesn’t. This is a common misconception. Testing only

increases development time initially, when you’re just starting to

learn how to test properly. You should stick with it and make it part

of the development process so that it becomes a good habit. Testing

will save you a lot of time and headaches in the future.

Making Commits That Are Much Too Big

One very inefficient habit is making your commits too big. Large

commits lead to not being able to see the forest for the trees.

Because so many things have changed in the commit, it is unclear

what has actually changed.

Besides that, how would you feel when you have to review a commit

that has over a hundred changed files? You would be probably

cursing. You probably would feel unmotivated to thoroughly review

the commit.
Small commits are your friend. They make it possible for the

developer to give a descriptive commit message. I’m sorry, but

“fixed some issues” is not a descriptive commit message.

Code reviews get easier with small commits. They make it possible

to review one change at a time, giving the reviewer the opportunity

to understand the thought process of the developer.

Making small commits your code gets easier to debug as well. It’s

easy to roll back to a certain commit to test whether a bug also

exists there. Once you’ve found where the bug was introduced

there’s not a lot of code that could have introduced that bug, if the

commits are small.

This will make you much more efficient, for not a lot of effort.