Readit NewsMy understanding was that it was the tenant rights movement that killed SROs and boarding houses by making it practically impossible to keep them orderly, because it made eviction almost impossible and compliance with anti-discrimination laws presented too large a burden for low-cost housing.
And rather than being refuges for same-sex couples and generally "[offering liberation from family supervision and the constraints of Victorian mores", they were the opposite -- often being extremely stringent in "morality" clauses and forbidding mixed company after dark. They were frequently racially exclusionary in ways that became incompatible with civil rights laws.
The reality is that the situation was probably a mix of both attacks -- attacks through over-regulation and tenant rights, as well as direct attacks on SROs as hotbeds of crime and illicit or immoral behavior, but I'm curious as to the mechanics of how this came to be.
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
But I think Sisyphus must have gotten at least some satisfaction for almost reaching the top.
(Mixed rating, according to Snopes.)
> Consider the humble modal dialog. The web has <dialog>, a native element with built-in functionality. [...] Now observe what gets taught in tutorials, bootcamps, and popular React courses: build a modal with <div> elements
The dialog element is new! Only broadly supported since 2022. I find it hard to fault existing material not using it. Things like dialog, or a better select, are notable because they were lacking for so long.
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.
In practice:
- smaller PRs aren’t necessarily easier to review (and this arbitrary obsession almost always leads to PR overload in chunks that don’t make any sense, reducing code quality as a result)
- nobody reads intermediate commit messages one by one on a PR, period. I worked on a team where the lead was adamant about this and started to write messages in the vein of “if you’re reading this message, I’ll give u $5”. I never paid anyone a dollar. Don’t waste your time writing stuff for no one.
- “every commit must compile” - again, unnecessary overzealousness. Every commit on the MAIN branch definitely should compile. Wasting your time with this in a branch, as you work towards a solution, is focusing on the wrong thing
You want PRs because they help others absorb what you’re doing (they’ll have to read that same code sooner or later). You don’t want to create a performance theater.
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.
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.
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.
Prescriptivism is appropriate for technical or legal discussions, where the specific meanings of words are hugely important.
Descriptivism is appropriate for casual communication, where it's fine as long as your intended meaning comes across.
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".