Habits Useful for Practising Software Developers

I sincerely believe that the micro decisions we make every day when developing software can have a huge impact on the quality of the systems that we build. This means that if we learn to make better decisions when faced with options, probably several times a day, the end result is a much better system.

In the book The 7 Habits of Highly Effective People, the author Stephen R. Covey defines a habit as the intersection of knowledge, skill and desire. Knowledge is what to do and why to do it. Skill is how to do something. Desire is the want to do it. Hopefully, this blog can provide the knowledge and skill necessary to adopt some new habits. The desire must obviously come from yourself.

The habits I believe to be useful for software developers are described here. Some are specific to software development while others are more general. None of the habits should come as any surprise; this does not mean they are easy to adopt on a day-to-day basis. Remember that knowledge alone is not enough to form a habit.

Write a Test First

Anytime you want to change the behavior of something, you should always try to first write a test that describes the expected new behavior, and then make the changes until the test passes.

Test-Driven Development (TDD) is an obvious example of using this habit when coding. Specification by Example is another example, where you specify functional or non-functional requirements as concrete examples using a tool such as FitNesse.

Don’t Document, Automate

Documentation is great for describing why you do something, and for giving the big picture of how something works. However, if you find yourself writing a to-do list, your first reaction should be to automate the procedure instead of documenting it.

This has the benefits of being testable and repeatable. And you do get written documentation as well; the automation script is a concise description of what is being done. The difference is that the script is a correct description while written documentation may start out as being fairly correct, but usually soon deteriorates.

An obvious example of this habit is using Puppet to automate provisioning of machines.

Publish Your Results

Very few systems are islands, most need to communicate with other systems and with people. In order to do so, it is important that the systems provide information about what is going on. Whenever you make a substantial change in the state of a system, try to think of others that may be interested in this change.

Examples of this habit are publishing domain events when a state change occurs in a system, and making sure to use proper application logging to make it easier to find problems.

When In Doubt, Do Something

If you are not sure what to do next, for example because there are multiple possible solutions to a problem, it is important to not just sit still and wait. By doing something you learn more, and move closer to a good solution.

Examples of this habit include spike solutions to try out a new technology, and reading a book while between assignments.

Everybody, All Together, From Early On

Make a habit of trying to communicate what you are doing to everyone who might be interested in the result. During a project, constantly try to identify new stakeholders.

Examples of this habit are having a brainstorming session at the start of the project to identify stakeholders, and to invite everyone interested to the sprint demos.


Published by


I'm a software developer with 20+ years of experience who likes to work in agile teams using Specification by Example, Domain-Driven Design, Continuous Delivery and lots of automation.

Leave a Reply

Your email address will not be published. Required fields are marked *