Talking Or Walking Away - Approaches To Maintaining Productivity

15 May 2018

Photo: jeshoots.com - Unsplash

Sometimes it is best to walk away.

I am not talking about ending a long relationship or changing job. I am talking about that situation where you work on a problem for so long you don’t see a way out. We have all been there.

As developers, our entire career is about solving problems. As our experience grows we become better and faster at solving them. You start to get to a point where you feel like nothing can stop you. Then every once in a while you hit a problem. A configuration that doesn’t work, code that you just can’t get to compile or a query that returns wrong data.

Through experience, I have found the best thing is to walk away from that problem and come back to it. The longer you sit and focus on it, trying any solution Google has to offer, your brain gets agitated. The more agitated you get the more frustrated you get. Your frustration changes and clouds your thinking. The alternative to walking away is to talk to someone about it sooner rather than later.

A member of my team expressed feelings of anxiety and worry this week to me over being stuck on a deployment issue. They had been trying to get a deployment to work on a cloud provider we do not normally use. They had spent a few days on the issue not getting anywhere and requested some help. The solution doesn’t matter here. What concerned me was that they told me they felt they were failing in their job by not solving it on their own. That my opinion of them would be reduced and that people might even start to discuss them in a negative light. None of these points was valid. No one else even probably knew what that developer was working on for starters. No one else would probably have been able to solve the issue anyway. These feelings all stemmed from the frustration of spending 5 days trying to solve the issue. This had reduced their feelings about their skills and the way they felt perceived by others.

The problem is actually worse for remote developers who work on their own. They have no one on had to recognise they are struggling or who they could talk to. And that is the key solution to most problems. I picked up on the issue through our stand up process (Slack-based rather than physical). Sometimes it’s not a someone that can help it can be a something.

A suggestion in the Pragmatic Programmer book is to use Rubber Duck debugging in situations like this. This idea comes from the story of a developer who would carry a Rubber Duck around. When that developer got stuck they would sit and describe, line by line, the code to the duck. Often the act of describing it would allow that developer to discover the issue and solve it. This can often be the best way to solve an issue whether using a rubber duck or not. Talk someone else through the issue. I am not insulting my wife when I say that I have described problems to her in detail. She has no (or little) idea about what I am saying. It is the act of describing the issue that lets your brain offload, focus and process.

Next time you are stumped I suggest you try either method.

If you would like to discuss this topic further then please message me via twitter or email.