Dan Luu

Which brings us to the best advice in Simple Made Easy. The advice which always seems to be completely overlooked. OUR OUTPUT FRIGGIN MATTERS!

Programmers love to debate types, tests, build-tools, and semi-colons till the cows come home. We tell ourselves stories about how we're doing The Right Thing. But those stories rarely have basis in actual outcomes–in actual artifacts.

For example, the phrase "fully unit tested," is developer for, "good." But that statement by itself says absolutely nothing about outputs. It doesn't say what will be easy to change, how fast it runs, what failures it might encounter. It doesn't say whether it solves a problem!

The ones who suffer from our navel-gazing are the ones we are supposed to be helping: our users, our businesses, and our coworkers Very few programmers talk about this. And that, to me, is why Simple Made Easy was, and continues to be, important.

Aaaaand I realize now I owe @danluu an apology. I should not have said that he's unaware of the reality of modern programming. He just missed the point of the talk. That's all.

This is the thing about this talk (which I think is illustrated by the replies to @hillelogram 's original comment) -- the talk is so vague that you can interpret it in many different ways. I don't think your interpretation is wrong, but I don't think it's the only one.

Your interpretation explains the "guardrail programming" thing in a reasonable way, but literally every other time I've seen that section of the talk cited, it's cited to mean that types = bad since types = guardrails = crashing, which (IMO) is an absurd viewpoint.

You might say that all of these other people are misinterpreting the talk, but if that many people misinterpret the talk, I think that saying that they're misinterpreting the talk is blaming the user. This is the perspective I personally have when I write, YMMV on this.