Well written software should be easy to use, test, maintain and understand. There are lots of software design principles and best practices that aim to help us achieve these goals (see Uncle Bob for great coverage of Object Oriented principles).
While all of these design principles and practices will certainly help you to write better software there are lots of them to learn, and lots to remember. When you actually sit down to write some code and you're under pressure to get it finished as soon as possible some of the best practices can go by the way side.
Here are three acronyms that are simple to remember and will almost certainly help you to write better software. So whether you're writing a small function, a class or a large module spare a few minutes to think about these acronyms and hopefully your software should end up being easier to use, test, maintain and understand as a result:
Don't Repeat Yourself - The DRY principle is about not repeating any logic or knowledge throughout your software, it's about removing duplication. At the very least this means that repeated code should be moved into a function or class - no copy and paste! Taken to an extreme it means even things like a database schema and database interaction code should be generated from a single source. In their book The Pragmatic ProgrammerAndy Hunt and Dave Thomas recommend the use of code generators to help remove all duplication from a project.
With no duplication software becomes much easier to maintain. If something needs to be changed you know you'll only need to change it in once place. It should also be easier to understand and test as a result.
Keep It Simple and Stupid - The KISS principle is about avoiding needless complexity, and keeping things as simple as possible. This doesn't apply just to code, it can also apply to features. As 37Signals say in their free book Getting Real, which contains lots of suggestions for maximizing simplicity:
"The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that's alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it's worth five times the effort to solve it."
Almost by definition simpler software should be easier to use, test, maintain and understand - so don't forget KISS!
You Ain't Gonna Need It - YAGNI is about not writing code now for things that you think you might need in the future, because the chances are that you won't, and even if you do the software you write now will likely be less than ideal for what you actually need in the future.
As a Software Engineer it's easy to get carried away and think about generalized solutions to the problem you're working on, or other ways in which your code can be used. This isn't necessarily bad, and thinking about these issues can certainly aid maintainability and software reuse. The point of YAGNI though is that we shouldn't actually write the code until we need it. Otherwise we have to maintain code that may never be used, and the time could better spent on other things.