Want to Code Faster? Timebox Impediments
Confession: Last week I burned an entire morning configuring SSH key authentication on our Enterprise Github account. I tried everything I could think of, but continued to receive authentication errors. When I was finally exhausted and out of ideas, I called over a co-worker. She fixed my problem in two minutes. Seriously. Two minutes.
I knew she’d set it up SSH keys on her machine successfully just last week. Yet I struggled alone for hours. Out of arrogance. Out of fear of looking stupid. Out of pride.
I was relieved to have the issue resolved, but had an epiphany: We make this same mistake all the time. We soldier on for hours on issues that someone could help resolve in minutes.
You’ve been on the other side of this interaction many times before. You’ve seen co-workers battle simple issues for hours. You walk up and ask “how’s it going?”, only to find it’s a fundamental design flaw that you can quickly resolve.
Key principle: The team is smarter than the individual
So, today, my team is trying a new habit: Timeboxed impediments. How’s it work? Simple: Only allow one hour of “churn” before asking for help.
One hour. That’s it. If stuck, start a timer. Once it goes off, it’s time to reach out. Impediments are timeboxed so we don’t spend hours on an issue that someone else could help resolve.
Pair programming is awesome, but this isn’t a mandate to pair program until resolution. It’s merely a commitment to discuss the impediment, consider potential paths forward, and consult others who can help guide next steps.
An Impediment Pomodoro
The pomodoro technique has a simple premise: Work in short timeboxes to enhance focus. The timeboxed impediment philosophy works for the same reason. When you’re in a timebox, you focus because you’re on the clock.
I turn off my phone, Twitter, email, and go heads down during my pomodoros. This is especially important once I’ve entered a timeboxed impediment. I need to focus because I have one hour before I have to swallow my pride and ask someone for input.
Why An Hour?
There is a careful balance at play here. If the window is too short, the developer misses the opportunity to learn through exploration. Spoon-fed solutions from a co-worker are less valuable in the long-term than learning on your own. Why? Because you tend to learn many other concepts while searching for the answer. One hour is a starting point that balances the need for exploration with efficiency.
Become a Rubber Ducking Success
Timeboxed impediments are a form of rubber duck problem solving. When we’re stuck, verbalizing our situation engages a new part of our brain. It forces us to think about the problem in a different way.
Ever walked over to a co-worker and began “Hey Bob, I’m really stumped. Each time I set a breakpoint, the API goes…woah, nevermind, I know the problem. Thanks!”. Bob smiles as you walk away, feeling smug that he helped you out by merely listening.
Ever started to write a question on StackOverflow only to get half-way through and realize the solution?
These scenarios show the rubber duck principle in action.
Documenting why you’re stuck exposes new pathways to the solution by forcing a justification of your methods.
One final bizarre reason to reach out for input regularly: We’re better at solving other people’s problems than our own. Studies have shown we’re more creative when we think we’re solving a problem for someone else. So if you’re stuck, get someone else engaged!
What If I’m Remote?
This works for remote employees too. In fact it’s even more important because it’s so easy to churn on a problem when you’re sitting alone. Timeboxing encourages remote workers to reach out. There are many great tools for remote collaboration including Hangouts, Skype, GoToMeeting, Join.me, Zoom.us, and useful Slack integrations Sketchboard. I even prefer pair programming when remote because the code is easier to see when I’m sitting directly in front of my monitor instead of hovering awkwardly to the side.
Bottom-line: Next time you get stuck, start a timer.
Anyone Doing This?
Have you tried this approach? What do you call it? Is it working? I’d love to hear feedback.
Cory House is the author of “Building Applications with React and Redux in ES6”, “Clean Code: Writing Code for Humans” and multiple other courses on Pluralsight. He is a Software Architect at VinSolutions, Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding.