Here's an interesting perspective: Code Is Not Literature http://www.gigamonkeys.com/code-reading/
It addresses a puzzle:
> [So many programmers say], “People should read code” but few people seem to actually do it. I’d be surprised if I interviewed a novelist and asked them what the last novel they had read was, and they said, “Oh, I haven’t really read a novel since I was in grad school.” Writers actually read other writers but it doesn’t seem that programmers really do, even though we say we should.
@codesections i just woke up but for everything OP says is why literate programming is bad is alost why i say it's good, lol.
@codesections nvm i see now that they realize they were, mis-applying the notion.
(Since I started advocating for literate programmin, I've seen a lot of people argue that "code isn't a narrative," or whatever else, and to me those all seem to miss the point - literate programming isn't writing the code to be red, it's writing the /software/ to be read. The code is just the equivalent of charts and tables that demonstrate implementation.
@emsenn @codesections I find that literate programming is a wonderful way of actually accomplishing the task. It's sort of taking the rubber-ducky problem solving method and applying it to the act of building in the first place.
People put a lot of hate on LP because they hate writing documentation/comments. I think we should have this whole topic nipped in the bud (so-to-speak) in school when it's being taught.
@emsenn @codesections Well, rubber ducking, as explained to me, is when you come across a problem you can't figure out, you talk to an inanimate object about the problem until you've figured out how to resolve it.
@codesections I frequently read other people's code for work, but also for pleasure/learning. It's sort of a hobby of mine to seek out Helm charts / large bash scripts and dissect them. The awful/arcane/powerful things do with Bash leaves me with a weird mix of respect and nausea =D
@codesections If this part appeals to you: "One reasonable approach might be to show the real code and then to show a stripped down reimplementation of just the key bits, kind of like a biologist staining a specimen to make various features easier to discern.", then you might find _500 Lines or Less_ to be worth a look: http://aosabook.org/en/index.html
Also, the other books in the series are worthy as well.
Fosstodon is a Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.