Yesterday, I was holding my daughter's hand as we crossed a street. A car, presumably turning left, stopped to let us cross. After we reached the sidewalk, the car did a u-turn. Instead of a 90-degree left turn, it ended up making a 270-degree right turn.

This puzzled me. Why not just turn right to begin with? Perhaps his steering wheel was faulty, and it could only make left turns?

I thought of this as I read Charles Miller's review of Paul Graham's essay on great hackers. Miller hilariously sums up Graham's argument about brilliant programmers like this:

1. Hire great hackers.
2. …
3. Profit!

Although I wouldn't say I was great, I am a hacker. I know where Graham is coming from. And four or five years ago, I came from there, too. I would have agreed with everything Graham said, including maintaining a huge blind spot for point #2.

Since then, I've found, among other things, sabermetrics. And the most important thing I've learned from following this crowd is to look at what actually works, instead of what I wish works. I wish that stolen bases and bunts and hit-and-runs were a productive way to play baseball, because I think baseball is more fun that way. But it's not.

And I wish that just letting hackers go off and do their thing was the best way to build a software company, because that would be fun, too. But it's not.

I think Miller is right. There are more examples of where hiring great hackers doesn't work than where it does. Just look at any of the companies with superior software that got squashed by Microsoft or Oracle.

Here's how I would build a software company, if (when) I ever do so again:

1. Hire great hackers to build the architecture.
   You want an architecture that is flexible, and can quickly adapt to whatever changes come down the line. This is where great hackers come in handy. As Graham points out, great hackers "can load a large amount of context into their head, so that when they look at a line of code, they see not just that line but the whole program around it."
2. Fire the great hackers.
   Or perhaps gently push them elsewhere. Once the architecture is in place, there's nothing fun left for them to do. We're switching modes; if they think they own the software now, they'll just get in the way.
3. Build a direct line from your customers to engineering.
   Your customers needs and fears drive the product from now on. Marketing, sales, and support have the biggest say in what gets made and doesn't get made. They'll push you in God-knows-what direction, but as long as you have that flexible architecture, you can go there, without having to make 270-degree right turns.

Even if you've never imagined the need to make a right turn, great hackers won't let you build cars with steering wheels that are stuck turning left. But a great hacker would never build a poorly-structured SUV, either, no matter how much customers wanted it. Sometimes, customers don't want the most elegant product. Great hackers hate inelegance. But if you want to maximize profits, at some point, you'll probably need inelegance. The hackers will angrily protest your foolish ignorance (the way baseball aesthetes protest sabermetrics), so you'll have to let them go.