Plus and minus takes the prize
We learn some of the most important research there is – on the superiority of linear models to expert judgment. We also learn how to easily find 30 % more problems when reviewing someone's code.
I was not able to publish last week due to being hit by a nasty stomach bug. Well, that, plus a lot of other things going on in life – possibly more on that later!
New articles
Arithmetic Models: Better Than You Think
This is possibly one of the most important articles I've ever written. I've wanted to write it forever, and got the spark needed a little while ago. This is the article on Meehl and his disturbing little book that I reference all the time. (I didn't mean to write two LessWrong-inspired articles in short succession (the other being on intention-to-treat experiments), but it happens.)
The basic idea is that if you (a) find the right small set of variables, (b) gather some historic data to calibrate against, and (c) are able to perform addition and multiplication, then you can predict future outcomes at the level of – or better than – domain experts.
Oh, you thought that was the good news? The good news is that the right set of variables is often rather intuitive to even an intermediate domain practitioner.
No, scratch that. I mean, that's still true, but there's even better news. The best news is that step (b) is unnecessary. As long as we know in which direction the variables poke the outcome, we don't need to calibrate against historic data. Come on, just read the article already! It defies summarisation.
Full article (10–30 minute read): Arithmetic Models: Better Than You Think
Flashcard of the week
Greg Wilson has a recorded lecture from 2010 which – back then – was quite influential on my appreciation of using science to find things out, especially in the software world. That lecture ties very well into a book he edited, called Making Software: What Works and Why We Believe It. I read that book ages ago and remember very little of it. I want to re-read it while making flashcards, because it was a good book.
One of the things I've learned from it is about code review:
How many additional defects does one uncover when reviewing code in an IDE, with the ability to jump to definition, expand type signatures, etc?
I don't remember the details of how they figured this out, but the number on the back of the flashcard is
30 %
That's not nothing. Maybe it's not worth pulling every single code review request into the IDE, but some of the developers I've known that I respect most do that for almost everything – and no wonder!
Premium newsletter
I've started writing the next premium newsletter, which will contain a list of the 20 best technical books I've read in the past five years – as well as how one can possibly approach creating such a list without having to manually create a global book ranking, because that would suck. (Hint: we perform pairwise comparisons and compute a global ranking from that – this is more difficult than it sounds.)
The third premium newsletter went out this weekend. It had three links, two book recommendations (covering investing and polar expeditions), a link to a future article that's not yet published, and the ACX 2025 forecast rationales.
If any of this sounds interesting, you should upgrade to a premium subscription! If you upgrade now, you will pay only $2/month – as interest increases and I learn to hit my stride with publishing these, the price will be set higher for future subscribers. As always, you can cancel at any time.
To upgrade, click the subscription link at the top of this newsletter and fill in your email again.
Your opinions
I cannot improve without feedback. Reply to this email to share your thoughts on any of the topics above, or anything else!