Murdoher Threshold
14 OctoberThe Backstory
To understand the Murdoher threshold we first need to understand the Doherty Threshold.
The Doherty Threshold is
When a computer and its users interact at a pace that ensures that neither has to wait on the other, productivity soars, the cost of the work done on the computer tumbles, employees get more satisfaction from their work, and its quality tends to improve.
And what exactly is that pace?
Provide system feedback within 400 ms in order to keep users’ attention and increase productivity.
Put simply, the Doherty threshold is the amount of time it takes a computer to fuck up your thought process.
The Brain’s Limits
Working memory, sort-term memory, procedural, episodic… they’re all limited in amount and duration, and they’re affected by our environment.
When we’re engaged in doing thought-work like designing, programming, testing, and debugging, our working memory is prime real-estate.
Above the Doherty Threshold
So things are “productive” below the Doherty threshold. Working memory isn’t used efficiently, and it feels like the computer is a tool helping get a job done.
But what about when the computer is slower than the Doherty threshold?
First, if it’s only a little bit above the threshold, it already feels slow. You feel like you’re being asked to wait for the computer before thinking your next thought. It’s like listening to someone telling a story who needs to take a break to sneeze. There’s a suspense. A feeling that the story should be progressing but there’s a momentary 4th-wall-breaking cliffhanger.
But, as programmers, we ask the computer to do things many times in a row. Add a log statement, recompile, run the test again, add a breakpoint, inspect a value, change a line of code, recompile, run the test again, etc. For some of us, the recompile step is always above the Doherty threshold, the “run the test again” step is also above the threshold, and even the “pause in the debugger” step, too. These are little sneezes, delays between what you were thinking about and being able to think the next thought.
Way Above the Doherty Threshold
What if it’s even slower? What if it takes 40 seconds to recompile and another 10 seconds to run the test?
The amount of time between an idea, testing the idea, seeing the result, and coming up with another idea is now ridiculous. We’re not programming in 1835 anymore with horse-drawn carriages and friggin’ abacuses. My working memory can handle it, but more than likely I’ll check messages from my team while I wait or I’ll make a little progress with something else altogether because WTF else am I going to do in that time? Stare at the thing I’m waiting for? Bullshit.
Introducing Humans as Thought Barriers
Back in my younger years I had a computer science professor who was fantastic at teaching, knew the material extremely well, and he would write code on a whiteboard with impressive accuracy. But if you went to his office with a question, he’d pull up the assignment on his computer by typing with one finger, slowly… painfully slowly. Everything he did on a computer, omgwtfbbq it took sooo long. This was my first real-life experience with the Murdoher threshold, but I didn’t know it yet.
Pair Programming and the Murdoher Threshold
I finally understood the Murdoher threshold while pair programming remotely during the COVID-19 era.
The Murdoher threshold is similar to the Doherty threshold in that they both relates to the time between inputting a command into the computing systems and processing the result it gives back.
The Doherty threshold is specifically about the total time from inputting a command, thorough the computer processing the command, executing the command, outputting the result, all the way until when you process the result.
The Murdoher threshold is all of that plus the time it takes for another human’s involvement as part of that process.
If I asked my professor “what grade did I get on the first assignment?” he could just check on his computer real quick. That’s a quick thing. Unless he’s Flash from Zootopia. The Murdoher threshold is the time up to when Zootopia’s Judy Hopps loses her patience. It’s the time just before SNL’s “Nick Burns: your company’s computer guy” yells “Move!”.
Importantly, the Murdoher threshold is personal and situational, just like the Doherty threshold. Pair-programming with a junior who doesn’t know the tricks of the trade yet - we all have high thresholds. And pair-programming with a senior developer who should really know by now how to quickly open a file but clicks and scrolls 10 times to eventually open a file which was only two keystrokes away? I am Judy Hopps.
Empathy break
Even the most experienced devs are still learning - all the time. They might not know the techniques/tools/shortcuts I know, and how will they learn if nobody tells them?