When to automatize?how looking to optimize your system will make you inefficient

[urlwolf]

If you are like me, you have many global shortcuts. All application are heavily customized, and you have a config file the length of your arm for your most used tools.

You spend ~1hr a day looking for the best tool to do the job. If it doesn't exist, you code one yourself.

This is all trying to optimize your time.

What I ask is… is it working?

Today a 'no frills' person showed me that she was willing to cut and paste something 73 times in excel (task that I would have automated!) and be done with the task faster than I could code an equivalent solution. Not to mention that I had to spend many hours to learn the language I was going to use for the task!

At the end of the day, trying to optimize everything in your computer, as much as we do, could be counterproductive in productivity terms.

I guess it also applies to the whole GTD view of the world. Learning the system costs you time, implementing costs you time, keeping the system updated costs you time… Not to mention the whole time wasted testing programs for the 'killer' application that will work for you best.

I had this idea when thinking about writing code vs. doing tasks by brute force (small tasks, of course). But it may apply more generally...

Your thoughts?

[mouser]

i have had your experience with your friend many times over.

some people i think can more rationally say "i can do this repetetive process for 2 hours and be done with it forever", while other of us "automaters" HATE repetetive work and would prefer 20 hours of learning to get that task done, as long as we can feel we've got some skills we can reuse in the future to do the task super efficiently, even if we know in our heart that we will never need to reuse that skill and it's just wasted brain space.

[nudone]

very true. i think we've discussed this before - or several of us held our hands up and admitted that we waste time trying to fix a problem that would have been quicker resolved to just get on with the task.

i think it might be useful to discuss these things during the GTD experiment as these sort of time wasting/saving acts are obviously a great source of procrastination, i.e. i won't finish that spreadsheet right now as i can write up a macro in less than 5 hours that will get the job done for me.

[Perry Mowbray]

I think what we need to do is to draw a line between work and recreation! And then distinguish between the tasks we have to do.

I have the same discussion with my wife, and thankfully she fully understands that I get great pleasure from working up an Access database or Spreadsheet solution that equally could have been done with a suspension file in the filing cabinet.

And thankfully I'm learning to distinguish between what would be more appropriately "knocked over in a booring way"!

But isn't that the question we have to answer at work, whether the planned response to the problem is the best use of resources?

[f0dder]

I'd rather spend 4 hours coding than 2 hours of repetitive work. If it's 20 vs. 2, I might consider doing the repetitive work... but might also still end up coding, because it's more fun and seems like less time. Also, if there's a remote chance I'll need to do something similar again, I'll of course code because I then have the experience the next time, perhaps meaning that I can do it in one hour instead of two...

[lanux128]

we're tinkerers at heart, we'd be happy to go thru the instruction manuals for any gadgets and hope that it comes with loads of option so that we can modify it to our liking. in our spare time, we'll be googling for utilities that we'd would eventually *need*, if not now..

that's why we find ourselves in forums like this.. anyway ending on a note of altruism, i think it's ok because what we find out will be useful to others.

[TucknDar]

guilty as charged. 'nuff said 

[brownstudy]

I'll write a Word macro or Macro Express macro if I find myself doing the same thing repeatedly, but I tend not to put all that machinery in motion for a one-off document.

Thomas Limoncelli in his book "Time Management for System Administrators" has a great breakdown of when to automate:

You should do manually simple things done once.
You should automate hard things done once or simple things done often.
You shuld buy or write software or outsource for hard things done often.

Other ideas from his book on this topic:

• Repeatability means I can do something consistently many times (like configuring new machiens with the same software).
• Automation can replace the need to memorize something complicated that is done rarely. (like command-line options)
• Scalability. The process can work as the network grows.
• Automation can replace error-prone procedures (again, like command-line options).

He has a whole chapter on "How to automate" in his book. Good stuff.

[app103]

hmmm...I don't think programmers are supposed to think like that...pasting something 75 times rather than coding a tool to do it this time...and every time...and for other people too.

If we all stopped coding the tools we want to use for the purpose of avoiding work, nothing would ever get done by anybody.

Necessity is the mother of invention...but laziness is its father.