Payback Time

One thing I think is super important is stopping work on the important projects I am doing, and especially any urgent tasks with which I am occupied, and focusing instead on items which have a less direct payback. Research which may not turn into anything useful. Ideas which do not have a clear return on investment. Prototyping programs or processes which may turn out to be a complete bust. Learning about topics which do not seem to have anything to do with testing.

Strikeouts (ideas which fail) tend to outnumber bunts (projects with small returns on investment or which take a long time to payoff), which tend to outnumber homeruns (changes which make orders of magnitude of difference). Which is not to say I fail a lot! Rather, I find lots of things which do not work or whose return is not worth the required investment. More importantly, I learn lots about lots. Exercising my brain in new and different ways does in fact have a direct impact on my important projects and urgent tasks.

Every great tester and great developer and great name-your-discipline I know has this same attitude. They read everything they can get their hands on about just about anything. They have multiple side projects going on. They know multiple (spoken and programming) languages. They wouldn't stop learning for any amount of money.

Some testers I meet do not see the value in this. They get their job done and do not try to do anything else. If you are one of these testers, I don't know how to convince you of the value. Rest assured that while you are getting your job done some of your coworkers are learning many things that don't work and finding a few things that do work and will shortly be leaving you in their dust.

Many other testers I meet see the value in taking this slack time but do not feel like they can. They look at the plethora of daily tasks that suck up their time - analyzing last night's automation runs, reporting status to their management, buddy testing their developer's builds, and on and on and on - and despair. "If I take even half an hour to do this learning stuff I won't get these five other things done! And I have to get them done!"

Really? Why do those five other things need to be done? Who are you doing them for? What information do they desire, or require? Why are those tasks are so important? Take time out to ask these questions and you may discover that some of those tasks do not really need to be done. You may find or know more efficient ways to do those tasks. Perhaps they would be more appropriately done by someone else.

You could simply stop doing some of those tasks and see what happens, who notices. I stop going to meetings when I stop seeing value from them. Rarely does anyone notice or care. I do not reply to emails to which I have nothing to add. I do not read emails which seem likely to have nothing to say.

Sometimes I miss something important. That's a definite risk. I usually find out some other way. That mitigates the risk. Overall I find the risk of missing something important and not finding out about it is more than made up for by the reward I receive from having more time to do what I think is important.

You can do the same. Once you identify a few tasks which you think are unnecessary, talk with your manager about them. Understand why (if) they view those tasks as important. Think of ways to mitigate any risks which might arise from you not doing the tasks. Boom! Free time!

Another way to find time to learn and research and investigate is to become more efficient at doing those activities which you really do need to do. Can you do something to reduce the time it takes to analyze test failures? Can you do something to increase the quality of the builds you receive from your developers? You have to spend time to make time, to paraphrase the old saying.

Another method is going stealth: learn and research and investigate and don't tell anybody about it. This is can be a risky maneuver. The consequences should you be found out can be dire. It's not for everybody. I am eminently comfortable doing this; some testers I know are not. Neither of us are better than the other. Know your comfort levels and think hard before you exceed them.

I do not want to be doing the same thing tomorrow as I am doing today. Taking me-time helps that happen. What about you?

Comments

• Anonymous
  February 14, 2007
  I'd have more time for learning if it wasn't for all these pesky blogs that I just have to read :) Now off I go away from here to read my new Ruby book Or should I try and find just one more bug...

• Anonymous
  February 14, 2007
  The comment has been removed