Code is maintainable if you have, in some way, document the LOGIC you are using. It can be in comments, a separate text file, hand-written on paper, whatever. For every set of variables you use, you must document, in very few words, what the variable is supposed to go through in its life, in how many ways can it be initialized, where, when and by what code its supposed to change etc.
Another sign of good code is one that use as much less state as it can. This can be achieved by using lots of static methods, so that its ensured that they don't use any state/field.
Another sign is to have related code gathered at one place. Its too hard to maintain in practise a class that uses single-responsibility principle because of proliferation of lots of small cases. Your class can have many responsibilities if they are related and each has its own method.
Another sign is consistency. Every code has a convention: are you using stored procedures, if yes, do they do anything more than dml, i.e. do they have any logic (loops, conditions) in it? are you using triggers, cursors, bridge-tables vs parent-child relations etc? Whatever you do, be consistent. Don't sacrifice architectural consistency for fast development. When write new code, first go to any approach that works, then do some little tweaking for obvious edge cases, then do a little tweaking for some performance, then do a lot of refactoring till it follow the same architectural principles as the rest of your code.