Rendered at 13:44:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
JohnMakin 5 hours ago [-]
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 abandon this bias, you may someday hope to get where i am”
caporaltito 41 minutes ago [-]
We all knew this kind of guys. Bless them
techwizrd 3 hours ago [-]
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.
zellyn 16 minutes ago [-]
Came here to say this. How can you write an entire article about Chesterton’s Fence without mentioning Chesterton’s Fence?!
keybored 1 hours ago [-]
HN will find a fence and say “I know this one, we must be conservative about messing with this fence”. Then they will implant LLM chips in the animals inside the enclosure.
They why behind conservative principles didn’t penetrate deep enough.
rcxdude 9 minutes ago [-]
It's also a mistake to only focus on the original intent of putting something in. It's quite common that other things comes to depend on that thing even after the original reason is gone (or even that the thing works but not for the reason that was thought).
cbondurant 44 minutes ago [-]
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 properly identify which details are actually self-evident, and which are only obvious because they already know them).
Another example of why technical writing is difficult, I think.
harrouet 2 hours ago [-]
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 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.
bluGill 40 minutes ago [-]
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.
iliveinberlin 22 minutes ago [-]
parables that didn't happen can still be useful
bluGill 36 seconds ago [-]
They can be, but you need to take care as sometimes they are misleading and can even drive wrong decisions.
nottorp 36 minutes ago [-]
How many of these winapi callbacks should have been just messages?
OneManHorde 5 hours ago [-]
Microsoft 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?"
bombcar 2 hours ago [-]
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.
throawayonthe 5 hours ago [-]
the blog says the documentation improvement was made in 2020? presumably not by the post author either
pwagland 1 hours ago [-]
From the article:
> The documentation should open with something like this:
>> The callback function must perform its work quickly without blocking. If you need to do complex work or synchronize with other threads or processes, do the work asynchronously, such as by using System Worker Threads.
A change was made, but not the change that Raymond thinks would explain why the list is there anyway.
sebastianmestre 1 hours ago [-]
He used his blog to queue the work to be executed asynchronously by another MS worker that reads it
pwagland 1 hours ago [-]
And, since he isn't waiting on the reply, he is following the rule for the callback.
chadgpt3 4 hours ago [-]
Always been that way
ElenaDaibunny 4 hours ago [-]
of course they had to add dont wait for your worker thread in 2020
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.
They why behind conservative principles didn’t penetrate deep enough.
Another example of why technical writing is difficult, I think.
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.
> The documentation should open with something like this:
>> The callback function must perform its work quickly without blocking. If you need to do complex work or synchronize with other threads or processes, do the work asynchronously, such as by using System Worker Threads.
A change was made, but not the change that Raymond thinks would explain why the list is there anyway.