5 ms·

it is not edgy whatsoever. it reflects the actual reality on the ground. nobody goes to school to learn how to use git or how to write unit tests. it's not som

it is not edgy whatsoever. it reflects the actual reality on the ground. nobody goes to school to learn how to use git or how to write unit tests. it's not something that needs to be actively "learned", you'll just absorb it eventually because you can't escape it. The more interesting and important things you will never "just absorb", you actually have to make a conscious effort to engage with them.

KevinMS 1y ago
I'm replying to statements like this > "testing" is not fundamental. and > there is no real skill to be learned there one of the biggest problems that has plagued software is failed projects. There have been a lot of them, and its probably costs hundreds of billions of dollars. I can guarantee not one of those projects failed because somebody had to take the time to look up the best data structure. But I'll bet a lot of them failed because they didn't follow smart testing practices and collapsed under their own weight of complexity, untestability and inflexibility.
- nice_byte 1y ago
  Citation needed. I've seen projects fail for a multitude of reasons, by far the most common are boring political ones, like the leadership not understanding what it is that they want to build. Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is. I assure you that if you have enough competence to actually go through with designing and building a thing, you certainly have more than enough competence to test it. It is not a fundamental discipline that needs to be studied, much less at the expense of fundamental knowledge. Edit: to reframe it a bit differently: you can always add more tests. you can't fix the problems you don't even know you have due to lack of thorough understanding of the problem domain.
  - KevinMS 1y ago
    > Citation needed. [7 Software Failures Due To Lack Of Testing That Rocked The World](https://www.appsierra.com/blog/software-failures-due-to-lack-of-testing https://www.appsierra.com/blog/software-failures-due-to-lack...) > Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is. Citation needed. > Edit: to reframe it a bit differently: you can always add more tests. you can't fix the problems you don't even know you have due to lack of thorough understanding of the problem domain. The problem domain is never the data structure or algorithm.
    - nice_byte 1y ago
      > [7 Software Failures Due To Lack Of Testing That Rocked The World](https://www.appsierra.com/blog/software-failures-due-to-lack https://www.appsierra.com/blog/software-failures-due-to-lack...) Do you really think you can prove your point by showing me some sloplist of mildly high profile bugs? All these systems had extensive test suites and yet these problems happened anyway. Bugs happen in extensively tested systems literally all the time, but by your own logic, any bug is "due to lack of testing". That's an unproductive line of reasoning because it is not possible or practical to test for every possible eventuality. This is why fields like formal verification exist. >> Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is. > Citation needed. ever tried to build a distributed cache?? > The problem domain is never the data structure or algorithm. The problem domain is literally always that. The way your data is organized and the way you work with it is directly affected by the exact problem you are solving.
      - KevinMS 1y ago
        > Do you really think you can prove your point by showing me some sloplist of mildly high profile bugs? Whatever I link to you are just going to say its AI, or inconclusive. There's a section on testing in the Mythical Man-month, but I can't link it here. But I don't see anything on getting the "fundamental theory" wrong. > All these systems had extensive test suites and yet these problems happened anyway. They were obviously missing some important tests. > ever tried to build a distributed cache?? Why would I if I could avoid it? And building that, rather than finding it somewhere looks like nudge towards a project failure. > The problem domain is literally always that. The way your data is organized and the way you work with it is directly affected by the exact problem you are solving. That's just basic programming in the type system of your chosen language, not "fundamental theory" as you call it.

KevinMS 1y ago

I'm replying to statements like this > "testing" is not fundamental. and > there is no real skill to be learned there one of the biggest problems that has plagued software is failed projects. There have been a lot of them, and its probably costs hundreds of billions of dollars. I can guarantee not one of those projects failed because somebody had to take the time to look up the best data structure. But I'll bet a lot of them failed because they didn't follow smart testing practices and collapsed under their own weight of complexity, untestability and inflexibility.

nice_byte 1y ago
Citation needed. I've seen projects fail for a multitude of reasons, by far the most common are boring political ones, like the leadership not understanding what it is that they want to build. Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is. I assure you that if you have enough competence to actually go through with designing and building a thing, you certainly have more than enough competence to test it. It is not a fundamental discipline that needs to be studied, much less at the expense of fundamental knowledge. Edit: to reframe it a bit differently: you can always add more tests. you can't fix the problems you don't even know you have due to lack of thorough understanding of the problem domain.
- KevinMS 1y ago
  > Citation needed. [7 Software Failures Due To Lack Of Testing That Rocked The World](https://www.appsierra.com/blog/software-failures-due-to-lack-of-testing https://www.appsierra.com/blog/software-failures-due-to-lack...) > Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is. Citation needed. > Edit: to reframe it a bit differently: you can always add more tests. you can't fix the problems you don't even know you have due to lack of thorough understanding of the problem domain. The problem domain is never the data structure or algorithm.
  - nice_byte 1y ago
    > [7 Software Failures Due To Lack Of Testing That Rocked The World](https://www.appsierra.com/blog/software-failures-due-to-lack https://www.appsierra.com/blog/software-failures-due-to-lack...) Do you really think you can prove your point by showing me some sloplist of mildly high profile bugs? All these systems had extensive test suites and yet these problems happened anyway. Bugs happen in extensively tested systems literally all the time, but by your own logic, any bug is "due to lack of testing". That's an unproductive line of reasoning because it is not possible or practical to test for every possible eventuality. This is why fields like formal verification exist. >> Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is. > Citation needed. ever tried to build a distributed cache?? > The problem domain is never the data structure or algorithm. The problem domain is literally always that. The way your data is organized and the way you work with it is directly affected by the exact problem you are solving.
    - KevinMS 1y ago
      > Do you really think you can prove your point by showing me some sloplist of mildly high profile bugs? Whatever I link to you are just going to say its AI, or inconclusive. There's a section on testing in the Mythical Man-month, but I can't link it here. But I don't see anything on getting the "fundamental theory" wrong. > All these systems had extensive test suites and yet these problems happened anyway. They were obviously missing some important tests. > ever tried to build a distributed cache?? Why would I if I could avoid it? And building that, rather than finding it somewhere looks like nudge towards a project failure. > The problem domain is literally always that. The way your data is organized and the way you work with it is directly affected by the exact problem you are solving. That's just basic programming in the type system of your chosen language, not "fundamental theory" as you call it.