Why Testing Accelerates Burnout
I’ve observed a few reasons why professional developers will either not write tests, or be reluctant and slow about it. These problems ultimately leak into the rest of the work. Here are some things that could be draining their motivation:
- The infra sucks
- Your teachers suck
- Your boss won’t let you test
- You have a mismatch between what you’re testing and what you’re held accountable for delivering
I. The Infra Sucks
Creating software, generally, should summon the delight of the builder instinct within you becoming quenched. When the testing infrastructure sucks, this is impossible.
Your testing dataset is unreliable or absent. They take forever to run, break a lot, and suck to debug. Some tests are scary to run because they aren’t isolated from prod somehow. Bad things are happening, but there is one symptom of bad infra that, by far, smothers your fire:
When the infra sucks, you are denied the opportunity to work close to the limits of your abilities on something that feels clearly important. You feel that, within your constraints, if you made your assertions as meaningful as you could, you would be unable to explain how your tests prove that the user will get the service that you were supposed to deliver. Your tests pass, while you and the product fail.
Your tests should paint a clear picture, but they don’t. To illustrate, if your tests were trying to show you a literal painting, they would not simply tell you what was depicted in the painting, like “A Seattle Landscape”. Instead, your tests are obsessively describing the angle, direction, and velocity of every sequential brush stroke.
What are your tests even about? Why do that matter? To whom? Have we been critical in our thinking about all that? Transparently so?
At best, these specifications are well-thought-out in early-quarter planning, but such subjects are only implicitly discussed within your tests, and what is rightly text is clawed into and dragged downward unto the subtextual.
At worst, such subjects are ignored. They are given a nod from Product in a docs page, and in subsequent meetings we habitually speculate whether we can find evidence of them in the software or not. Maybe we don’t even do that, and off we go charging into the next big thing.
And why? Well, your tests couldn’t make assertions on the OKRs directly in an environment with the required level of realism to do. Even the habit of moving on too fast to the next project is often a symptom of having collectively given up on the testing capabilities of the engineering organization. The infrastructure sucks, and you’re stuck checking if your 78th-89th brush strokes are using pale yellow pigment at 30º angles, and everyone forgot to check if you made an actually photorealistic Seattle landscape in oil on canvas at the end of the day.
As a result, you are robbed of your ability to join your team in celebrating the demonstrated achievement of a well-formulated goal. You cannot have any of the moments which could very well have been the most dopamine-inducing of your career. Despair.
Does your software even matter at all? Does your job even matter? Are you merely contributing to the impressiveness of your company’s headcount? Those thoughts are burnout.
II. Your Teachers Suck
Learning is slow and difficult:
You’re settling in somewhere new. Frustratingly, you feel that testing at this place is way harder than it was at your last gig, and of course you do, because you haven’t even realized that you haven’t learned enough about how to use this new damn framework the way other people do. You haven’t realized that you haven’t realized this because, well, you need help.
It’s like you keep passing out while doing deadlifts because someone needs to tell you when to inhale and when to exhale. Of course you think this new way of lifting things is dangerous and stupid. You’re doing it the dangerous, stupid way. It’s humiliating.
You can’t effectively initiate the creation of an environment that’s conducive to learning within one that’s hostile to learning. Someone needs to ambush you with the evidence that you are allowed to not know stuff, despite having a job primarily about knowing a lot of stuff.
To make matters worse, after you have this evidence, someone needs to basically spot you at the squat rack until you’ve demonstrated that you’ve stabilized the quality of your form. You will stumble on many things that are new, embarrass yourself by messing up stuff you actually already know, and become dangerously overconfident the moment you challenge yourself.
If there is someone available that has the know-how, the empathy, the patience, the good judgement of comprehension, and the good humor required to spot someone who is learning to test, and they do not ambush you with help, then they have failed you. If you are helped by someone who sucks, they will usually abandon you for things that feel more important before you’re ready, and they won’t even notice the damage. It’s humiliating.
Despite this, I have not met a single developer that wouldn’t enjoy looking back at a year to see dramatic improvements in their building capabilities. In other words, they all want to learn.
I have met comparably few developers that take responsibility for filling another person’s year with happy memories about the process of improvement. The negative association that creates tends to contribute to atrophy, outright complacency, a tendency to struggle to keep up with challenges, and then burnout as a form of nihilistic self-acceptance.
III. Your Boss Won’t Let You Test
If you are not allowed to validate that you’ve built what you’re accountable for delivering, it’s a lot easier to move the goalposts on what it means for you to be effective in your role.
Perhaps shockingly, being abused by your boss is a really efficient way to start hating your job. Despite that, the easiest way to stay employed is to power through without acknowledging what’s happening, even to yourself.
You have limits, though. You’ll get burned out.
IV. You Have a Mismatch Between What You’re Testing And What You’re Held Accountable For Delivering
When you don’t control your own fate, it’s hard to get attached to success or failure– at least, it’s hard to do painlessly.
Imagine someone broke your end-to-end test. They broke it, so reasonably, they should be the ones to fix it, but it’s your deadline at stake tonight, so fixing it is currently your problem. A normal Friday night for you.
It’s something in the backend, that’s all you can know for sure at first blush, but Friday-night exercises like this one have burdened you the gift of a disproportionately large understanding of the whole software system. You narrow it down to two services almost right away, and it gets hotfixed in an hour and half.
It’s exhausting to burn the midnight oil like this every week, both directly from lack of sleep, and indirectly by becoming the defacto human-wiki of the engineering organization. You are rewarded for all your hard work by being on-call for everything, plus a constant stream of Slack DMs tearing you away from what you actually have to do to keep your job. It’s also exhausting to think about keeping your job.
Exhaustion is a mild form of burnout. Chronic exhaustion is probably burnout.
An Antidote
Problems in testing are rarely atomic units. They are inextricably interconnected to issues of intersectional topics. But to nevertheless rephrase the above, I think it’s a good idea to get leadership buy-in to hire someone good at testing, infrastructure, and mentorship. Let them set up the testing infrastructure so that it doesn’t suck. Hold them accountable for enabling assertions on paintings made by a painter, not facts about brush strokes owned by countless disjoint teams. Invite everyone involved in the software development lifecycle to think critically about the testing process, as well as the individual assertions. State assertions in terms of the fulfillment of business objectives and well-specified customer experiences. Generally, aim for test quality over test quantity.
