The scenario: A simple prototype in JavaScript, so I could test play an MVP of my new game.

The problem: Why is this d_mn thing taking so long?

 

Ever since I started working on my own, I’ve spend far more time figuring out how to motivate myself. Because I’m working in a startup, I make sure to do just the minimum amount of work to make a viable product, so that I can save time and work on other things.

And yet, I find myself staring into space, going on Google Reader, Hacker News, playing games, or anything I can find aside from work.

As I’m talking with a friend online, we make some observations:

• While the eventual result is interesting, the work I’m doing is boring.
• The reason I’m bored is because the work is easy.
• Therefore, if I want to be more productive, I need to make my work harder.

I throw out the disorderly, simple, get it done code that everyone says you should write for a prototype. I make things organized. I put all my variables into neat, sensible structures that follow design principles. I use a regular expression to replace 6 lines that I could’ve done by hand in five minutes.

All of a sudden, I’m getting work done again.

What gives?

–

I’ve talked with scores of startups over the years, and they consistently err on the side of overbuilding rather than underbuilding. Fancy prototypes take months to code, months that are wasted if your idea of a customer is the two people you told at the startup meetup you went to last week that said it looked kind of cool; people create entire frameworks to build sites that could be done in the time it takes to write a shell script (that installs WordPress).

Thus, the rule to build fast and build cheap was born.

Am I some kind of unlikely exception? Perhaps. But after giving it more thought, I realized that the need to make some things hard is not surprising, and not unique.

–

Are you working at a startup?

Why?

The pay is (sometimes) lower and the responsibilities are (often) greater. Most of the programmers I know working on their own projects are exceptionally good at programming. The hackers aren’t hanging out at the back of the bell curve. They can pass FizzBuzz, they know it, and that’s exactly why they’re finding a place where they live or die by their skills.

So it’s not entirely surprising that, if you pick people who are fairly competent at coding, so competent that they want to go to a place where they may be solely responsible for the technical success of the product they build, that they might just prefer not to always have simple, somnambulist-friendly code assignments.

Now, as with any essay that argues a point, you can poke holes in this thesis. Perhaps, you might say, the original rule isn’t against giving yourself a technical challenge from time to time, but rather as a safety railing to stop the people who want to make Pandora Craigslist Farmville with an extra layer on top so you can tag your singing cows with pictures from your last missed connection. And that’s a fair point.

What we do thrives on exceptions. I wouldn’t be able to think of a good example, but by chance, I read of one in the NYT yesterday:

When asked what market research went into the iPad, Mr. Jobs replied: “None. It’s not the consumers’ job to know what they want.”

Do what works.