An educational doc you can rely on
The difficulty lies not in the new ideas, but in escaping the old ones. John Maynard Keynes
Keynes is telling it true for developers. Sometimes the sheer size and complexity of existing systems can take up so much brain space that it’s hard to innovate and create something new. And this can be a hurdle in the sprint for better reliability.
If we want to help developers and engineers break new ground and make meaningful improvements, we need to ensure their existing systems aren’t already demanding too much of them mentally.
Daniel Terhorst-North uses an interesting phrase to elucidate the point. In order to emancipate engineers, we need to be sure that their current systems can be described as: “software that fits in your head”. This is a neat, tidy, and visually-pleasing way of making sure developers aren’t overwhelmed by their own projects.
The idea and implication is that we should always have the mental capacity and availability to understand our projects, and visualize the impact of the decisions we’re making when we code. With too much going on, developers are never at their best. Sure, most engineers can stack a lot onto their plates (pun very much intended) – but that doesn’t mean it’s the smartest way to eat.
How do we make sure our software is the right size? Well, we believe it’s all about measuring cognitive load.
Cognitive load is a way of measuring the burden placed on people while they work – in this case, developers and software engineers. It’s another way of asking: “how much do you have to think about right now?” And then, crucially, “how much brain space do you have available to do good work?”
In one sense, this is a modern take on a very traditional form of team management – looking simply to get the absolute most out of a talented team of software engineers. In another sense, the relevance of cognitive load is indicative of a new approach to business. Today, the most successful companies are typically those who look out for their employees – making real time to care for their well-being and to keep them happy in their daily work.
Modern-day Mother Theresas? Or simply savvy management minds, keen to maximize productivity in today’s workplace? It matters not, because the outcome is the same: cognitive load has consequences for the way developers work, and it’s becoming increasingly interesting to those with a stake.
In short, the greater an engineer’s cognitive load, the more risk averse they become. There’s a lot being asked of them, and the last thing they want to do is create even more work for themselves unnecessarily. So it follows that they do the simple thing, rather than innovating. Too busy to take risks? End up with defensive engineering, reacting to problems as they emerge, rather than taking the time to pre-empt issues that – who knows? – may never rear their ugly head if left entirely alone. After all: what problem is the boogeyman if he never visits your house?!
It may seem intuitive that defensive engineering – that is, not taking many risks – is a good thing for something like reliability. It sounds safe and secure. And that may be true at times, when you’re trying to establish a solid foundation.
But when you’re trying to achieve elite results (in development terms, when you want to see a lot of 9s across the board) it always takes an element of creative thinking. That inevitably means taking risks, and having developers push themselves on a daily basis.
In order to do that, managers need to keep an eye on their teams’ cognitive load. They need to avoid exhaustion and over-working, and instead give their staff the mental space they need to have new ideas and approach systems in novel and intelligent ways.
In the tech world, we’re spoiled for choice when it comes to metrics, monitoring, and observability. So when something needs quantifying, our first thought is obvious: there must be a tool for that! In the case of cognitive load, the best tool you have is right there on your face, below your nose. It’s called your mouth. Use it.
There’s no better way to understand how much mental effort is being demanded of your developers and engineers than simply talking to them. Ask them how well they feel they understand their systems, and how complicated it is to observe and make changes on a daily basis.
And this applies to entire systems. If you’re running microservices (?) and have siloes between different areas of your team, it may well be worth asking people how well they understand other aspects of the system, and not just their own.
And remember: cognitive load is not a fixed metric. Capacity varies massively from one developer to the next, and even within individuals. With increased levels of stress comes diminished mental capability. So there’s a tangible benefit to creating a low-stress working environment, and helping delivery teams take control of their work-life balance. That’s a no-brainer (!).
If cognitive load is linked to levels of stress and happiness, then it’s worth sparing a thought for rewards. The problem? Reliability work can be abstract and intangible. Engineers often don’t see the positive impact of their work, or any impact at all. In fact, when a reliability engineer does their job superbly, exceedingly well, the outcome is absolutely nothing – just the absence of disaster. And that can be mentally exhausting, rather than rewarding.
We thrive on measured success and positive feedback. The dopamine that comes with it. So make progress real, show engineers the impact they’re having: actualize graphs and numbers, and use this information to empower and reinforce their good work.
This will make them happy and provide a sense of accomplishment and fulfillment, which will in turn increase their capacity to take on greater responsibilities and amounts of cognitive load. Good news for both Mother Theresa and her savvy manager.
If merely “talking it out” feels a bit, well, analog to you, there are a variety of more formal and scientific ways to measure cognitive load. Task-induced pupillary response is one way to measure cognitive load, and specifically the impact that certain actions have on the working memory.
Interested parties may also look to relative condition efficiency, a theory developed by Paas and Van Merriënboer which combines effort ratings with performance scores. This isn’t the place to discuss deep levels of cognitive theory, but we promise to include a list of recommended further reading for anyone with the interest and, well, cognitive availability.
One straightforward way to reduce cognitive load is to make your work easier. Automation plays an important role in that. But intelligent automation plays a really important role.
Reliably is built around the importance of the cognitive experience of both the end-user and the developer. We strongly believe that our product has the power to transform the daily life of site reliability engineers – reducing their cognitive load by not only automating basic tasks, but also providing clear, actionable tips on how to make positive changes to their system.
Doing reliability in the first place is about peace of mind. Knowing that you have a reliable system can be a colossal weight of your mind – and this is true for managers and engineers alike. But by making lighter work of the journey towards greater reliability, we genuinely feel that we’re making a monumental difference to the lives of software engineers.