> The whole “just read the code carefully and you’ll find bugs” thing works fine on a 500-line rope implementation. Try that on a million-line distributed system with 15 years of history and a dozen half-baked abstractions layered on top of each other. You won’t build a neat mental model, you’ll get lost in indirection.
Yes, yes, why bother reading your code at all? After all, eventually 15 years will pass whether you do anything or not!
I think if you read it while it's 500 lines, you'll see a way to make it 400. Maybe 100 lines. Maybe shorter. As this happens you get more and more confident that these 50 lines are in fact correct, and they do everything that 500 lines you started with do, and you'll stop touching it.
Then, you've got only 1,5m lines of code after 15 years, and it's all code that works: that you don't have to touch. Isn't that great?
Comparing that to the 15m lines of code that doesn't work, that nobody read, just helps make the case for reading.
> What actually prevents bugs at scale is boring stuff: type systems, invariant checks, automated property testing, and code reviews that focus on contracts instead of line-by-line navel gazing.
Nonsense. The most widely-deployed software with the lowest bug-count is written in C. Type systems could not have done anything to improve that.
> sure, but treating it as some kind of superpower is survivorship bias
That's the kind of bias we want: Programs that run for 15 years without changing are the ones we think are probably correct. Programs that run for 15 years with lots of people trying to poke at them are ones we can have even more confidence in.
Yes, yes, why bother reading your code at all? After all, eventually 15 years will pass whether you do anything or not!
I think if you read it while it's 500 lines, you'll see a way to make it 400. Maybe 100 lines. Maybe shorter. As this happens you get more and more confident that these 50 lines are in fact correct, and they do everything that 500 lines you started with do, and you'll stop touching it.
Then, you've got only 1,5m lines of code after 15 years, and it's all code that works: that you don't have to touch. Isn't that great?
Comparing that to the 15m lines of code that doesn't work, that nobody read, just helps make the case for reading.
> What actually prevents bugs at scale is boring stuff: type systems, invariant checks, automated property testing, and code reviews that focus on contracts instead of line-by-line navel gazing.
Nonsense. The most widely-deployed software with the lowest bug-count is written in C. Type systems could not have done anything to improve that.
> sure, but treating it as some kind of superpower is survivorship bias
That's the kind of bias we want: Programs that run for 15 years without changing are the ones we think are probably correct. Programs that run for 15 years with lots of people trying to poke at them are ones we can have even more confidence in.