What can Paul Graham teach us about testing?

Of Paul Graham’s many essays, one of the best is the maker’s schedule versus the manager’s schedule. We think that it has a lesson we can take to the way we think about software testing, particularly when owned by engineers.

At the moment, software businesses are more and more encouraging engineers to “own” quality to encourage them to produce better code. But what does that mean for productivity?

The essay, summarised...

Put briefly, The Maker’s Schedule vs the Manager’s Schedule talks about the different time costs of meetings between “makers” and “managers”.

Makers are people involved in long-form focus work who make things, including engineers.
Managers are people involved in organizing and communicating between makers. They include sales professionals, senior managers, and some kinds of product managers.

Graham argues that for managers, a meeting costs only the half-hour slot in which it is allocated. But for makers, the cost of meetings is huge:

“One meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning […] ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.”

If Paul is right, this is huge. Given that software engineers are among the best paid “makers” out there, it makes sense that interrupting software testers for short meetings (or anything else) is an expensive business.

If you’re an engineer, how many times do you stop coding per week in order to take meetings? When you plan your time or your team’s time, are you factoring in refocus time?

The science seems to back Graham’s point: research cited by Atlassian show that it can take up to 30 minutes to refocus after an interruption in the context of long form work. Added up, thirty minutes is a lot!

How is this relevant to testing?

PG focuses on meetings in his essay, but the same is true of testing: we’ve read that after all interruptions are counted, engineers spend just 32% of their time writing new code or improving existing code. They spend 12% of their time testing and not coding. So just as with meetings, there’s a huge benefit to thinking about how we can reduce interruptions to our coding which relate to software testing.

So, how can we reduce the amounts of breaks from coding we’re taking to test? You can find out in the next blog, which is all about how to reduce the number of interruptions to your coding which relate to software testing.

Read the next article