ampersandy

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.

Have any examples in mind of the “really good tracks?”

It looks like they've copied the template/page from a previous diagram file and forgot to remove one of the lines, probably just an accident.

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.

The implied disagreement for why neovim exists to provide functionality that wouldn’t have been merged into vim.

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.

It’s not prioritization if it doesn’t hurt.

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).

What about staying inside with cool/dry air causes these infections? Genuinely curious.

> 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 love learning more about the ampersand, for obvious reasons.

I've used this unixname for a long time and it's always immensely satisfying when people realize it's just my real name.

I would have used it! :)

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.

You can totally implement A/B tests on top of a feature-flag framework. Your “pass” function should be hashed on the User ID/Cookie/whatever and then you can distribute users into pass/fail. You should do this anyway for reproducibility. If you log whether they passed/failed and then have metrics, you compute experimental results.

Er, I don't really think dine-and-dashing is quite the same as being treated to your meal because you are on a date.

Do you have any resources on how you learned to create such loaders? I hacked together a custom loading animation for some tools I've built just using images & css transforms, but would love to learn to make things even slicker.

You may like Tomorrow, which has several sub-themes and is available for dozens of apps. I use Tomorrow Night Bright for everything.

https://github.com/chriskempson/tomorrow-theme

Requiring users to know what sites they want in advance somewhat defeats the purpose of a search engine, no?

> I'm not entirely sure why buzz around "developer learns basic knowledge" has this on the front page.

Because it's a well written, humble account of learning from a mistake then using it as an opportunity to teach others to help them avoid the same mistake.

If anyone leads a team, I hope they might learn from this approach, rather than just bashing on people and implying they don't deserve any attention because they made a mistake a more experienced developer might have dodged.

Assuming 2 day shipping, you probably lose ~2 real hours of time, but have no working cable for at least 4 days.

- a few minutes to order the cable

- 2 days for the cable to arrive

- ~2 hours to realize it does not work, complain, initiative a refund, print a return label, and drop it off at a post office

- another 2 days to wait for the next cable.

> The value of the cumulative labour of Mailchimp's engineers is $12 billion which vastly exceeds the amount it was sold for.

Yes, that's how employment works. Companies do not pay you exactly the same $$ you generate, that's just common sense? Why would they employ you if you cost just as much profit as you generate?

The question here is whether Mailchimp _exploited_ its employees by not offering equity. Unless an employee was lied to and told they might later receive equity, they all joined under the assumption that they were making a mutually beneficial agreement, and that the compensation offered by Mailchimp was worthwhile (as opposed to going and starting their own company or working for another startup that offered equity).

Every Mailchimp employee was welcome to start their own company if they wanted to capture 100% of the profits they generated.

They wouldn't — and Mailchimp employees didn't. The market value of your labour is what you can get a company to pay you.

The hypothetical market value of employees in a world where Mailchimp did offer equity and employees stuck it out to reap that upside doesn't exist, so arguing the point makes no sense.

What sort of qualifications/awards/etc. are most compelling for O1 visas as a tech worker that would demonstrate you are at the "very top of your field"? What examples of work do you commonly see for people making these applications?

I'm curious what types of things a regular tech employee could do while employed to demonstrate that they'd meet these criteria.

This fear of failure by others is why so many people have a hard time delegating. Sometimes things will fail, and that’s ok (with a few exceptions, of course).

Surely the hot take should be that the kernel is at risk of a malicious actor introducing bugs that can be exploited, not "Oh, we already write bugs so it's not a big deal."

This seems like a rather lackadaisical take on the situation.

What a fascinating watch! That they were able to produce such clean cuts through the entire ship with the cutting wire is absolutely incredible.

As a trading noob, what then happens when you sell a future but do not buy one later (and you obviously don't have X amount of crudge to deliver to Cushing)?

Also, any suggestions on good books to learn more (not necessarily to start trading in futures, but just to understand the market dynamics)?

The imaginary PM stereotype everyone likes to bash would do that, real teammates you work with that respect your time will work with you to plot things in a way that better reflects the team/organization’s shared priorities :) Don’t sell this short because of an imaginary threat (rampant PM abuse)!