3 ms·

What an amazing email from ESR. I feel like I've had the issue he describes happen to me in multiple facets of life, at different points. College? Check - The

What an amazing email from ESR. I feel like I've had the issue he describes happen to me in multiple facets of life, at different points. College? Check - There definitely was a point where I couldn't cruise and catch up by cramming. High school was a joke in comparison with some of the learning challenges I finally encountered. Task management? Hah! Todo lists are for old people. I cruised by on this one for a LONG time due to (at least my own perceived) pretty large short-medium term memory before personal life + work life (and moving up the chain) meant that there's no way I'd remember everything that needed tending to unless I adopted some sort of system. More guilty one? Tests. For better or for worse, I worked professionally in an environment where we a) had a compiler, b) had a QA group, and c) managed to put out a lot of working software without a test suite. It definitely made me finally give in to "code should have at least SOME test suite, if not a pretty comprehensive one" after much kicking and screaming. To this day, in my mind, I harbor feelings that it's possible to pump out largely working (i.e. with a defect rate not much worse off than any other project, because no software is without any) software incredibly faster and make the users/customers/people who wanted the thing built happy WITHOUT writing tests. That said, I also know it's completely irresponsible and not scalable to do so.

mbrock 11y ago
With tests, there's also the idea that writing them helps you write better code. That's something that doesn't happen automatically. If you approach tests as something you have to do because somebody told you to, and I think this is pretty common, then your tests are probably not going to be great, and it's not going to help your code... But if a team really takes to heart the whole principle of testing, and start to design things with testing in mind... then they start to ask questions up front like "how will we really know that this works?" and "how can we isolate this component so that we can test it independently?" and "how can we write fast tests for this?" and "can we make this into more of a pure, simple data structure?" and so on and so on. Especially this one: "How can we get the important business logic here to be a clear and distinct module with verifiable correctness?" And that's a cascade of wonderful benefits. Enforcing a culture of "you must write tests" might possibly help with QA, especially in the more obvious cases of algorithmic correctness, but the true benefits are so much deeper.

mbrock 11y ago

With tests, there's also the idea that writing them helps you write better code. That's something that doesn't happen automatically. If you approach tests as something you have to do because somebody told you to, and I think this is pretty common, then your tests are probably not going to be great, and it's not going to help your code... But if a team really takes to heart the whole principle of testing, and start to design things with testing in mind... then they start to ask questions up front like "how will we really know that this works?" and "how can we isolate this component so that we can test it independently?" and "how can we write fast tests for this?" and "can we make this into more of a pure, simple data structure?" and so on and so on. Especially this one: "How can we get the important business logic here to be a clear and distinct module with verifiable correctness?" And that's a cascade of wonderful benefits. Enforcing a culture of "you must write tests" might possibly help with QA, especially in the more obvious cases of algorithmic correctness, but the true benefits are so much deeper.