Table of Contents
When developing a larger codebase with several teams it can be challenging to hold everyone to the same standards. Sure coding standards can be forced, but some other things are much more difficult to force. In this blog post, we will take a look at how we can use the science of habit building to make sure developers do the right thing, or maybe even more important: do not do the wrong thing.
I’m a big fan of James Clear. The guy wrote Atomic Habits and has a pretty awesome blog. In one of those blog posts How to start new habits that actually stick, James describes the four stages of a habit. For full in-depth information, I recommend reading the article. In this post, we will focus on a subsection.
In programming, what makes developers take shortcuts? If we don’t take pressure and deadline stress into account. It is usually that the right thing to do is hard, and the shortcut is easy. Why write a migration for a data change if you can “just” click it in an interface? Sure it is much more error-prone, but also much faster!
In general, we want to make it easy to do the right thing, and hard to do the wrong thing. Let’s take a look in more depth.
Making it easy to do the right thing
There are four steps to making a habit stick.
- Make it obvious
- Make it attractive
- Make it easy
- Make it satisfying
Making it hard to do the wrong thing
We can invert these laws for the opposite side.
- Make it invisible
- Make it unattractive
- Make it difficult
- Make it unsatisfying
Years and Years ago we had a big MYSQL database with all our information in it. As it was pretty common 10-ish years ago, all developers had write access to the production database. In case we needed a quick fix or something. Over the years this grew into an anti-pattern. We noticed that there were features that were left unfinished because “we can just run a query by hand every day”, or that root causes where not identified. Since it was so easy to fix it by hand.
It took a developer with balls, and a lengthy discussion to get most of the devs on board. Of course, the frequent offenders did not agree.
We tackled this solution by:
- Revoking write access for everyone. (Made it invisible)
- Created a repository where migrations could be written that could only be executed once. (Made it difficult)
- Said migrations had to be reviewed by a member of an appointed group to make sure we did not misuse migrations for structural fixes. (Made it unsatisfying)
Not to our surprise, we found out there were a lot of things that were kept hidden by manual work. Having these migrations made it painfully awkward for everyone.
Before you go
Making sure people do the right thing is all about making it attractive and easy to do the right thing. And making it hard to do the wrong thing. You can use this science of habit building in more places like processes, developer experience, and more.
If you liked this post I recommend the following as well:
- How to create a culture where failing is acceptable
- Hanlon’s razor, a great tool to be more positive
Or you can subscribe to the newsletter.