This tells me a real developer wrote the docs, instead of someone with good English writing skills but is less technical.
> they could have even used their own LLM to edit their documentation to fix grammar issues
In my experience companies who do this rarely stop at using LLMs to fix grammar issues. It becomes full on LLM speak quite fast, especially if there isn’t a native English speaker in the room who can discern what’s good and bad writing.
I’d even argue that most things operated by tech doesn’t need 24x7x365 availability. If it’s about life-and-death, then yes make it super reliable and available. Otherwise, bring back scheduled downtime please.
I’ve always thought about this as more of a meme than a serious point. Trivially, aren’t most of the network protocol RFCs “sufficiently comprehensive spec that isn’t code”?
I think there's also something about being able to make it exactly how you want. For example I didn't like openclaw, I felt it was extremely over-engineered and I honestly couldn't even get it running on my first attempt. So I made botctl to be a generalized version where it doesn't rely on complex setup and have every bell and whistle, you just install it, create a directory with a BOT.md file and off it goes.
Weird that this needs to be said. I’m not familiar with the Go ecosystem, but there is usually a natural incentive for library developers to reach more people, which means you’d want to support the oldest feasible version. If you don’t do that then someone will develop a better library which does support an older version. Is that not happening here?
What the article does not say is that if you don't have a recent enough version, by default, Go automatically downloads a more recent toolchain. So, for most users, this is transparent.
However, this behavior can be disabled (for example, when building for a Linux distribution).
The problem is scale. Beyond a certain scale it’s all a net negative: social networks, bitcoin, ads, machine learning, automated trading, big this big that, etc.
Unfortunately for fellow developers, software enables massive scale.
A lot of process and management is about dealing with low performers - by which I don’t mean incompetent people but people lacking motivation, or with the wrong intuitions, etc. Our hiring process can’t reliably filter out low performers, and when they get in it’s difficult to fire them, so we invent ways to raise the bottom line through processes.
And FWIW I don’t think you can solve this by always hiring the “best” either, at least not beyond a certain team size.
> they could have even used their own LLM to edit their documentation to fix grammar issues
In my experience companies who do this rarely stop at using LLMs to fix grammar issues. It becomes full on LLM speak quite fast, especially if there isn’t a native English speaker in the room who can discern what’s good and bad writing.
reply