Understanding the rationale behind a rule when trying to circumvent it
devblogs.microsoft.com
Understanding the rationale behind a rule when trying to circumvent it
1–10 of 38 posts
Re: Understanding the rationale behind a rule when trying to circumvent it
#2Microsoft is so broken that an employee finds it easier to write a blog post about a documentation improvement than simply making that improvement? Explains a lot. "Conway's Flaw?"
Re: Understanding the rationale behind a rule when trying to circumvent it
#3Am 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 abandon this bias, you may someday hope to get where i am”
Re: Understanding the rationale behind a rule when trying to circumvent it
#4Microsoft is so broken that an employee finds it easier to write a blog post about a documentation improvement than simply making that improvement? Explains a lot. "Conway's Flaw?"
the blog says the documentation improvement was made in 2020? presumably not by the post author either
Re: Understanding the rationale behind a rule when trying to circumvent it
#5of course they had to add dont wait for your worker thread in 2020
Re: Understanding the rationale behind a rule when trying to circumvent it
#6Microsoft is so broken that an employee finds it easier to write a blog post about a documentation improvement than simply making that improvement? Explains a lot. "Conway's Flaw?"
Always been that way
Re: Understanding the rationale behind a rule when trying to circumvent it
#7This 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.
Re: Understanding the rationale behind a rule when trying to circumvent it
#8There 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 gets beaten out by the others, like "seems like you're new here".
Days 4-12, they've replaced one monkey per day, so that no monkey was here when it was possible to get the banana. None of them have ever been sprayed either. Still, they enforce the rule not to climb up there.
I am putting this example because in our society as well, there are many rules that are enforced without anyone questioning the "why". Yet the "why" is often more important to know than the rule itself.
Designers know this dichotomy between the "why" and the "how". Most people don't.
Re: Understanding the rationale behind a rule when trying to circumvent it
#9Microsoft is so broken that an employee finds it easier to write a blog post about a documentation improvement than simply making that improvement? Explains a lot. "Conway's Flaw?"
Raymond's important and high up enough that he probably only needs the approval of three AIs and five managers to publish a blog - updating documentation likely needs twice that.
Re: Understanding the rationale behind a rule when trying to circumvent it
#10This 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.
[flagged]