Two other superpowers: (1) don't try to impress yourself or anyone else with the sophistication of your solutions, in fact do the opposite finding simple mechanisms that fit the problem. When you do this well, the solution looks simple, and makes the original problem seem much less hard. People don't do this because there's little credit to be had in a simple solution to a non-hard problem. Just keep in your own mind that it was a hard problem and finding that simple solution wasn't easy. With repeated practice, this means you can solve more difficult problems than others because you operate at a lower ratio of solution-complexity:problem-complexity. This is how you deal with intrinsic complexity rather than incidental. (2) Do not think procedurally (like a machine) in time steps. Think in invariants, decompose into independent logical partitions, ensure that logic is composable. When we say make code easy to 'reason about' we want to be able to, at each level, understand only what the subparts are doing, not how, and that those parts do not interfere with each other. If you repeat this at every level, you need to keep far less in your 'working memory' compared to problems that have deep implementations to keep in mind to understand and use properly. Related to this, relate the implementation structure to a conceptual model, and don't be compelled to make the conceptual model into concrete form, that tends to only add incidental complexity. People tend to do this because the conceptual model is cool and beautiful and would like to be able to show it, see it. Whenever you see a deep implementation stack that seems excessive and unnecessary there was probably a simpler implementation where each concept didn't have to be an explicit piece of architecture. Again this is very much less code, and less impressive to the unenlightened, but don't concern yourself with that, lose the ego (or rather feed it yourself instead of externally), only focus on solving hard problems with simple, underappreciated solutions.