Skip to content

7 Practices Of Highly Effective Developers

Effective developers are consistent and honest with good habits that brings them and their team forward.

TheNimblegeek
TheNimblegeek
5 min read
7 Practices Of Highly Effective Developers

The outcome of your work as a developer is determined by your daily habits and practices.

During my years in product development and IT I have observed developers in various domains and been inspired by a few.

The practitioners that have made the most impact on me have all been comfortly honest and aware of their daily work and what truly makes an impact.

Lately I have started to obsess about what makes a good developer great and effective.

In this short article I present a snippet of my findings so far and I hope these basic habits can lay a foundation for you in your own developer journey.

1. They Commit Often

The software development craft is a creative endeavor. And as most creative crafts out there there is a huge need to try out, break things and branching out.

This is why version control is so powerful and effective.

Assuming you are well versed in this practice I would like to drill down on the importance of doing small commits. Very often.

Whenever you have a successful build or unit test complete, commit with a straight forward comment. So you easily can go back to it if you get stuck.

Don't Push It...Yet

A good advice I got from my mentor was that you shouldn't push every commit.

Consider your local commits as your "dark secret log". It's healthy to not push every small change you make. Because not all fixes and tinkered solutions are relevant as part of your pull request.

Just like the mountain-climber attaching the hooks on the wall whenever progress is made, your commit is your safe-spot to jump back to when next problem occur.

So whenever you have a successful build, your unit tests are completed or when you are completed with an important function, commit it!

Then continue to tweak and tinker your way forward.

2. They Know When To Use A Testdriven Approach

For some practitioners going for a Test Driven Development approach is the preferred way. But it is not always the best practice.

This comes with experience of course and it is all about trade-offs.

Since the outcome of test driven development (mostly) result in more robust code and solutions, this comes with some costs:

  • Harder to go back and rebuild and re-factor
  • More code to be written
  • Test written for trivial code, are we really testing the right thing?
  • Difficult to design test before implementation is done
  • Kills the creative process

Just to mention a few, there are more aspects to this of course. Here's a another good dialogue on his topic.

As a curious and being more of a junior developer, for me it was an eye opener this week when my mentor asked me what approach I would take when continuing with my first micro-service project at work. I assumed a test driven approach and he asked me why and asked a follow up question, similar to:

When using frameworks like Spring, Angular or React, how do we know whether we are testing our own code or the framework's/library's code?

A useful thought to digest before you choose your development approach.

3. They Are Assertive

Never be too sure about it. If something can't happen, use assertions to ensure that it won't. It's like an antagonist to Murphy's Law:

Anything that can go wrong will go wrong.

For example, if you have a parameter that should never be null, make sure it won't:

assert (result !=null);

When writing Java code we should also use a descriptive string to it:

assert (result !=null) && result.size() > 0 : "Empty result from XYZ";

This habit makes it more comfortable and less error prone because you never know what types of bugs that may appear as you proceed.

4. They Use The Power Of Command Line Tools

An early lesson I got when I on-boarded my team earlier this year is that you can do a lot of work using command shells.

If we consider applications like Git Bash, Terminal or CMD in Windows they are super powerful tools to that you can use when you don't have a GUI in place for example. Opening up powerful tools like curl for instance.

I like the analogy, that David Thomas and Andrew Hunt used in The Pragmatic Programmer to these tools as being the "workbench" for a developer. Just like the woodworker use a workbench to craft their creations, the software developer use command shell and command line tools to easily access files, run scripts and even work effectively with version control.

5. They Finish What They Started

This goes for bigger and smaller tasks.

Close your micro's. Like making sure your loops and functions doesn't contain any loose strings, circular references or whatever bug-seed you might have in your code.

Completing the bigger chunks of work, like the habit of wrapping up your Jira tasks and smaller projects in a good way. Making sure documentation is up to date. Or perhaps closing that open dialogue you started with the other team last week.

It is so easy to get piled up with new stuff, saying yes to new tasks as you become bored and stuck in difficult problems.

But this will only make you miserable and leave you without any progress.

6. They Are Familiar With YAGNI Exceptions

YAGNI = You Ain't Gonna Need It refers to the habit of spending your "resources" wisely. You shouldn't build something that is never going to be used.

But there are some exceptions to take.

...there are some things which really are easier to do earlier than later ...

Knowing when to deviate from the principle of "You Ain't Gonna Need It" is a powerful skill.

Source: lukeplant.me.uk

You can read more about it in this article, by Luke Plant.

7. They Refactor Early and Often

As a final habit, I want to highlight the habit of refactoring. Doing it whenever is needed, usually based on these trigger points:

  • Duplication of code
  • Outdated knowledge
  • Performance - moving functionality from one area to another
  • New Requirements appear related to implemented code
Refactoring, as with most things, is easier to do while the issues are small, as an ongoing activity while coding. David Thomas & Andre Hunt, The Pragmatic Programmer.

The habit of refactoring is crucial and being nimble enough to know when to re-factor is a valuable skill to have. Both individually and as part of your team.


Photo by Jared Erondu / Unsplash

Do you agree on the above? Do you find more habits and traits you want to bring up?

Let me know in the comments below 👇🏽

Programming