The cognitive load increases the furthest away you get from the problem you're trying to solve. I've worked with some really smart people that couldn't program

The cognitive load increases the furthest away you get from the problem you're trying to solve. I've worked with some really smart people that couldn't program themselves out of a 24hrs challenge because they went deep in lalaland with patterns up the wazoo and didn't just consider what the program needs to do. A program is a set of instruction for a computer to do stuff. It takes data in, does stuff to it, and pushes it out. Whether you're doing a UI or an automated landing system, it's all the same. In one case, you're waiting for user input to do stuff with it, on the other you're reading sensors at a high frequency and affecting control inputs as a feedback loop. Patterns should only be used if they actually solve a problem. E.g. the command pattern in systems that require Undos. The simplest way to manage complexity in any program is to manage state carefully. Avoid global state, and use as much pure functions as you can. The net effects of this has been evaluated ad-nauseam and the results are clear: easier code to reason about, easier to parallelise, easier to test and less cognitive load. Over-using patterns and abstractions is throwing cash in a pit. The harder a system becomes to reason about or change, the more it will cost to maintain. Over-abstraction will result in main() { application_here() } which might look good in reviews, but the metrics won't add up.