Nasty Little Problems

Paul Graham has posted another mildly provocative, yet mildly predictable, essay. This one is titled "Great Hackers". I want to contrast two of the points he makes in this essay. Point the first:

It's hard to predict which problems hackers will like, because some become interesting only when the people working on them discover a new kind of solution... When Google was founded, the conventional wisdom among the so-called portals was that search was boring and unimportant. But the guys at Google didn't think search was boring, and that's why they do it so well.

Point the second:

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.

I'm somewhat surprised at the lack of self-awareness evident in this juxtaposition. First he says that you never know what's going to be interesting, because great hackers can find interesting things in unexpected places. Second he points out an area that he thinks is always uninteresting. Well gee, it seems to me that he's just put up a big ole' sign pointing at an area that needs some serious hacker attention. Someone smart just needs to think about how to make those "nasty little problems" less nasty!

In fact, those "nasty little problems" are pretty much exactly what I have found interesting over the years. For example, writing GUIs can be tedious, so I started thinking about using dataflow to make it more elegant. Similarly, designing custom data structures for highly scalable software can be nit picky and unrewarding, so I started thinking about automatic programming. And I personally find debugging to be spectacularly frustrating, so at one point I started thinking about value tracing debuggers.

This also helps explain why I love my current job (QA lead). I'm charged with making sure that the product we're building is useful, usable, and robust. This means I get to spend time thinking about verification techniques like model checking. I also get to advocate for new features that I think are important in order to make the product more useful. And I am obligated to develop a broad understanding of what problems our customers are actually trying to solve. All of these things are challenging (which makes it interesting) and important (which also makes it interesting). Plus I get to learn management skills (which makes it interesting yet again, but in a different way).