The Virtues of Laziness
Saturday, May 24th, 2008(NB: I originally posted this under the pen name of “Lee Morgan” in 2005).
A long time ago, long before I went to college, I worked as a dishwasher.
I must admit, for me, it was a dark time.
After several months of pearl diving, the sous chef, a great fellow named Bryan, offered me a position as a prep cook. “Dan,” he said, “I think that you’d make a great prep cook. You’re lazy.”
I was really hurt by his comment. I always worked hard and fast! How could he say something like that!?
He saw that I’d taken the bait. “Dan, what I mean is, you don’t have any tolerance for doing unnecessary work. You’re efficient. That’s what we need in prep cooks, because they have to do a lot of work in an eight hour shift. If you don’t learn how to save time, you won’t be done with your work when it’s time to go home.”
So they made me a prep cook. And I got buried. There really was a lot of work to do. And after about a month, Bryan started teaching me all of his tricks. After about four months, another prep cook told me that he’d been told in his review “you don’t have to be as good as Dan. Being *half* as good as Dan would be a good move for you.”
I didn’t know what to say. Bryan had been right. I work hard, and I despise inefficiency. And ultimately, it paid off for for me.
And the lessons that I learned slicing cases of produce and making ten gallon batches of soup and salad dressing paid off nicely when I finished college and moved into the software industry.
I fervently believe that it is completely worth everyone’s while to spend a lot of time getting your build environment set up and automated. When you are prototyping a new product, particularly a distributed one, building and deploying your product can take anywhere from several minutes to half an hour or more. Taking the time to automate your build can save you a huge amount of time and effort further down the line, particularly when you are troubleshooting and making frequent changes to your build.
When you are debugging code a long build and deployment process with lots of manual steps can derail your train of thought and cause you to make mistakes, forget what you were trying to do, or miss details you meant to watch out for when you finally got an opportunity to run your code.
This has been most apparent in servlet and midlet development, but it is also a huge factor in cluster and grid applications, particularly MIMD applications, where different nodes may be running different applications.
Arrgh. I have more to say about this, but it’s getting late. Time to sign off for now.


