Tom's First Law: Code Readability is the Key to Long-term Software Quality
Setting aside correctness of functionality (which should be addressed with as much automated testing as possible), I consider "good code" to be code that is easily understood by others. Good code naturally gives rise to quality products, so... if you want to build a quality product, write code that others can understand.Remember, 6 months from now, you'll be a different person. So "others" technically includes you, the original author, not just beings who inhabit other bodies. Speaking from experience, there are few things more frustrating than looking at code you yourself wrote and not being able to understand how it works.
There are at least two very good reasons why mindful code writing leads to quality products in the long term.
First, unless you live alone on an island without Internet access (in which case you won't be reading this anyway) then someone else, at some time, is going to look at and modify your code. A co-worker, a QA engineer, a professor... your eventual replacement if you write lousy code... somebody else is going to work with your code. Not only will you make their lives better by making it easy for them to understand your code, but you will help them avoid creating new bugs due to misunderstandings about your code. That in turn frees them up to add new features or make other improvements, both of which make for better software.
The second but probably more important reason to keep your audience in mind while writing code is more subtle. Focusing on your future audience forces you to step back and think about the code differently. Bugs jump out at you when you try to see the code through someone else's eyes. You take fewer shortcuts when you assume someone else will look at the code, because you know they'll think you're a lazy SOB for taking those shortcuts. You add extra comments to explain things so that the funny smelling guy on the next floor doesn't come asking for explanations. The list goes on and on.
At an institutional level, this idea manifests itself as coding standards. Good coding standards can make a lot of things better, but the burden is still ultimately on you, the developer, to remember that the world doesn't revolve around you. Embrace that responsibility - your co-workers and your career will both thank you for it.
And most importantly, so will your customers.
By improving code readability, you improve maintainability. IMO 'maintainability' and overall 'long-term software quality' are not the same.
I think more important factor of (long-term) software quality is e.g. its simplicity. It means "don't reinvent the wheel", "don't repeat yourself", "you ain't gonna need it" and other funny tips like that.
I agree with your suggestions re: simplicity, but I think that all of those things ultimately make the code more readable, so... I stand by my theory.
I admit I made a mistake suggesting 3 tips, two of which also improve readability.
Therefore I'll now give you examples that improve code quality and does not relate to readability:
generally DRY principle - sometimes hurts readability, but can be very beneficial
Build require one step - special case of DRY
Generating code - not related to readability, but also an example of DRY
Using version control - example of "Don't reinvent the wheel"
Professional bug tracking - dtto
Using priority queue to implement user's requirements - (also) higher level than just source code
Improving security or Optimizing for speed - usually hurts readability, but can be crucial to improve quality
To precisely specify what I disagree on: I don't think readability is the key of quality. Maybe management or something higher level like that
DRY - Well architected code should still be made readable.
Generating code - Why the heck would you generate unreadable code?
Version control and bug tracking - I would agree that these are very, very, very important, but if you have these and your code isn't readable... well, best of luck to you. Knowing when/why changes were made and what's wrong with the product won't help you maintain it if the code is inscrutable.
Priority queues for requirements - Completely disagree. You can implement the wrong thing well, trust me.
Security - Not sure why security measures would necessarily make code unreadable, or why secure software can't be readable.
Speed optimizations - I wouldn't consider speed a measure of software quality. A necessary feature sometimes, but not necessarily a measure of quality. (Fast code is not necessarily good code, in other words.) I will agree though that optimizations can certainly obfuscate code.
I still think that DRY can be done readable but usually it hurts readability. But it doesn't really matter.