3 ms·

https://neverworkintheory.org/ https://neverworkintheory.org/ is the web site associated with this (from the 1st reference in the paper)

by sfink 3y ago

dj_mc_merlin 3y ago
These are pretty interesting talks but they very much feel like just random talks from any conference? Interesting but I have no way to apply them if I wasn't writing a tool for developers. edit: On another level I am put off by their tendency to describe things such as "teaching undergraduates" or "debugging problems" as algorithms. I understand that you can't really analyze unclear, hazy things without putting them down in clear terms, but something in me doesn't really accept that you _can_ do this without losing so much detail and information as to make your conclusion useless. They do point out that SWE often think of studies this way: > Most software developers in industry have never heard of any findings more recent than The Mythical Man-Month: Essays on Software Engineering (which few of them ever actually read) and routinely dismiss studies as “not statistically significant,” even when those studies are carefully done and directly relevant to their work.
- cratermoon 3y ago
  Ah yes, the front page featuring the recorded talks kind of hides the real substance. Here's the full collection of papers, by category https://neverworkintheory.org/category/ https://neverworkintheory.org/category/
sethammons 3y ago
Awesome, thanks. I jumped into the first one that grabbed my attention: CDD - cognitive driven development (link below, 15min video). I love the premise but find the recommended results silly. TL;DW: cognitive research shows humans have working memory limited to 7 +/- 2 things. This means that classes should be limited in what they do. So far, I agree. And I think this can be extended, in practice. However, they back up this idea with a single case study and use a decorator to help count complexity to keep the classes small and state that methods not extending beyond 24 lines of code are ways to do this. This will just lead to cargo culture like "don't comment code." The decorator is not needed because code should (authoring or in review) be obvious if handling more than 5 to 9 things. The number of lines might be correlated to the number of things a function does, but that doesn't mean cognitive overhead. Like, a 100 line function that maps state abbreviations to state names is fine. Based on the presented data and mental performative drop off, it is not 7 +/- 2, it is really five + 0 to 2. I hereby dub this the Rule of Five. A practical example better than what they present in the talk: early returns. Every nested block adds to cognitive load, early returns allow you to discard that load as you continue reading through the function. The cyclomatic complexity reaching over 5 levels means many people will start to fail to keep all the blocks in working human memory. Therefore, early returns are a good implementation of Cognitive Driven Development. The case study they used seems meh. With a couple decades of experience with high growth start ups becoming "real" companies, I just don't buy their results on decorators and function line length. But they are on to something with limiting code to keep minimal cognitive overload down. https://m.youtube.com/watch?v=g_ht_LDm5Hw&feature=youtu.be https://m.youtube.com/watch?v=g_ht_LDm5Hw&feature=youtu.be
- munchler 3y ago
  Early returns provide a breeding ground for subtle bugs. I wonder if the research considered that aspect as well.
  - n0n0n4t0r 3y ago
    Not forcibly if you keep every function short: then their structure is simple and less hazardous to read without error
  - taneq 3y ago
    I’ve heard this before, and I can see how some cases (returning from random points in deeply nested loops or something) could cause issues, but in my experience early returns at the start of a function for error handling make things far simpler and more explicit compared with other options.
- n0n0n4t0r 3y ago
  And it seems a little wrong as developers gain the ability to use the way more capable spatial memory with time (the same as for memory palaces). So yeah, in practice, I agree to keep classes small, but not for the short term memory problem.
  - sethammons 3y ago
    Good point: as you become an expert in the given system, you can encapsulate or abstract away multiple things into one. A silly example: when you are learning to dress yourself as a kid, zippers are hard, shoe laces are hard, putting left shoe on left food often gets mixed up. All these little details. When you are older, these details take no mental capacity and you can "get dressed" as a single concept.
  - kayodelycaon 3y ago
    It really bugs me when it is blindingly obvious a professor doesn’t actually know how cognition works. The actual study of human performance is outside their field, therefore untested or flawed assumptions form the basis of their research.

https://neverworkintheory.org/ https://neverworkintheory.org/ is the web site associated with this (from the 1st reference in the paper)

by sfink 3y ago

https://neverworkintheory.org/ https://neverworkintheory.org/ is the web site associated with this (from the 1st reference in the paper)

dj_mc_merlin 3y ago

These are pretty interesting talks but they very much feel like just random talks from any conference? Interesting but I have no way to apply them if I wasn't writing a tool for developers. edit: On another level I am put off by their tendency to describe things such as "teaching undergraduates" or "debugging problems" as algorithms. I understand that you can't really analyze unclear, hazy things without putting them down in clear terms, but something in me doesn't really accept that you _can_ do this without losing so much detail and information as to make your conclusion useless. They do point out that SWE often think of studies this way: > Most software developers in industry have never heard of any findings more recent than The Mythical Man-Month: Essays on Software Engineering (which few of them ever actually read) and routinely dismiss studies as “not statistically significant,” even when those studies are carefully done and directly relevant to their work.

cratermoon 3y ago
Ah yes, the front page featuring the recorded talks kind of hides the real substance. Here's the full collection of papers, by category https://neverworkintheory.org/category/ https://neverworkintheory.org/category/

sethammons 3y ago

Awesome, thanks. I jumped into the first one that grabbed my attention: CDD - cognitive driven development (link below, 15min video). I love the premise but find the recommended results silly. TL;DW: cognitive research shows humans have working memory limited to 7 +/- 2 things. This means that classes should be limited in what they do. So far, I agree. And I think this can be extended, in practice. However, they back up this idea with a single case study and use a decorator to help count complexity to keep the classes small and state that methods not extending beyond 24 lines of code are ways to do this. This will just lead to cargo culture like "don't comment code." The decorator is not needed because code should (authoring or in review) be obvious if handling more than 5 to 9 things. The number of lines might be correlated to the number of things a function does, but that doesn't mean cognitive overhead. Like, a 100 line function that maps state abbreviations to state names is fine. Based on the presented data and mental performative drop off, it is not 7 +/- 2, it is really five + 0 to 2. I hereby dub this the Rule of Five. A practical example better than what they present in the talk: early returns. Every nested block adds to cognitive load, early returns allow you to discard that load as you continue reading through the function. The cyclomatic complexity reaching over 5 levels means many people will start to fail to keep all the blocks in working human memory. Therefore, early returns are a good implementation of Cognitive Driven Development. The case study they used seems meh. With a couple decades of experience with high growth start ups becoming "real" companies, I just don't buy their results on decorators and function line length. But they are on to something with limiting code to keep minimal cognitive overload down. https://m.youtube.com/watch?v=g_ht_LDm5Hw&feature=youtu.be https://m.youtube.com/watch?v=g_ht_LDm5Hw&feature=youtu.be

munchler 3y ago
Early returns provide a breeding ground for subtle bugs. I wonder if the research considered that aspect as well.
- n0n0n4t0r 3y ago
  Not forcibly if you keep every function short: then their structure is simple and less hazardous to read without error
- taneq 3y ago
  I’ve heard this before, and I can see how some cases (returning from random points in deeply nested loops or something) could cause issues, but in my experience early returns at the start of a function for error handling make things far simpler and more explicit compared with other options.
n0n0n4t0r 3y ago
And it seems a little wrong as developers gain the ability to use the way more capable spatial memory with time (the same as for memory palaces). So yeah, in practice, I agree to keep classes small, but not for the short term memory problem.
- sethammons 3y ago
  Good point: as you become an expert in the given system, you can encapsulate or abstract away multiple things into one. A silly example: when you are learning to dress yourself as a kid, zippers are hard, shoe laces are hard, putting left shoe on left food often gets mixed up. All these little details. When you are older, these details take no mental capacity and you can "get dressed" as a single concept.
- kayodelycaon 3y ago
  It really bugs me when it is blindingly obvious a professor doesn’t actually know how cognition works. The actual study of human performance is outside their field, therefore untested or flawed assumptions form the basis of their research.