Mastering the holy grail of programming: What makes a good coder

1. Know the language you are working with. Read manuals. Read all the stuff you can about it. Learn the language inside and out. Doubt what you read, make experiments. This is important: To really learn, you need to test and experiment for yourself. Make up your own mind.
2. Check parameters in every function. Learn defensive programming. Make sure your code is solid, in the sense that it is  almost impossible to use incorrectly, it is impossible to break.
3. Learn best practices. This is different than mere manuals, because manuals have all the important information, everything you can do with the language, but they don’t distinguish between: “this is a good practice” and “this is going to be bring you problems down the road.”
4. Learn design patterns. The idea of design patterns is to make your code more dynamic, in the sense that changing requirements can be accepted. See GoF design patterns. If you have time also read the anti patterns.
5. Learn object orientation. It is a way to order your code, not a way to “model the world”—that is the wrong approach. You need written requirements and work from there. A design is comprised of design decisions. Number requirements. For every requirement there must be at least one design decision that at least conceptually solves the requirement. Create a prototypes for every design decision to show it works. Use source control to store prototypes.
6. Automated unit testing. Unit test everything. This is what makes the difference between wannabes and real programmers.
7. Learn make, ant, maven, gradle, or whatever tool you can use to make one step compilation.
8. Avoid memory leaks.
9. Avoid resource leaks.
10. Use issue trackers to store your backlog. That way you can always remember what is missing or how you solved things. If you are using Scrum, Kanban or XP, you can always copy issues from the issue tracker into sticky notes. You will end up doing it anyhow, because looking at a scrum board makes it so much easier to see what is missing.
11. Dry and not wet: dry = don’t repeat yourself, wet = write everything twice. No repeated code, period.
12. Methods no longer than 10 lines.
13. Classes contain no more than 10 methods and 3 instance variables.
14. According to Bertrand Meyer, when your design is too complex, you need more classes.
15. One responsibility per class, and only one class per responsibility. That responsibility should go in a comment at the beginning of said class.

Different languages have different rules and best practices. You should look for the best practices in the language you are using.