The Forgetting of Research Papers

By on

John Langford recently blogged about researchers preference to cite recent research. He calls this tendency "the forgetting" of prior work. John suggests a number of reasons recent work may be remembered (including "Dead men don't reject your papers for not citing them").

John also points out the obvious: forgetting is a bad thing. It may lead people to overestimate the value of a paper, and it reduces the efficiency of contribution. He wonders whether our line of research may be able to help: "Wouldn’t it be great if all the content at a conference was organized in a wikipedia-like easy-for-outsiders-to-understand style?"

Programmers Don’t Like to Code?

By on

Jonathan 'Wolf' Rentzsch has an interesting blog on the theme that [[Programmers Don't LIke to Code |]].  His argument is that programmers like to solve problems, not to develop code to solve those problems.  He gives a number of great arguments: programmers choose tools that make it easier to get their jobs done (languages and libraries that require *less* code), and that programmers find it frustrating when they are building something and they have to build lots of piddly stuff that doesn't really advance their cause directly.  He misses another strong argument, which is how frustrated programmers get when they can't get their tools to do what they're supposed to do — further support for his second argument, which is that when programmers do rework, they are doing it in support of their understanding, not because they just like to build.

 I think, however, that he's deeply wrong about the motivation for many programmers.  Many of us do just like to build.  It is true that if we are building something we'd prefer to use a tool that makes that building elegant.  In this way we're like furniture builders who are happy to use a mechanical planing device to smooth the wood, rather than doing so with stone implements.  However, we don't enjoy working on problems that are trivial for us to build, or that require boring or ugly creations, even if the problem is important to someone.  If the right way to solve a business problem is with an Excel macro, I'll whip up the macro, joylessly.  If the right way to solve a business problem is with an OCaml program, or a Python program, or even a Java program, and if the tool is a good fit for the job, I'll approach it with pleasure.  The difference is that the programmer wants to be an artisan, not merely a nail pounder.  As Knuth said some years ago, programming can be an art, and, for me, it is most pleasant when it is an art.