YCombinator's RFS #5: An Accidental Case Study

Update: check out ddotdash.

I pricked my ears up at the latest Request For Startups from YCombinator. Last year I wrote the first 6,000 lines of my last startup on an eeePC 901, which is about half the size of a MacBook Air. It's cheap and solid-state so I treated it more like a largish book than a smallish computer. I toted it around to many more places, even parties. Losing that thread of worry about damage made it feel an extra half-kilo lighter. I sometimes wished it had a cell phone built in.

In the end the BabyBook was too cramped for long sessions. Both my code output and my hands suffered. The RFS's accompanying essay is correct that whatever platform hackers use to hack on eventually wins in the larger market. But it doesn't necessarily follow that because hackers have smartphones the next step is hacking directly on them. An equally plausible path is that our phones become portable homedirs that plug into any computer when we need to do real work.

Any human input surface smaller than a sheet of paper starts to bump against physical limitations that Moore's law can't fix. To do development on a mobile you have to be willing to give up both touch-typing and large screens. That's a big sacrifice, and it's hard to say what benefits I'd trade for them.

Any innovation that improves the speed of reading or writing code on a small device should also work on a large device, unless it takes advantage of features or use cases unique to the small one. Otherwise it's not a net advantage to mobile hacking. I giggle at the thought of using the accelerometer to indent, smacking my code into line. But the list of things an iPhone can do that a laptop can't is short while the inverse is very long.

Was the OQO early, or wrong?

Let's start fresh. Imagine you have a device the size of a thick passport or Moleskine. It is a phone plus a computer as powerful as a laptop from three years ago. You can hack on it directly in a pinch. It has enough storage for all of your working projects. You can plug it into any keyboard and screen (or computer) and start hacking.

You know what? That sounds pretty neat. And we'll probably get there soon. Perhaps someone will make a dongle that does this for iPhone or Android. Or it could be the accessory that saves the FreeRunner. But this is not very different from today, except for the reduced utility of your computer when you are not at a properly-equipped desk.

So let's go back to code input and output. We use keyboards because we have 100 years of experience with them as speed-of-thought input devices. We use ever-larger screens in order to view ever-larger amounts of code and data in one glance, partly because moving our eyes is faster than moving our hands. Random access matters a lot.

Multitouch gestures (pinch, zoom, scroll, etc) are interesting and so far underused. Using the "mouse" is less of a productivity hit on a phone because your fingers are already in position. Instead of representing code as long lists we spread out like so much wallpaper, maybe we can represent and navigate it like the directed multigraph it actually is. The Canon Cat and Archy might point the way here.

That leaves speed of input. Hinting and autocomplete might bring the mobile programmer back up to an acceptable wpm. Terser languages and WYSIWYG UI builders can help as well. But still I worry about fatigue. It's hard enough to work comfortably on the hardware we have. On the other hand, there's no reason we need to have a keyboard per se. Experienced telegraph operators could type up to 40 wpm with one finger using Morse code. Typing on virtual keyboards is slow because unlike keyboards or game controllers you have to carefully coordinate vision with motion. Instead, I wonder what one could do with two thumbs, an updated Morse, and a little practice.