My take has nothing to do with charity to Cloudflare, but to the author. I can't help remembering that quote from the 50's where an IBM exec said they weren't going to fire an employee who made a costly mistake for the company, they just spent $$$ training them.
I think it's fair to assume, given the historical quality of the CF blog, that this was a (big) mistake by an individual, and not "Cloudflare", as an entity, making this claim.
My charitable read on this is that an individual vibe-coded both the post and repository and was able to publish to the Cloudflare blog without it actually being reviewed or vetted. They also are not an engineer and when the agent hallucinated “I have built and tested this and it is production grade,” they took it at face value.
You can tell since the code is in a public repository and not Cloudflare’s, which IMO is the big giveaway that this is a lesson for Cloudflare in having appropriate review processes for public comms and for the individual to avoid making claims they cannot substantiate or verify independently.
Because users do not know that there's some hypothetical "better" experience they could have had and do not care, unless your service/tool/whatever is not functioning correctly. Prioritizing your employees' enjoyment and experience to deliver more, faster, and consistently, is in all likelihood a better decision than prioritizing some subjective improvement to user experience.
Of course there are exceptions. But it's definitely a hot take to say you should never prioritize DX over UX.
There’s a difference between “I don’t want any photos of my kids in a server anywhere” and “please don’t share pictures of my kids to other people unless we do it privately”, which your wife immediately violated by screenshotting an obviously private message.
I don't really buy the two main criticisms around code review. They're stated as intractable downsides but are really just cultural issues around how you perform code reviews.
If your coworkers are sending changes for review that don't explain why the changes are being made (and therefore provide the context), reject it until they write a proper summary/test plan that does explain it. You should review the "metadata" of changes before you ever review the code itself and if done well, you'll probably be able to guess what a lot of the incoming changes are before reviewing the code. This makes it easier to spot code that deviates from the stated purpose of the changes and can help identify faults in both understanding of the overall problem or the system being built, especially in more junior engineers.
If your coworkers are taking to long to review changes, work with your team to incentivize expedient code reviews, or talk to the people that aren't reviewing enough code to help everyone else get more done. You should also utilize a stack that lets you continue progressing with your work even when waiting for reviews (like stacked diffs).
> it was assuredly brought high up into the DoJ and approved.
The warrant was approved, but the issue at hand is that these safety deposit boxes were raided when "the warrant authorizing the raid explicitly forbade the FBI from seizing the safe deposit boxes or their contents."
I really dislike this meme of pointing out that Google has deprecated a lot of projects. Do people actually expect Google to staff people & resources running every project they've released forever?
A more interesting comparison would be open source projects that Google has abandoned or failed to properly hand over control of to the community, especially if we're talking about Go.
I think it's fair to assume, given the historical quality of the CF blog, that this was a (big) mistake by an individual, and not "Cloudflare", as an entity, making this claim.