Giving Up

lifehacking

Thu Oct 30 12:16:00 -0700 2008

Give up early, give up often. That’s one of the secrets to being an effective hacker, an effective entrepreneur, or an effective anything.

High-level languages make it quick to bang out early implementations of new ideas. UI designs that are going to be good will show promise in early drafts. Business initiatives which are likely to be valuable in the long run usually produce results right away.

The trick is to put a time constraint on whatever you’re doing. A few hours or a day to code a new feature. A day to make a first-draft mockup. A week to measure the impact of a new marketing angle. If something takes longer than the alloted time, then there are probably one of two possibilities:

  1. You bit off too big a chunk at once. Separate out some concerns. Pick a smaller bite and go to work on that.
  2. The approach you're using sucks. Stop trying to push that boulder up the hill, Sisyphus, and stop and think for a minute. There's probably a better way.

If it’s #2, this is where I wholeheartedly recommend giving up. Consider your work so far to be “research.” Write up a paragraph or two summarizing how you tried to solve the problem and why it didn’t work. Put this into the ticket or an email or your personal notes, so that it’s preserved for posterity. Then forget about it and move on to something else.

“What?! No! We need that (feature|design|initiative)!” cries the (client|manager|partner). But it’s much better to give up cleanly, than drag it out through a long painful death.

Here’s the thing: giving up is not a permanent state. Now you’ve got the problem floating around in your subconscious, unresolved. As you browse your news feeds, talk to colleagues, and work on other problems, a tiny bit of your brain will be on the lookout for another approach. For me, it comes most often when reading a blog entry about someone solving a related problem. They point out some library, or some technique, or some pattern that tickles that little bit of my subconscious that is still chewing on the problem. Enlightenment floods me and I reopen the task, diving in and solving it in a matter of minutes.

Speaking of programming specifically, learning a new language can be very helpful this way. Programming languages come with their own culture full of patterns, techniques, and styles. Some technique, common in the new language I’m learning but not common in my old standby, will jigger some neurons in my brain and out will pop a new approach for solving the problem in the old language. (Yet another reason why it’s important for hackers to constantly be learning new technologies. “When all you have is a hammer…”)

Is this just another spin on the agile methodology of small iterations, which I've been harping on for, like, ever? Yes.