A good while back, “Uncle” Bob Martin tweeted the following:
It’s easy to read that tweet and imagine an insufferable coding diva who demands the very finest mechanical keyboard and has a software rider a mile long.
This clearly isn’t what Uncle Bob had in mind, though. The point he’s making is that rushing is never the right thing to do. Try to move quickly, sure. Be mindful of the timescales and deadline, or course. But don’t rush, don’t panic, and don’t make rash decisions.
It reminds me of another quote:
“Worried that TDD will slow down your programmers? Don’t. They probably need slowing down.”
J. B. Rainsberger
We all have deadlines to work to but rushing ahead full-tilt isn’t usually the best way to maximise productivity. The US Navy Seals have a neat, paradoxical mantra, which when the adrenaline is pumping reminds them not to charge headlong into a firefight and get themselves shot:
“Slow is smooth, smooth is fast”
Apparently the motto has its origins in the rifle range, where deliberate, controlled, coordinated action is more effective than desperate fumbling. Calm, considered action is ultimately more effective than going too fast and making costly mistakes.
I remember reading a while back about an interesting experiment where they had volunteers playing Pacman while wired up to sensors that monitored brain activity. The idea was to see how stress affected the brain activity of the subjects, and what the experimenters found was that when the subjects weren’t under much pressure and had plenty of room for manoeuvre, they used areas of the brain associated with higher-order cognitive functions and conscious awareness. However, when the subjects found themselves in a tight spot and had much less time to react, the more conscious parts of the brain shut down and the evolutionarily-older, more instinctive areas took over.
This seems to explain why, when we panic, we get that feeling of being less in control: our conscious thinking gives way to instinct and reflex as the pressure increases, and our decisions start to focus on getting out of the situation as quickly as possible to escape to source of our anxiety, rather that on taking a step back and working things through calmly.
This makes sense from an evolutionary point of view; we probably had potential ancestors who were weeded out of the gene pool when they were faced with a saber-toothed tiger and, instead of running like hell, carefully weighed up their options, carried out a risk assessment and gave due consideration to outsourcing their escape solutions to an external consultancy.
Writing software is a high-order cognitive process. It’s extremely abstract, requires significant concentration, and is therefore very difficult to do under fight-or-flight conditions. It’s more a job for the frontal lobe than the hypothalamus, which is the main reason you find very few lizards with committer status.
As a result, developers will do better work if they’re calm, relaxed and focused. We all know that feeling of being in flow, when you’re in an a nice feedback loop with your tools, nothing is getting in your way or interrupting you, and you suddenly realise you’ve been working for hours and didn’t even notice. Sadly it doesn’t seem to happen that often, but this is the state in which developers should ideally spend most of their working life: in a calm, focused state making steady progress, rather than in a frenzy of panic because the code has to go out tonight.
Stress and pressure causes errors and lead to shortcuts being taken that cause further work. If the house you’re building is on fire, you need to down tools, put out the fire and assess the damage, not try to build faster.
So what can you do? We don’t live in a ideal world. People are messy: we don’t always do the right thing, we don’t always make good choices, and our circumstances are often far from ideal.
I’ve always liked the following advice:
Grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference.
Reinhold Niebuhr
What You Can’t Change
- Estimates are hard, and you’ll get them wrong.
- Customers will always demand more than you can deliver.
- Your tools and processes will never be perfect.
- You will often have to make compromises.
- You’ll make mistakes.
What You Can
- Don’t try to do everything. Successfully juggling three balls is a better result than dropping ten on the floor.
- Take time to think things through – a stack trace isn’t a predator you can defeat with adrenaline and a piece of flint.
- Leave some slack in the schedule. Accept that developers don’t spend 100% of their day writing code, and that things will come up you didn’t plan for.
- Leave room for error. Estimating is hard and mistakes will be made.
- Invest in your tools and processes to give you a safety net and allow you to focus your effort where it counts. Spending a week automating a manual, error prone process that takes a day but needs doing every release is time well spent.
- Pay down technical debt. Building on shaky foundations never ends well.
- Minimise interruptions and distractions. Pulling one person into a 1-hour meeting will cost 2 hours when you factor in the cost of context switching.
- Recognise that quality isn’t an overhead: it’s a cost reduction.
- Be honest with yourself, your team and your customers.
- Remember to breathe 🙂