Tricks to avoid productivity "rabbit holes"

Question

I find that I often descend into what I call "rabbit holes" as I learn about a new technology/language/method/etc.

These are the moments where you feel that in order to understand a detail of what you are working on, you start investigating and investigating and you end up in a related, but detached space.

For instance, I'm learning Ruby (and Rails), and the more and more I discover, the more I feel I need a much better understanding of system administration, and so on and so on until I realize that I've found myself reading about Lisp...

or I begin working on old code. I take a look and I work at it and next thing I know, I'm refactoring and eventually rewriting code, when really I should just be completing the task.

Anybody else? Or just me?

How do you avoid these time sinks and rabbit holes? How do you pull yourself out of "refactor" mode?

Answer 1

Embrace the rabbit holes! It's a way of life.

Answer 2

Your last question is easy to answer: "How do you pull yourself out of "refactor" mode?"

Simply by remembering that everything has to be tested again after you refactored it. Ok, you get bonus-points if you refactor AND add tests that weren't there before. But mostly we refactor old code without any tests ... developer pride ;)

Answer 3

More often than not, I believe the correct answer is "you don't."

Programming is ultimately a thinking game. If your mind made the jump from Ruby to LISP, it's often worth following the path to its logical conclusion. I've found dusting off my LISP knowledge to be helpful in learning JavaScript.

Obviously, you need to get back to the question at hand eventually. But, many distractions are opportunities to think about the main problem in a different way. When you realize you've gotten off track, the first step is to try to remember how you got from A to B. If the path was a valid one, decide if it's still valid. As long as it is, consider following it through.

Being a good programmer is ultimately a holistic exercise.

Answer 4

I try to learn one new thing every day - well. When this is done, I try not to learn anything new, just do productive stuff. I do this every day. At the end of the year I've learned quit a lot. It also lets me balance out productivity demands vs learning. So mentally, I shut the rabbit hole out after being there once.

Answer 5

Short Answer

Use time-boxing and focus on a single next-action or goal.

Long Answer

List (you do keep a development log, right?) the next action or goal you are trying to accomplish, a rough estimate of how long you think it will take or how much time the effort is worth and then half of that becomes a 'box' or 'block' of time allocated to that task/goal. Start with half of the allotted time (set an alarm if you need to) and check your progress - are you still focused on the original goal/task? Are you about halfway through it? Do you need to reconsider what you're doing and how?

If everything is on track, continue with the other half of the time-box. Otherwise, rethink the task/goal/time/tactics.

It is really really easy to spend four hours on google reading about things that are really interesting but only peripherally related to the task at hand. Ditto for SO!

Answer 6

There are two quite different forms of learning you should be doing as a programmer. First, there's the learning you have to do to perform a particular task to do your job: then you should be strongly goal-based, and Steven Lowe's answer will serve you perfectly. Then there's 'down the rabbit hole' learning which is free-form, and you go wherever your interest leads you. Usually the former will be done on your employer's time, and the latter on your own time, but the two forms of study are strongly complementary to each other: one gives depth, the other breadth.

Thinking about which mode you're in will help you focus on what you want to achieve.