Over the past few months, I've been using David Allen's Getting Things Done; in the process, I've started reading various sites that have to do with the "GTD" system and "lifehacks" in general. While catching up on LifeHack after a vacation, I stumbled on an article titled Organized People are Lazy!.

The Author of that article poses a few questions he asks himself when trying to be more efficient ("good lazy"). Since Laziness is one of the Three Noble Virtues, I immediately thought of how those questions might be answered for working with Perl. While I provide my answers below, I'm interested in what my fellow Monks have to say on the matter as well.

Question 1: How can I do this faster?

Focus on reusability. Even when you think you won't use your one-liner or snippet again, save a copy. Need to perform the same few steps over and over? Don't retype, don't cut-n-paste, factor out into a sub or a module.

Reduce debugging time. Using methodologies that keep bug counts low (like Test-Driven Development) let you get to release faster. Debugging without tests in place takes a lot longer (on average) than maintaining the test suite; you'll do less debugging, and what you have to do will go faster. Follow a "zero defects" approach (fix your open bugs before adding new features) -- fixing bugs in fresh code is a lot faster than fixing them in code you're no longer familiar with.

Question 2: How can I not do this at all?

Leverage existing work. Check CPAN first; chances are, a good chunk of your problem has already been well-solved. Use that work instead of rolling your own. Don't re-invent the wheel!

Redefine problems. Is there a way to think about your goals such that you can avoid work entirely? Are you optimizing prematurely? Do you really need all the features you're planning for this release?

Question 3: How will I remember this later?

Document and test! Use POD to document interfaces and user experience, use inline comments to document implementation decisions (even if you think they're easy to remember). Maintain a complete test suite (the laziest way to do that is to use Test-Driven Development); sometimes the best documentation is the tests themselves.

Question 4: How can I use my time better?

Get your priorities straight. Check CPAN for existing solutions; if none have all the features you need, pick one (or more) and add your features rather than starting from scratch. Avoid premature optimization: get a program that works correctly before you worry about how fast it is. Make sure you really need to save that 300ms of execution time before you spend hours optimizing. (In other words, make sure your optimization gains are worth the effort.)

<radiant.matrix>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Replies are listed 'Best First'.
Re: How to be lazier
by xdg (Monsignor) on Feb 28, 2007 at 21:44 UTC
    Question 1: How can I do this faster?

    This is the impatience virtue.

    Also, you mention premature optimization, CPAN and Test Driven Development each twice in separate places. Maybe this post needs to be refactored? I'm not sure it's lazy enough. ;-)

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      Hey, they're not my questions. ;-)

      Refactoring might be interesting -- how would you do it? (Laziness tip #5: delegate! ;-D)

      <radiant.matrix>
      Ramblings and references
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet