3 ms·

>A plumber, sure. What about the guys who design your water heater? Should they just google the thermodynamics as they go as well? Honestly, regularly referrin

>A plumber, sure. What about the guys who design your water heater? Should they just google the thermodynamics as they go as well? Honestly, regularly referring to the reference material as you need it rather than trying to remember or derive every single pressure equation off the top of your head sounds like a good idea when designing a potentially explosive boiler.

phn 11y ago
I agree, I'm simply arguing the fundamentals must be somewhat present in your head in order for your research to be productive. Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics? It's easy to dismiss an example case as solving a maze, because that's been done to infinity. But real-world problems are rarely so cleanly defined.
- Sir_Substance 11y ago
  >Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics? In general, these things are well implemented in either the base language or a library, and thus both easily searchable and well covered in practical examples. It's unusual for 9-to-5 non-R&D developers to be solving a problem which hasn't been solved before at the algorithm level, the job usually revolves around connecting pre-made components together and specializing them. As such, you really only need a loose knowledge of the fact that things like binary trees exist. Being able to hand-write one isn't useful and may be a liability depending on the temperament of the developer. Your hand-rolled implementation is unlikely to perform better by any metric than the pre-made one, and it'll probably be less platform independent and more buggy simply because it's newer and looked at by fewer people. In 95% of all software development today, rolling your own version of any off-the-shelf algorithm is a mugs game and actively bad practice because it places the foundations for technical debt. You really don't want to be hiring people who roll their own just because they can. Now, if you're going to be working in the R&D or experimental areas of software development, kind of where the Oculus driver crew are at the moment (as an example), then sure, you definitely need to know the inner details of these things. The problem is that we're interviewing everyone as if they're going to be writing high-performance drivers, when most of them are never going to work at that level and wouldn't want to.

phn 11y ago

I agree, I'm simply arguing the fundamentals must be somewhat present in your head in order for your research to be productive. Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics? It's easy to dismiss an example case as solving a maze, because that's been done to infinity. But real-world problems are rarely so cleanly defined.

Sir_Substance 11y ago
>Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics? In general, these things are well implemented in either the base language or a library, and thus both easily searchable and well covered in practical examples. It's unusual for 9-to-5 non-R&D developers to be solving a problem which hasn't been solved before at the algorithm level, the job usually revolves around connecting pre-made components together and specializing them. As such, you really only need a loose knowledge of the fact that things like binary trees exist. Being able to hand-write one isn't useful and may be a liability depending on the temperament of the developer. Your hand-rolled implementation is unlikely to perform better by any metric than the pre-made one, and it'll probably be less platform independent and more buggy simply because it's newer and looked at by fewer people. In 95% of all software development today, rolling your own version of any off-the-shelf algorithm is a mugs game and actively bad practice because it places the foundations for technical debt. You really don't want to be hiring people who roll their own just because they can. Now, if you're going to be working in the R&D or experimental areas of software development, kind of where the Oculus driver crew are at the moment (as an example), then sure, you definitely need to know the inner details of these things. The problem is that we're interviewing everyone as if they're going to be writing high-performance drivers, when most of them are never going to work at that level and wouldn't want to.