Questioning the Question

One of my favorite articles about working in a highly technical field is Paul Krugman's How I Work, which he wrote while working as a professor at MIT.

A decent chunk of the article is technically connected to his economics work, but his "Rules for Research" are generally applicable to any kind of technical work that smells researchy.

  1. Listen to the Gentiles
  2. Question the question
  3. Dare to be silly
  4. Simplify, simplify

I can't do any better at summarizing the principles than just citing the exigesis of the principles in full, but there's one part of "Question the Question" that I just love:

In general, if people in a field have bogged down on questions that seem very hard, it is a good idea to ask whether they are really working on the right questions.

Often some other question is not only easier to answer but actually more interesting! (One drawback of this trick is that it often gets people angry. An academic who has spent years on a hard problem is rarely grateful when you suggest that his field can be revived by bypassing it).

If you're guessing that this is a veiled reference to TC39, it is, but perhaps not in the way you're expecting. TC39 is, in fact, great at questioning the question.

Since JavaScript started small (especially in its standard library) and has only added bog-standard features pretty recently, we're quite often adding a new feature with a long precedent.

I really appreciate the committee's willingness to take a fresh look at problems even when many other languages have very similar or identical solutions. Quite often, all of the previous languages were just cargo culting from each other!