Take some job you do a lot and write down the steps. Number them, 1, 2, 3 etc. Then step back and look at the list and think. The same way you might think about an interesting crossword puzzle, or a bridge game. A SimCity. Your goal is to eliminate steps.

I find that if there's an underlying simplicity to the problem, if it's possible to simplify, you'll figure it out.

Now, of course sometimes to simplify you have to cut off options. Another way of thinking about this is you're paving a cowpath. Look to see what people do the most, where the path is most worn, where the tracks are deepest -- where the taverns and hotels went up. These are the places where it pays to smooth things out.

A great example of this was Think C in the early days of the Mac. Think C had a shorter learning curve than a powerful command-line tool with a shell language. That was the downside. On the upside -- you could start having fun sooner. And the downside wasn't all that bad, because patterns had emerged, they were basically codifying and supporting processes Mac programmers were already using.

I think we're in the process of creating the cowpaths now, in the emerging environment of static apps and server-side JavaScript. It's an interesting time to think about it, because development models are simplifying on their own, and with a little willfulness we could get there faster.

Here's an A vs B to consider. I have a Node app to deploy. You could create an EC2 instance, or you could run on Heroku or Nodejitsu. In one case you get the full flexibility of a virtual PC. All the options. But it's still interesting to be able to drop a JS file in a folder, type a few commands at the shell, and have it run in its own process on a machine you don't have to even think about.

Ultimately, I'd like to be able to deploy by choosing the Save command from a File menu in my editor. That would be the easiest. A 1-step deploy.

Everywhere I go on the web I'm seeing an ad for Google Cloud Platform.

I actually have clicked on the link a few times. (Might be the first time I've ever clicked on an ad link.)

Their algorithms have correctly inferred that I'm actively making decisions in this area now. And those decisions will influence my spending for (knock wood) many months or years into the future. They may even influence the purchasing decisions of other server users. In other words, it's a good time for them to be flooding me with their Good News.

My longtime friend Doc Searls has a vision for commerce on the Internet that's very much two-way. If you recall, Doc is the guy who famously coined the term "Markets are Conversations." Here's what Doc means, in the context of Google's Cloud Platform and me.

Dear Google -- I find the idea of your Cloud Platform very appealing. But I can't use it, because I'm doing all my server-side development in Node.js at this time, and it's missing from what you offer in Cloud Platform.

This omission seems interesting, because it's Google's JavaScript technology that makes Node.js possible! Maybe you have a different vision for how JS code should run in the cloud? Or perhaps you don't feel that JS makes sense in a server environment? Or perhaps you think JS is an egregious hack, and you want to, for strategic reasons, to push the other runtimes? If any of that is true, I would like to urge you not to give into that kind of thinking! The market has spoken, there's a lot of development energy going into Node. You could even say it's the consensus platform for server development going forward.

Short version: If you supported Node.js, I would probably be a customer.

That's me, the market, responding to the persistent offer that Google keeps making. They could save their money on the ads aimed at me, I'm already sold on the idea. However, until they support Node, I can't be a customer.

Sincerely,

The other side of the market

Update: People tell me that Google's Compute Engine has Node.js. A quick search didn't uncover any docs explaining how it works.