Gay Dad Explosion

It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.

Of course some problems inherently have this character. And because of supply and demand, they pay especially well. So a company that found a way to get great hackers to work on tedious problems would be very successful. How would you do it?

One place this happens is in startups. At our startup we had Robert Morris working as a system administrator. That's like having the Rolling Stones play at a bar mitzvah. You can't hire that kind of talent. But people will do any amount of drudgery for companies of which they're the founders. [4]

Bigger companies solve the problem by partitioning the company. They get smart people to work for them by establishing a separate R&D department where employees don't have to work directly on customers' nasty little problems. [5] In this model, the research department functions like a mine. They produce new ideas; maybe the rest of the company will be able to use them.

You may not have to go to this extreme. Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications. This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department. The toolmakers would have users, but they'd only be the company's own developers. [6]

If Microsoft used this approach, their software wouldn't be so full of security holes, because the less smart people writing the actual applications wouldn't be doing low-level stuff like allocating memory. Instead of writing Word directly in C, they'd be plugging together big Lego blocks of Word-language. (Duplo, I believe, is the technical term.)

Working on nasty little problems makes you stupid.

No. It makes you thorough, attentive to details, prudent, careful, etc.

Also teaches you the economy of abstraction -- the delicate balance between tons of simple boilerplate and pounds of complicated boilerplate produced by the inner platform effect. That kind of thing actually happens everywhere, but "nice" problems allow the overly clever programmers to delude themselves about the usefulness of their abstractions, while the "little nasty problems" don't provide such convenience.

PG sucks as a programmer.

have one group that builds tools for writing software of that type, and another that uses these tools to write the applications.

Why, what an excellent idea! And when the unwashed application programmers complain to the master race about the fact that their fucking parentheses are full of abstract bullshite, intellectual masturbation and just push the complexity around instead of solving anything, they could be told to shut their plebeian faces!

I mean, you can't tell the clients that it's their problems that are wrong, not your solutions full of inner beauty and elegance! Even a lithp programmer could see that there's something a bit wrong with that.

But this arrangement is just perfect: on one hand, there's nothing wrong with telling your own application programmers that they "don't get it", especially if they were specifically hired to do the "not very clever" jobs. On the other hand, they can't even snap back with the "try to use it yourself then" retort, 'cause you've already established that using your master language/framework for anything other than fibs, facs and otherwise proofs of concept "makes good programmers stupid" and so should be avoided at all costs.

PG is a genius.