I think it helps to know of ways to model problems beyond "arrangements of objects in patterns" which is the thing that CS education has dropped the ball on the most: you get the algorithms, you get some exposure to practical systems, but then there's no checklist of approaches to try, no nmemonics to learn. Just a faint hope that slathering objects on a problem does something helpful, propped up in turn by the large body of articles and blogposts that advertise silver bullet patterns(lately dominated by "ECS", which isn't really OOP specific but fits in the usual pattern of the hype cycle).

And that is in some ways related to the consumer nature of the programming stacks in use: If there isn't a named-and-documented "feature" for it, and it's not in the hype cycle, it's a less legitimate, more hyptothetical technique.

But what are those other ways? Where's the starting place? My own WIP answer is:

* Data modelling techniques(beyond algorithmic complexity concerns: data lifecycles, persistence, schema design, and so forth)

* Formal models of finite state(decision tables, statecharts, behavior trees, and so on)

* Constraint solver techniques and their many applications(type checking, physics steps, pathfinding, depedency checking, UI automation).

* Dataflow modelling, with static routes and bounded buffers.

* DSP techniques used to do analysis and filtering of digital events at scale.

There's still an overarching tendency to let execution flow get out of hand, and our current trend for asynchronous concurrency is an antidote only in the sense that it motivates the existence of rigor by blowing up easily.