Dan Luu

My feeling (just a feeling, I don't have evidence for this either way) is that pair programming works better for training than code reviews. I suspect actual training also works better, but since no one does that it's hard to compare.

I've worked at two companies that are probably P99+ in how much explicit training they offer, but they're not even in the same league as what you get if you walk down to your local go/chess/bridge club, let alone what you get if you're a serious amateur athlete or go player.

Given it is hard to measure costs and near impossible to quantify benefits, it would be nice if major tech companies were significantly different so we could at least compare macro outcomes. Instead there is surprising amounts of groupthink.

One thing I find funny about programming is the slow diffusion of practices. Fuzzing/randomized testing has been standard practice in hardware for my entire life and there are papers applying this to software that are decades old, I that doubt even 5% of devs use fuzzing today.

Could it be that ~95% of devs today are using memory-safe languages? I like fuzzing, but it takes some rearchitecture to set up for, and I don't know that I'd believe it's worth it for something like JS, Java, Rust, or even Golang.

I don't see why fuzzing or randomized testing should only be used for memory-unsafe languages? The vast majority of bugs I've found with these techniques aren't memory safety bugs.

If we're talking about bug rates like in the original tweet (well under 1 a year for the entire product), you're probably not going to get there just by using a safe mainstream language or using standard-for-software testing techniques.

You might argue that you don't need bug rates that low for most software (and I'd agree), but that company also moved faster than all but one big tech company team I've been on, so the testing overhead couldn't have been too high relative to normal big tech company overhead.