Kent Beck is a very accomplished software engineer, with seminal contributions to the industry since the mid 1990’s. He’s credited with inventing (or re-discovering) Test-Driven Development (TDD). He’s the creator of jUnit, and several other xUnit suites. He’s the creator of extreme programming (XP) and the author of the authoritative book on the subject: Extreme Programming Explained, as well as many other books.

Yet with all of these accomplishments, any one of which could make the average programmer envious, he claims he’s not a great programmer.

I’m not a great programmer; I’m just a good programmer with great habits.
-- Kent Beck

What does he mean by “great habits”? He elaborated on this in a Quora post. In summary, he says:

My books basically describe the habits: code for other people, work in small steps, rest well.

Kent’s concept of “great habits” has been with me for years, and it’s a guiding principle when I think about how I do my work, and how I train and mentor others to do their work. The concept of “great habits” has applications far beyond computer science and software devepment—the habitual use of check lists in industries like medicine and aviation are examples.

Both on my blog and on my YouTube channel, The Tiny DevOps Guy, I spend a lot of time exploring what I consider to be “great habits” for a software engineer to learn and adopt.

The importance of great habits

Most schools, universities, and boot-camps for programmers focus on the so-called “hard skills” of software development which might be summed up as “data structures and algorithms”. Of course we know this isn’t enough. In the last three decades, “soft skills” has become the new buzzword, as the industry has recognized that being a genius “cowboy coder” isn’t enough. We need to hire people with good communication skills, a team attitude, etc.

So where do “great habits” fit in? In my estimation, great habits overlap with both hard and soft skills, but they also transcend both.

If hard and soft skills are about “what” things we do, then habits are about “how” and “why” we do them.

In theory, a perfect programmer may not need good habits. They may be able to spin out a perfectly efficient, bug-free algorithm, on the first try, with obscure variable names, without type safety, and without writing automated tests. But such unicorn cowboy programmers don’t exist—except at costume parties.

This is why programmers throughout the industry rely on certain habits. Some have become ubiquitious (like the use of higher level programming languages intead of Assembly). Others, like TDD or CI/CD are now quite popular, but still not used everywhere. And still others are popping up all the time (BDD, the Mikado method, TCR, etc), to be experimented with—some will stand the test of time, some will fall into disfavor, and some may stick around for niche purposes.

What makes a habit great?

According to Merriam Webster, a habit is

a settled tendency or usual manner of behavior

Washing your hands before eating may be a habit. Biting your nails may be a habit. Commiting code after every small change may be a habit. Typing one-word commit messages might be a habit.

Of course, for a habit to be good, it must be beneficial by some measure. Long debates could be had about what is or is not beneficial in a given context, but I hope we can agree that nail-biting and one-word commit messages are not good habits.

So what makes a habit great?

A great habit, in my view, is a habit which somehow re-enforces other good habits. If hand-washing is a good habit, the being mindful of good hygiene would be the analogous great habit. It will lead to hand-washing, but will also lead to a plethora of other good habits: cleaning the kitchen counter, removing your dirty shoes before entering the house, etc.

Likewise, while commiting small changes may be a good habit, an analogous great habit might be: Be mindful of the future developers who will need to read or maintain your code. Such a habit leads to many more good habits: Writing good code comments, writing small functions, using descriptive variable names, etc.

The greatest habit

One habit stands out above all the the rest. And it applies to all human endeavours, not just programming. It's the greatest habit because it re-enforces all the other great and good habits, and diminishes bad habits.

Kent Beck put it like this:

Reflection is the ultimate habit. “How’d that last hour go? What could I have done better? What do I want to try next time?” Reflection leads to all the other habits.

Learn to reflect on your own behavior and performance–both professionally and privately. Learn to reflect on the behavior and performance of your team. Learn to reflect on the behavior and performance of your department and company.

Continuous improvement

Of course reflection in a vacuum isn’t going to cause any change. You might spend hours reflecting on your mistakes, and never correct them. This is where the closely related habit of continuous improvement (CI) comes in.

CI is the cornerstone of every (successful) Agile methodology. Scrum has the retrospective ritual. XP has its planning and feedback loops. LEAN has the concept of identifying and eliminating waste.

Without a habit of continuous improvement, all other habits will exist in a vacuum, and they will tend toward meaninglessness, and cargo cult programming.

For this reason, I encourage every team, and every individual developer I work with to adopt a habit of continuous imporovement first.

Don’t wait

Either retrospectives or post-mortems are great formal tools for intentionally seeking out areas for improvement. But the process doesn’t need to be formalized to work, especially for an individual or small or mature teams.

If you haven’t already, begin immediately to use these tools, or some other intentional habit to detect, define, and resolve problem areas. Doing so will give your team, or you as an individual, the framework necessary to begin incorporating all the other habits you may run into.