21–30 of 38 posts
Earlier quoted context omitted.
I've heard that story. I've yet to see evidence it actually happened though. I don't the experiment with pass a modern ethics panel either.
parables that didn't happen can still be useful
There is this famous experiment with 9 monkeys in a room with a banana attached to the ceiling and a scale. First day, a monkey climbs the scale, gets the banana and is happy. Second day, they start spraying whomever gets on the scale. Monkeys hate this. They learn not to climb. Third day, they take a monkey out and replace with another. The new monkey sees a banana up there and tries climbing the scale. He literally…
I've heard that story. I've yet to see evidence it actually happened though. I don't the experiment with pass a modern ethics panel either.
I feel like a lot of documentation falls into this kind of style, where the motivation behind design is not communicated, just the design itself. Sometimes it's because the documentation writer doesn't want to leak internal details to the end user (closed source libraries are an especially bad source of this). Sometimes it's that the writer is too close to the project, and is struck by the curse of knowledge (can't p…
I always liked that mindset, and it helped teach me the important lesson that sometimes being the person who asks very basic questions because I don't understand things can make me valuable to the teams I work on. There are certainly times when the answer makes me go "oh, duh!", and I feel a little sheepish, but the feeling doesn't last very long, and no one has ever held it against me, whereas the times when it leads somewhere interesting and potentially to better documentation for people coming after me are far more frequent and memorable to everyone involved.
This isn't to say that the burden should fall on the ones who are reading the documentation rather than writing it, but to encourage people who are in the position of being frustrated and confused to take advantage of those moments, because they can make you very valuable to your team in addition to helping you learn. If you're on a team that operates in good faith, the burden for documenting things well can be shared, and in the long run it will matter less who's job it is to keep it updated and more about whether everyone is contributing however they can to maintain the quality (and if you're on a team that operates in bad faith, you have my permission to keep quiet and do whatever you can to get through that experience, not that you need it from me!)
This seems adjacent to Chesterton's Fence, though maybe not the canonical form of it. For anyone not familiar with the term, Chesterton's Fence is the idea that you should understand why a rule exists before trying to remove it or work around it: https://fs.blog/chestertons-fence/ Here the issue is not that the rule was removed, but that the code followed the wording while missing the reason the rule existed.
This seems adjacent to Chesterton's Fence, though maybe not the canonical form of it. For anyone not familiar with the term, Chesterton's Fence is the idea that you should understand why a rule exists before trying to remove it or work around it: https://fs.blog/chestertons-fence/ Here the issue is not that the rule was removed, but that the code followed the wording while missing the reason the rule existed.
Came here to say this. How can you write an entire article about Chesterton’s Fence without mentioning Chesterton’s Fence?!
1. I want to remove a rule
2. Understand why that rule is in place before proceeding
This article deals with the second part, but not the first. So it is only about about half of Chesterton's fence at best.
In these examples, a rule (avoid blocking calls) is in place to guide the programmer to a performant system. Programmers apparently thought that if they found a way to avoid directly blocking calls, but managed to indirectly block, they had still obeyed the rule. And strictly by the most narrow reading of the rule they had obeyed it. But they had defeated the purpose of the rule.
So definitely Chesterton's Fence adjacent, but not Chesterton's Fence itself.
Am reminded reading this of an esteemed and since passed away colleague who had written windows driver code since the dos days and may have had decades of insanely archaic knowledge die with him - when working on a difficult piece of windows driver code years ago, he said to me in a thick eastern europe accent as best i can remember “you make the primary mistake of thinking anything in windows makes sense. once you a…