My rule of thumb is that 'the smartest code, is the code that you can work on in your dumbest moments'. Or, in a team, 'the most senior code, is the code where

My rule of thumb is that 'the smartest code, is the code that you can work on in your dumbest moments'. Or, in a team, 'the most senior code, is the code where the most junior dev can easily work with'. They may seem obvious. But in practice, far too often do I encounter code that is far too complex, and fails your porthole principle, and extremely hard to reason about, or work in, without worrying. Now, when such code is made by an inexperienced dev, this is fine, and acceptable: finding the right abstractions, or even seeing the need for those, comes with experience. But when senior devs produce such poorly abstracted, hard to reason, complexities, it is inexcusable. It is your task to make complex problems simple. To make unreasonable domains reasonable. To apply the right abstractions in the right places. To make code that you can work on when tired, distracted and stressed. To build structures where a junior can feel at home in, in hours.