I've seen a host of other imperfect measuring sticks, including the "tickets" metric I cited. But the post to which I was replying said that people are judged on how much code they write.

If I can close 100 tickets with less code than someone else, I've still closed 100 tickets.

The big issue has been that in the US, the followup colonoscopy was often no longer covered by insurance as it was no longer classified as part of the preventative medicine tier, and instead was now a different sort of procedure. My understanding is that this is no longer true though.

I live in an area of the US that the vast majority of US citizens would describe as "city" yet it doesn't conform to your description. The kids here get along just fine. But it's an important distinction because it would have been described as more of a suburb 100 years ago in that we are a few miles away from the heart of downtown.

I was online in that age group by the late 80s. Just as in your story, that started me down a path of not going outside as much, even though the other kids would be outside doing outside things. Why would I go out and play basketball or something else I didn't like when I could instead be online talking to people with shared interests?

Can it cause bugs? Yes. Do teams ship production code that meet their business goals? Also yes. The former doesn't necessarily preclude the latter. And as long as the business keeps on trucking along, complaining about the bugs and headaches is just a matter of engineering sensibilities. Which I agree with fully and grind my teeth every time.

If the business proceeds along just fine, having the perfect temple of dependently typed, category theoried, memory checked, fuzz tested software may have turned out to just be a waste of money.

If, on the other hand, the business does not proceed along just fine because the team can't get anything done due to not being able to understand that a float probably shouldn't go into a variable that's supposed to be a string, then yes, you're right.

The original post to which I responded said "it's disastrous for code that requires development by a team". Anyone claiming that using Python in a production environment is "disastrous", or equivalent to hitting a nail with a rock, is being obtuse. It has and continues to happen all the time with no notable ill effects. It's not like these teams are using Brainfuck here, Python is one of the most mainstream languages in the world, and I don't think I need a cite to make the claim that many, many teams manage just fine with it.

When I said "it usually doesn't matter", i'm talking in terms of the most important metric for a team: are the business goals being met i na timely and cost efficient manner. And my experience has been that as much as I've been a zealot in the past claiming that this tool or that tool can't possibly achieve useful results, teams that do use those tools still manage to achieve their business goals. Meanwhile I could also look around and find plenty of teams using whatever the flavor of the week "ideal" tool is and find teams that aren't meeting their goals.

Now, in an absolute objective sense, is it true that some tools are better fit for some purposes than others? Of course. Is it true that some languages lend themselves to robust coding practices than others? Of course. But the world's not a vacuum, and one must do the calculus at a higher level because as I said, the most important metric for a development team is achieving business goals. Would adopting tool A over tool B (for any A, B) improve the business? That's when these questions get a lot murkier, and the relative advantages & disadvantages tend to drop into the "noise" category.

People who say it’s impossible to use a 8gb MacBook are being obtuse

Yes, to an extent. And it's also the case that it usually doesn't matter. And that's my point.

I have also been someone like GP poster who has declared that it's physically impossible to produce valid software with XYZ tool in a team environment. And yet, there are oodles and oodles of counterexamples in the real world that proved me wrong and it worked AOK for them.

Could they all have been better off using another tool? Hypothetically yes. But their business needs (or whatever) were met and thus disproves a claim it can't be done.

Linux had a similar problem but had the advantage of open source. Random people would cobble together support for things and stick it online.