Don’t accept the status quo

Ever been on a project where the build takes way too long? Or the tests are flakey? Or getting your environment setup is a long, laborious and error prone process? Most engineers have experienced this at some point in their careers. Interestingly, engineers get used to it. Over time, these initially irksome and grating issues become part of what it means to work on this project and they dissolve into background noise. However, this background noise has a persistent tax on productivity and job satisfaction.

This is a well-known process called habituation. Humans are really good at taking stimuli that are noticeable at first turning them invisible. It is like when you walk into a new room and you notice that it smells different. If you then spend 30 minutes in that room, the smell seems to vanish. Your body acclimated and habituated to your environment and set it as a new baseline. That is what happens on software projects. The build is slow but you get used to it. Deploying a local test environment is annoying but you get used to it. There are problems and inefficiencies but you learn to live with them.

What’s at stake?

Unlike getting used to a smelly room, there are some large costs to becoming too habituated on a software project. First is “death by a thousand needles”. A number of small annoyances compound and can greatly decrease developer productivity. It may seem small at first but over time the team’s ability to deliver new customer value can grind to a halt.

Secondly, habitually poor engineering systems can drive engineers off of teams. I have seen several engineers become frustrated with the time it takes to build, deploy, test (the developer inner loop) and decide to leave the group. Making sure the development experience is enjoyable and smooth is a table-stakes item for retaining talent.

There are ways to fight against this habituation and improve the developer inner loop and the quality of the engineering system.

Empower New Hires

One of the best methods for improvement is to empower people who are not yet habituated. When a new engineer joins the team they see all the warts, pains and issues fresh. This is an invaluable resource and it’s imperative to ensure they feel safe questioning the current system and advocate for how to make it better. It is common for a new engineer to feel worried about not “rocking the boat” but it’s important for them to know their feedback and thoughts are important in order for the system to evolve and improve. In fact, I often ask new engineers to help fill any missing documentation that can make the the onboarding process smoother and to point out the parts of the engineering process that are confusing or annoying to them. Listening to their experience can lead the team towards self reflection and realizations like “I am so used to that, I didn’t even realize it was that bad!”. This insight can drive improved experiences across the team.

Surveys/Retrospectives

It is critical to routinely ask engineers to share what is bothering them in order to unearth habituation that may be negatively impacting your team. General questions like, “What could be better?” may not lead to much revelation, so ask more targeted questions:

• “What are your biggest gripes in our build system?”
• “What most gets in your way of solving live site issues?”
• “What part of the development process forces you to sit idle the longest?”

Those types of questions will lead to more specific and honest responses, and get you a better pulse on where to improve.

Incorporate these into a periodic survey sent to all engineers, or even better, discuss in retrospective meetings specifically focused on engineers’ work experience. Creating a forum for this open conversation can spur a snow ball effect where one engineer points something out and it “shakes” others out of their habituation and they realize “Oh yea, that bothers me too!”.

Dedicated Time/Resources

Set time and resources aside to focus on the developer experience in your group. Depending on the size of your group the look of this will vary. You may assign one developer every few weeks to dig into areas for de-habitualizing, or you might create an “engineering improvement” week. Some teams will build this lens into their normal workflow, ensuring they are always focused on improving systems and habits.

Often, engineering system improvements provide a good amount of low hanging fruit that provide quick results and a large sense of reward, encouraging continued work towards this end.

Do Something

We all get used to things that are less than ideal. Ensure you take advantage of ways to see past habituation and find what drains team productivity. Dedicating the time and funds to this reflection and growth will quickly become a vital and rewarding habit that your team will want to hold onto.