Thread from 2017: https://news.ycombinator.com/item?id=13855185
Not to start wars, but imperative code especially is a waste of time to read unless forced, as I need to understand your desired goal AND how you chose to get there. See for + if vs filter, for example. I would rather just read a function comment or class comment or some doc instead (assuming its up to date...)
I did not say code should not be read, just that it shouldn't be expected to be read. Make it clear before you ever get to the code what's going on
Sort of like the more generalized form of what BDD is supposed to allow non-developers to do, where there's no requirement that anyone be able to change the code quickly, just a requirement that they be able to easily audit and understand the code from the code itself.
People who need to get up to speed to become new maintainers for such codebases will sit down and grok the codebase, by poking it with tooling, exploring APIs, etc. until they get a sense of it—sort of like getting a sense of a city. But even they won't ever just sit down and read through the code, because they know it wasn't written for that.
It's a bit of a vicious cycle. The question is: which part of the cycle is easiest to break?
https://norvig.com/spell-correct.html is like poetry— or at least what I imagine poetry is like to people who like poetry.
Reading it changed the way I look at code, and inverted what I consider good code.
If it's not in a super high level language it probably won't be beautiful, at least not in the same way as Norvig's spelling corrector. For lower-level code, approaching it like a scientist, as OP suggests, may be right; I wouldn't give up on a reading group for sufficiently high-level code.
Which isn't poetry. Poetry is its own thing. We are not required to compare non-comparable things.