Readability

Make sure code written is natural to read (i.e. how easy does it convey meaning). I am an idealist when it comes to programming and believe that the code should tell a story (i.e. describes an accurate sub-set of the real world). Anybody can write code and get it to work. A great programmer writes code that is easy to understand for humans.

Correctness is Key

I should guarantee with enough certainty that the code I write achieves what it was set out to do. You would be hard pressed to find any code that can be attributed to me (“allegedly”) that has not been fully tested. There is a beautiful concept in computer science called provability. It is very difficult to verify that a modern program is correct. However, testing can prove to a reliable enough degree that your code works as intended. A disciplined method of programming should give more confidence in the code you are writing. We should run test cases not to look for bugs, but to increase our confidence in a program we are quite sure is correct. Being a good programmer is knowing your code works before your interpreter does.

Keep it Simple

According to the agile approach, a system should be built incrementally over time. A Silicon Valley adage that leaps to mind is that you should strive to fail quickly. It is crucial that we train our brains to focus solely on addressing problems that are important in the short term. We must not lose sight of the forest for the trees. A general rule of thumb is to keep your solution simple enough to rationalise. If you're having trouble communicating your solution to someone else, it's probably because it's too complicated. When dealing with complex problems, you should always start with the basics. Try to break a problem down into smaller chunks. If we can first solve these sub-problems, then we can develop more systematic ways of understanding the solution. If we combine enough of these solutions into one application, we form a complex structure.

Optimisation

Performance is last (Pardon the pun), and it is last for good reason. An overfocus on performance initially can interfere with the natural process of development. You spend stupendous amount of time worrying about things that are unlikely to happen and start theorising before you have implemented any real code. This is akin to walking before you crawl. If you are working on a real-world problem and are having difficulty by the problem's complexity, then dealing with performance will only add to your woes. If you have ever written a complicated SQL query you would understand this feeling o too well. Donald Kruth once famously said “Premature Optimization Is the Root of All Evil”. Performance still remains essential in the real-world. The weighting it should be given should be determined on a case-by-case basis. A service that needs to be called multiple times per second needs to be more performant than a service that runs a periodic batch job at the end of each day. Low-level code optimisation in particular has now becomes a trivial pursuit. For instance, having a static string dictionary (i.e. avoiding the use of the heap/stack) that you reference during the application’s runtime (instead of initialising new strings) will yield negligible performance gains. Compilers have become much better at making optimisations in real time and modern hardware is a lot more performant. The majority of significant performance gains can now be made at the network level. How the application is configured within the servlet container and how many network hops are required to process a message are some of the performance-related questions that need to be addressed when it comes to optimisation.