DavidWoof

That's not true. As with all game theory payouts, it's not saying that a Nash equilibrium is inevitable, it's saying that to avoid it you need incentives outside the game, it's saying that the incentives of the game itself don't suffice.

In terms of "the tragedy of the commons", that outside incentive is usually public shaming in smaller communities, or rules and laws in larger and more anonymous communities. If you look at shared resources across history and cultures, you usually find communities enforce very strong outside incentives against spoiling the commons instead of just relying on the kindness of strangers.

Under what circumstances a passenger needs to identity themselves differs significantly from state to state. Also, neither Brendlin v. CA or AR v. Johnson talk about identification requirements, so I'm not sure what you're thinking there. Maybe you're confusing it with exiting the car?

And before someone says "but the Supreme Court overrules the states", no it doesn't. Many state courts have found that their state constitutions grant their citizens more rights than the US Constitution in various circumstances.

I loved Connections so much as a kid, but I'm so tired of this clip. There's so many better clips from this show.

So he nailed a 13 second countdown. Who cares? Newscasters do this at every commercial break. Sports announcers do this without a script and they still nail the cut to commercial almost every time. Yes, there's a talent to timing your speech to a countdown in your ear, but it's a talent that people do thousands of times a day around the world on far less preparation than Burke had here.

The fact that this article calls a simple cut a "sleight of hand" just terrifies me. Does the public really not know what editing is?

It's very common the US as well, but primarily in education circles. I honestly have no idea what percent of the general public would recognize it immediately (hard to know for anything, really).

> My understanding was that it was the tenant rights movement that killed SROs and boarding houses by making it practically impossible to keep them orderly

It depends on the time frame you're talking about. Long-term SROs like boarding houses were absolutely affected in the 50s/70s by tenant rights laws. But they adapted. In the 70s/80s, SROs were still widespread in large cities except that they all had occupancy time limits (usually 60s days or so) to avoid tenancy laws. But people who relied on them could just move to a new one when the time limit came, so the market was still viable.

But then in the late 80s/early 90s they all got zoned away in the way this article talks about. It was really more NIMBY than reformer. Note that this time frame corresponds with the height of the US crime wave, and what was once a sketchy urban neighbor became the source of major neighborhood blight, especially as re-urbanization started up in the late 90s

I have Sisyphus as my wallpaper. When people ask about it I say he's the patron saint of software development.

In OP's defense, "becoming suspicious" doesn't mean it's always wrong. I would definitely suggest an explaining comment if someone is using DISTINCT in a multi-column query.

Snopes has this as mixed because Stalin may or may not have expressed this sentiment at some point, but it seems impossibly unlikely to me that this pun works in Russian as it does in English.

It's hard to talk in the abstract because obviously people can abuse any type of code feature, but I generally find chaining array methods, and equivalents like c# linq, much easier to read and understand than their looping equivalents.

The fact that you single out .reduce() here is really telling to me. .reduce() definitely has a learning curve to it, but once you're used to it the resulting code is generally much simpler and the immutability of it is much less error-prone. I personally expect JS devs to be on the far side of that learning curve, but there's always a debate about what it's reasonable to expect.

> “nobody reads intermediate commit messages one by one on a PR”

I clean my history so that intermediate commits make sense. Nobody reads these messages in a pull request, but when I run git blame on a bug six months later I want the commit message to tell me something other than "stopping for lunch".

> pedantically apply DRY to every situation or forcing others to TDD basic app

Sure, pedantically doing or forcing anything is bad, but in my experience, copy-paste coding with long methods and a lack of good testing is a far more common problem.

You may be 100% correct in your particular case, but in general if senior devs are complaining that your code is sloppy and under-tested, maybe they aren't just being pedantic.

JoelOnSoftware had a great piece back in the day where he mentioned that while he consciously knew what a short sale on an option was, in practice he had to stop and think about how to calculate it, while his financial friends just knew the answer immediately. He drew a comparison to pointers in C, where if you're going to be a C programmer, then pointers should just be intuitively obvious to you and not something you need to think about.

IAW, there are no pure fast or slow thinkers, a lot of this is just how well have you internalized the background material. Having quick repartee in conversation has absolutely no relationship to immediately seeing what the loop variable should be in a programming problem. FizzBuzz isn't quickly solved by decent devs because they think faster, it's quickly solved because it's a trivial problem that doesn't require serious thinking for experienced devs.

When I'm programming for finance or medical, I often have to tell the PM "let's stop here and let me think about this for a day". Because it's not my field, it takes me a while to get my head around it. OTOH, there's very often algorithm conversations where I have to wait for others to catch up.

One of the aphorisms I repeat a lot is that in this age where everybody programs a little, including analysts, devops, QA, researchers, etc., the thing that separates all of them from actual software developers is that developers know that "code is bad. Code is where I find all my bugs.

And I do wear these other hats sometimes. I think nothing of scripting a useful utility or cranking something out in R or VBA for a presentation. But when it comes to production code, I'll spend a lot of time trying to think of ways to reduce the amount of code required.

But it's two completely different philosophies regarding code, and unfortunately in some organizations AI is starting to blur the lines.

That's absolutely not what the article is about. Did you even read it?

People don't really have that debate anymore outside of twitter casuals, and it's dismissed with a wave almost immediately in this article, which then goes on to examine the complex grammar of "try and".

Give me an AI chatbot over someone with poor English skills reading a script any day of the week. My problem probably isn't unique, it's probably something fairly obvious that was vague in the instructions.

Now, the important thing is offer a way to upgrade to a human. But I have no problem at all starting with AI, in fact I honestly prefer it.

I think the "sendOnce" question is fine. Software development is just different than other professions, and you get a lot of candidates who talk a good show but can't actually program at all. For a decent dev, this isn't programming, it's typing.

But all the "ok, now add this feature..." stuff is just a sign that the interviewer is an insecure asshole. And you get insecure asshole interviewers in other professions as well, asking about obscure laws or diagnoses.

Software is still a bit of a craft, and it's perfectly reasonable to ask a job seeker on a construction site to go hammer a nail. But nobody is going to follow that up with a bunch of "OK, now do an L-joint" just to show off their own knowledge.