Understandable code is the main goal; the app is just a side-effect!

As game/software developers, our job is to understand the system-under-develop, which is a game in our case, and then codify that knowledge. We can think about it as writing down or reporting what we've learned or discovered after researching a science subject. The same way we want our report to be understandable by the next scientist, we want our codebase (codified knowledge) to be understandable by the next developer. The only difference is that the language we use to express our understanding can be a bit weird to some people sometimes. This is because our codebase has a secondary user called compiler, and it doesn't understand the human language very well.

Regardless of what medium we use, our goal stays the same, sharing our knowledge effectively. The key thing to keep in mind is that the primary user of a codebase is a human, not a machine. So, we need to pay attention to how human perceives things. For example, abstraction is what our minds are comfortable with and how they make sense of the world around us, so we use it in our software design. Another example, our minds are not good when dealing with lots of details, so we hide the unnecessary details in the form of encapsulation.

Knowing that writing an understandable code is the goal has helped me to better understand design principles, programming best practices, and design ideas. For instance, for so many years, I couldn't understand the benefits of OOP. I used to ask myself, "what's the point of designing a class if I'm ever going to create a single instance of it?" To me, a class was a way of reusing code, not a form of organizing code and making it more understandable. Having this knowledge, when I face a new design idea now, I approach it from the perspective of "in what way this idea can make the code more understandable?". This way, I can learn that idea easier and utilize it better.

Although our goal is to write an understandable code most of the time, sometimes other goals get higher priority. For instance, we may need to improve runtime performance, and that might force the code to be less readable. In this case, it's ok to sacrifice the readability because we are making this decision informatively.

We should also consider other factors before any attempt to make the code more understandable because it can be costly sometimes. Factors like how much time and resources we have to write the code, how important it is compared to the rest of the codebase, or how long this code will be in use. Improving the code quality can be wasteful if done blindly.