Software engineering is a weird niche that is both a high paying job and something you can almost self-teach from widely available free online content. If not self-teach, you can rely on free online content for troubleshooting, examples, etc.
A lot of other industries/jobs are more of an apprenticeship model, with little data and even less freely available on open internet.
> something you can almost self-teach from widely available free online content.
I think you massively underestimate just how much data is online for everything, especially once you include books which are freely available on every possible subject (illegally, perhaps, but if Meta can download them for free then so can everyone else).
There's less noise for many other subjects than for software engineering, there's often just a couple rather than 100s of competing ways to do everything. There might just be one coursebook rather than 1000s of tutorials. But the data for self teaching is absolutely there.
Consider two fields with vast amounts of literature: medicine and law.
Medicine faces two key challenges. First, while research follows the scientific method, much of what makes a good doctor—intuition, pattern recognition, and clinical judgment—is rarely documented. Second, medical data is highly sensitive, limiting access to real-world cases, images, and practice opportunities. Theory alone is not enough; hands-on experience is essential.
Law presents a different problem: unknown unknowns. The sheer volume of legal texts makes it nearly impossible to be sure you’ve found everything relevant. Even with search tools, gaps in knowledge remain a major risk.
Compounding this is the way law is actually practiced. Every judge and lawyer operates with a shared foundation of legal principles so basic they are almost never discussed. The real work happens at two higher levels: first, the process—how laws are applied, argued, and enforced in practice. Then, at a third, more abstract level, legal debates unfold about interpretation, precedent, and systemic implications. The first level is assumed, the second is routine, and only the third is where true discussion happens.
Self-teaching is easier in fields where knowledge is structured, accessible, and complete. Many subjects are not.
A significant chunk of human knowledge is not publicly accessible. You cannot self-teach how to make a modern aircraft, jet engine, nuclear reactor, radar tech, advanced metallurgy etc.
Similarly, I would wager most of the useful economics and financial theory that humans have come up with is only known to hedge or prop trading firms.
For some subjects, the entire journal-published academic body of knowledge for it is probably some useless fraction of the whole and university academia is operating nowhere close to the cutting edge. People are probably doing PhDs today on theses that some defense contractor or HFT firm already discovered 20 years ago.
Even things like specialized medical knowledge, I would wager is largely passed down through mentor-mentee tradition and/or private notes as opposed to textbooks. It's unlikely that you can teach yourself how to do surgery just from textbooks. I once had a pathologist's report use a term for a skin condition that was quite literally ungoogleable. The skin condition itself was fairly ordinary, but the term used was outright esoteric and yet probably used on a daily basis by that pathologist. Where did he learn it from?
Taylor Wilson built a nuclear reactor at his home when he was 14. People build jet engines and put them on modern model aircraft every day.
If the instructions aren’t immediately available, the internet provides connections and forums to find anything your heart desires.
Information wants to be free.
Arbitraging micro-opportunities (or far more likely, deploying insider information masked as HFT or some secret sauce arbitrage) is not economically useful.
> Software engineering is a weird niche that is both a high paying job and something you can almost self-teach
If you meant programming, I agree it could be self-taught, but not SE. SE is the set of techniques, practices, tools that we have collected over decades for producing multi-versioned software that meets a certain reliability rating. Not all of these is freely available online.
I'm self-taught and had a job in the autonmous vehicle industry writing software that included safety-critical functionality.
I had about 12 YoE at the time, and my manager didn't realize I didn't have a degree until after I was hired. Apparently it hadn't affected my offer, and he was more impressed than anything.
You say:
> SE is the set of techniques, practices, tools that we have collected over decades for producing multi-versioned software that meets a certain reliability rating. Not all of these is freely available online.
The same way there's no single guide on the internet on how to be the kind of engineer who builds reliable or extensible software, I don't think there's a guide hiding in the average CS curriculum.
Most of it consists of getting repetitions building software that involves the least predictable building block in all of software engineering (people), in all its various forms: from users, to other developers, to yourself (in the future), to "stakeholders", etc.
Learning how to predict and account for the unpredictability in all the people who will intersect with some facet of your software is the closest I've seen to a "universal method" for creating software that meets the criteria you defined.
And honestly I'd be concerned if someone told me you can just be taught some blessed set of tools and practices to get around it... that sounds a lot like not having actually internalized why they work in the first place, and the "why" is arguably more valuable than the tools and practices themselves.
this is a challenging point of view.. on one side, a "a job in the autonmous (sic) vehicle industry writing safety critical software" sounds like one of the most slave-ish jobs in the world. This person had a 100 other people checking every tiny result, plus automated testing frameworks and hundreds of pages of "guidelines" .. in other words, the least creative and most guard-checked software possible.
On the other hand, an open and level playing field does not exist in the thirty-some odd years of open markets software development. No one since Seymour Cray has done complete systems design, really.. it is turtles all the way down. You have to get hardware to run on, and the software environment is going to have been defined for that.. CPU architectures and programming languages. People who write whole systems generally do it in teams.
The arrogant and self-satisfied tone of the corporate worker-bee says that there is no such thing as real software engineering skills?
like defining "health" or other broad topics.. the closer the topic is examined, the more holes in the arguments. I am glad I never punched a time clock for Elon Musk, however, all things considered.
...who don't get hired at "real" jobs because they can't produce a bubble sort in 15 minutes on a whiteboard.
I feel very fortunate that the core blender devs had the patience to put up with my stupid amateur mistakes while I learned the skills to become a helpful contributor back in the day.
Software engineering is a weird niche that is both a high paying job and something you can almost self-teach from widely available free online content. If not self-teach, you can rely on free online content for troubleshooting, examples, etc.
A lot of other industries/jobs are more of an apprenticeship model, with little data and even less freely available on open internet.