The best resources I've encountered were not talks or books, but practical challenges that taught me a deep, almost tactile sense of software complexity.

The first was practicing typed functional programming in the ML tradition. Standard ML, OCaml, F#. If you've never programmed in such a language, it's hard to overstate just how simple they are. (I am not talking about Scala and Haskell, those are a lot of people's first contact with typed functional programming and they can be fiendishly complex.)

When you code in a language that is simple, there is no ambient complexity clouding your thoughts and obscuring the differences between different solutions. Simplicity becomes a matter of skill, rather than personal taste.

Typed functional programming should be enough to "jailbreak" the average working programmer. It's worked for me, it's worked for my peers, it's worked for my pupils. When they backport their understanding of the fundamentals into a mainstream programming language, they can code far beyond their years of experience. The converse is also true: senior software developers with a career's worth of experience in Java or C# frequently fail to write code that "simply works", all development is done by groping in the dark and iteratively approximating the spec until either it becomes "good enough" or the runway ends.

For those who've tasted simplicity and would like to go yet further: Software Foundations is an interactive textbook, almost a video game, about the formal verification of programs. You write code, and then you prove properties about your code. Proving doesn't happen automatically, you need to come up with arguments as to why your code actually works and encode those arguments into a proof script that the compiler then verifies.

As you get better at proving that a piece code abides by its specification, you begin to get a sense of which algorithms, and which branches of which algorithms, are going to prove vexing. Any code whose correctness isn't immediately, trivially obvious becomes a cause for alarm.

At this point you should begin to notice the insanity that is mainstream programming practice in most of the industry. Programmers treat their own code like a black box, they hammer it left and right until it slots into the shape it's supposed to occupy, at which point everyone understands that it is not to be touched or disturbed in anyway lest it totally and fractally dislocate. This isn't every team in the industry, but it is most teams at second- and third-tier companies, and even a surprising number at FAANG-tier companies. People bitch that the tech interview doesn't resemble day-to-day practice, and they are correct, but if you can't infer a loop invariant from a problem statement, then I'm sorry but your code only ever works by accident. Go back to basics.

In exchange for this existential despair, you will be able to effortlessly perform feats of clarity and correctness in software engineering that will leave your colleagues open-mouthed and slightly concerned for their jobs. And the process of getting there isn't awful either.