rgbgraph

> Medical school class sizes are not artificially restricted. Schools limit class sizes to ensure that almost all graduates can find a residency program slot.

This is paradoxical. Class sizes are limited by the school, but not artificially limited?

Medical school class sizes are artificially restricted by outsized requirements for admissions. For example, the requirement of an undergraduate degree in order to enter medical school is not something that exists in Europe. Or that the admissions and exam requirements are much less hyper-competitive in Europe, than the U.S. This is, of course, “to restrict the supply of residents, so each one can find a job.” It’s still artificial restriction, rather than a natural bottleneck.

The same AMA that “Twenty years ago, the AMA lobbied for reducing the number of medical schools, capping federal funding for residencies, and cutting a quarter of all residency positions,”[0] is now asking for support in reversing its schemes? That’s rich. The same AMA that makes hundreds of millions in revenues, by speculating in securities[1].

Like an alma mater asking you to donate to its investment coffers after it’s shackled you with debt.

[0] https://blog.petrieflom.law.harvard.edu/2022/03/15/ama-scope...

[1] https://www.epsilontheory.com/ama-bitfd/

- Artificial restriction of class sizes in medical schools.

- Egregious costs just to become any sort of practitioner (medical school, residency, etc.).

- Insurance companies are basically always grifting you as a policy, unless you call them out on it (reasonable things will be denied and not covered, because most people won’t fight).

- Hospitals are basically always grifting you, unless you call them out on it (bills are basically fraudulent).

- Pharmaceutical companies are basically always grifting everyone (you, the FDA, the prescribers, the insurance companies, etc.).

- Doctors are basically grifting themselves (going into medicine, and staying, almost always for the wrong reasons).

This is just to name a few.

Fair assumption; but anyone who’s done any research into the history of education in the U.S will tell you that phonics has vastly superior outcomes to “whole language” schemes.

Learning to read via phonics vs the alternative is like the difference between being born into wealth and opportunity, and being born a slave.

No hyperbole.

Yeah, a lot of the .NET stuff is low-paid, low-challenge big business work (and the only high-visibility "cool" .NET work is at MS).

There's a few positions that intermittently pop-up doing "cool" work in .NET: usually startups, or small teams; the chances are much rarer, and you have to be in the right place at the right time -- but your chances are much greater than someone who's coming in from any other ecosystem (e.g. Javascript back-end).

Or in other words, sniper vs shotgun approach. You're going to get less targets overall if you specialize; but it'll be much easier to have a strong chance of being "the best" in the crop of applicants (or even for marketing purposes, a la personal consultancy).

Lovely article -- very original.

I'll add some anecdata, to give more context on why "atmosphere at all costs" might be en vogue.

- Most software engineering is CRUD

- Almost all 3rd generation, higher level languages can achieve CRUD (e.g. Javascript, C#, Java, Python, Ruby, PHP, Python, Perl -- even Bash)

- Most engineers will not have to dig around in the internals of a language to be able to do their jobs (e.g. that you can fine-tune and pick your own garbage collector (or even disable it completely), depending on the domain in Java (such as low-latency environments); whereas in .NET, you cannot really tune, swap out, or turn off the GC completely)

- Without needing to know the internals of a language, all the aforementioned languages are largely interchangeable (again, for CRUD -- and based on taste)

This is why you may commonly see people recommending that even if you don't know a language, you should be able to pick up whatever language a potential engagement requires (see: "a senior should be able to pick up frameworks and languages within a week or two"). I've always disliked this way of seeing the world. It rubs me in a certain grating way: that most work is CRUD, so you should optimize your career for being an interchangeable COG.

In my experience, if you take the time to learn a single language or ecosystem thoroughly, your chances of finding work for that specific ecosystem greatly increase -- versus the "generalist." Likewise, you'll be able to tell when it's the tool that's messing up, or yourself. Further, you'll be able to find more interesting, "deeper" work to handle -- rather than just building another CRUD web app. And lastly, life is too short to work with stuff you don't like.

For example, I love the .NET ecosystem. If I want to build something that isn't in the HPC space, I'll reach for it first. I know Java, but I don't like Java -- and I do not ever want to work with it. My ability to land .NET work is much easier, because I know the ecosystem -- not just how to program in an OOP language.

Or how about databases? I love Postgres. If I want a great OLTP DB, without any fuss, I'll reach for it first. I know MySQL/Mongo/SQL Server (to be fair, this one is also really good)/etc., but I don't like most of them. My ability to land work that utilizes Postgres is much easier, because I've taken the time to thoroughly understand it.

Or in other words, most people in the game are optimizing for commerce: how much money they make.

The hackers? They're in lower-level, systems programming languages; they're in compiler and language design; they're in low-latency or kernel programming; they're in stuff that isn't directly related to making money. Part of the reason I'm learning C++ is because the work there is more interesting (database engineering is very fun, but you need C++ or C in some cases) -- and the people more passionate. But also, because the gravy train is starting to dry up in CRUD -- anyone who can program can do it.

1. Not everyone and their dog was getting into tech; there was a lot of low-hanging fruit, and a lot lower bar for what was considered "impressive."

2. The bar for impressive is now "insanely complex."

3. The tools were shittier, but more flexible, and you sucked it up and learned to deal. Now? The majority of our tools are overengineered in all the wrong places, because their contributors wanted to build something "impressive" (using today's standards) -- rather than useful and practical.

We had jQuery (a library) and PHP (a language modeled after the hit Microsoft classic, Minesweeper), and that was enough. Now you need React/Vue/whatever framework to build an "impressive" website (because you'll look like a clown if your website isn't as "polished" as your competitors -- who are also using newfangled frameworks)

It was easier to build shit back then, because the standards and expectations were saner.

A DB article that you can actually learn something from. Lovely