I find the author’s writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.

I tried reading the article and gave up because life is too short for me to read a tiresome article making points that aren’t even particularly that new.

Something that definitely separates me from some of my less experienced coworkers is that, when I sit down and start to implement a plan I came up with in my head, if it turns out that things start exploding in complexity then I reevaluate my plan and see if I can find a simpler approach. By contrast, my less experienced coworkers buckle down and do whatever it takes to follow through on their plan, as if it has now become a test of their programming skills. This makes life not only more difficult for them but also for everyone who has to read their code later because their code is so hard to follow.

I try to push back against this when I can, but I do not have the time and energy to be constantly fighting against this tendency so I have to pick my battles. Part of the problem is that often when the code comes to me in a merge request it is essentially too late because it would have to be essentially completely rewritten with a different design in order to make it simpler. Worse, the “less experienced” coworker is often someone who is both about a decade older than me and has also been on the project longer than me, so even though I technically at this point have seniority over them in the hierarchy I find it really awkward to actually exercise this power. In practice what has happened is that they have been confined to working on a corner of the project where they can still do a lot of good without others having to understand the code that they produce. It helps that, as critical as I am being of this coworker, they are a huge believer in testing, so I am actually very confident that the code they are producing has the correct behavior, even when I cannot follow the details of how it works that well.

So does that make the new name the undead name, and therefore like a zombie name?

Huh; I don’t believe that it is really him.

If this is the real Slim Shady, would you please stand up?

Every one had already been launched.

All of these options are still better than spending full price for a pair of jeans that were lovingly crafted to start with holes in them!

Easy: recognizing bird calls on my phone.

The difference is that aether unraveled pretty quickly when we started seriously looking for it because experiments kept being outright inconsistent with what it was predicted we would see if it were there, whereas there are lots of independent lines of evidence that all point to the dark matter existing in the same page, so it really is not the same situation at all. The only problem with dark matter is that it doesn’t show up in our particle detectors (so far, at least), but there is no law of the universe that says that everything that exists has to.

It helps to realize that mass is just a bookkeeping label that we assign to the “internal” energy of a system, where the choice of what counts as being “internal” is somewhat arbitrary and depends on the level we are studying.

For example, if you measure the mass of the nucleus of some atom, and then compare your measurement to the sums of the masses of the protons and neutrons inside of it, then you will see that the numbers do not agree. The reason for this is that much of the mass of a nucleus is actually the energy of the strong force bonds holding the nucleons together.

But you can actually drop down another level. It turns out that the vast (~ 99%) majority of the mass in the proton in turn does not come from the quarks but from the energy of the gluon field holding them together.

And if you drop down yet another level, the quarks get their mass through their interactions with the Highs field.

So in short, it is energy all the way down.

I disagree; I think that we do care about it being popular enough that it incentivizes software and hardware vendors to support it rather than ignoring it.

Sometimes this can help, but lately I’ve been running into the opposite problem where people have been following this advice to such a degree that one cannot ever figure out what is going on without having to constantly jump around to find the actual code involved in doing something.

Because some of us are bitter at the trees for generating so much pollen at this time of year and want revenge.

Spotted the INTERCAL programmer.

Because it looks like that functionality uses special compiler functionality only available on GCC and clang?

“This isn’t us encouraging you to gamble-it is us asking you to think about how bad you would feel years from now if you learned that you could have made a ton of money if you had only placed a bet right now! It’s completely different!”

I see a lot of enthusiasm here, and there is nothing wrong with that, but… am I the only one who actually found the movie to be kind of disappointing?

No, it will be too busy making paperclips to even notice us, except as a nuisance getting in the way of it making paperclips that needs to be eliminated.

Yeah, I miss living in Australia where you didn’t have your own waiter but on the other hand that meant that it wasn’t rude to flag down any of the wait staff if you need anything rather than being restricted to having to go through a single person.

Ah, yes, the good old git off --my lawn command.

Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (git rebase --abort) and using a merge instead.