A software engineering professor of mine in the '80s used to harp on providing enough inline documentation and using meaningful variable names to ensure that a reasonably logical person (potentially without any computer science background) could read our code and understand: 1) what problem we were trying to solve, and 2) how we were solving it (potentially including why we chose to solve it that way or not to solve it another way). I later revised the criteria down (sadly, in some cases up) to a relatively intelligent nine-year old. Every time I was able to meet that criteria, I ended up with code that I knew I could pick up in six months and maintain without having to retrace steps and reinvent.
Much of programming is problem solving, which is what attracts many of us to it in the first place. When well written, the fact that we can compile and run our solution is almost incidental. Although, it does pay the bills...
Another benefit I've noticed is that when I try to make the code clearer, I often find ways to refactor it or notice logical inconsistencies that weren't obvious before. When I'm really, really lucky I start finding sections of code I can eliminate entirely.
Sadly, many of my colleagues either are too unmotivated or have been seduced by what they understand of best practices to focus on making their code more readable. Some of the excuses are laughable--I don't use long variable names because they take too long to type from someone that apparently doesn't understand that even Notepad allows you to search and replace.
As I get older and more bitter, I've begun to rail against all sorts of (perceived) idiocy: 'IF SomeBooleanVariable = FALSE' instead of 'IF NOT SomeBooleanVariable', several hundred line long routines, and can someone please tell me why 'gRC' is supposed to more meaningful than 'PageNotFound'.
The problem with many of the legacy programs I have to maintain isn't necessarily any of those or the host of other irritations swarming around them, but they have become a symptom and signpost of a disordered approach to solving a problem. Unfortunately, they spread from one program to another as they're copied as working examples simply because their inherent flaws haven't been exposed yet.
The point of software engineering (as opposed to pure coding) isn't to completely eliminate bugs. That's frequently either impossible or impractical. It's to make as many of the mistakes as early as possible in the development life cycle and learn from them how to isolate problems and leave enough clues when they happen that you can determine root causes.
Write your programs as if you were going to get called at 3:00am and needed to figure out what was going wrong and at least potentially how to fix it while your boss was waiting impatiently on the other end of the line. If you don't, one day you will be.