I have noticed a few articles recently on HN that talks about dropping tests because they are too slow or holding them back or just extra cognitive load.
This kinda beggars belief for me. I wonder who these people are - do they have the "battle scars" from working on complex or big systems? Are they reasonably junior or new to the profession with less than 10 years experience?
Next up? Fuck structural engineers, it's just going to slow us down building this bridge...
If you are doing something for fun, sure do whatever you want. I write zero tests for my own pet projects. But please in professional environments please don't ignore hard-won lessons in reliability and engineering-velocity because you don't want to have to do the extra work to update your tests. Your customers and colleagues (potentially years in the future) will thank you.
Tech is a relatively immature industry. And a lot of time and effort and money in it is devoted to non-critical products.
I'm not directing this at the OP, because they have actually thought about it even if I disagree with them, but there are a lot of people working in tech and in software who do not care about product quality at all. They're paid a lot of money and exclusively focus on shipping ASAP, quality be damned, so they keep their metrics looking good and the $$$ flowing. Add in the industries tendency for very short term tenure at jobs and you end up in a situation where people think what they're doing is "optimal" simply because it keeps them getting $$$ --- product quality is just secondary. Their "craftsmanship" is their job-hopping. (I don't have a problem with job-hopping if the products and code are still good --- they usually aren't.)
They usually don't need to care about a bridge lasting 6 decades, but then they're writing critical software for infrastructure or airplanes and, unfortunately, they can actively resist a lot of the hard learned lessons people had to make in those industries because they just want to move fast (and leave after ~2 years).
It's my failure as a writer, because this is not one of those articles.
OP is about how I thought I had the answers in the past but was wrong, and how I have new answers and am still wrong in ways I will find out about. So what beggars belief for me is anyone reading it and thinking I'm offering any sort of advice for others in all situations. What here gives you a sense it's at all related to professional environments? My first bullet was, "building for others is hard so don't even try." If you have ideas for what I can reword to make it even clearer, definitely let me know.
The one I saw some years ago with relatively new people was, they'll write tests while writing a piece of code, then once it's done and all the tests pass they'll think the tests are no longer necessary because the code is done. They didn't have the experience to see how long their code will exist, how it is extremely likely to get tweaked over the years, and how future developers won't have any of the context they had while writing it.
This kinda beggars belief for me. I wonder who these people are - do they have the "battle scars" from working on complex or big systems? Are they reasonably junior or new to the profession with less than 10 years experience?
Next up? Fuck structural engineers, it's just going to slow us down building this bridge...
If you are doing something for fun, sure do whatever you want. I write zero tests for my own pet projects. But please in professional environments please don't ignore hard-won lessons in reliability and engineering-velocity because you don't want to have to do the extra work to update your tests. Your customers and colleagues (potentially years in the future) will thank you.