Separation of concerns - code is much easier to test and understand when everything is in the right place.

Keep behaviour with data - again makes the code easier to understand but also makes it easier to change later on as the code is in nice cohesive units.

Intention revealing methods - should be able to tell what the code does without having to go into the method to work it out. Makes browsing of code much quicker.

Compose Method - the best way to make code more readable from my experience. Helps keep methods short and easy to follow.

Keep it simple - don’t do something clever when something simple solves the same problem. Easier said than done.

Avoid debugger - the debugger is invaluable when tracing through 3rd party code but with our own code we should test it well enough that we don’t need to use the debugger often. Ideas like the Saff Squeeze can help achieve this.

Short feedback loops - keeping the steps as small as possible whatever we are doing is vital for making progress I’ve found. Every time I try to be clever and do two things in one step it ends up taking much more time than taking small steps would have done.

Always test first - I wrote last week about the pain of testing last and writing code without having a test to verify whether what you’ve done actually works is something I find very difficult. Code without tests to tell us whether it actually does what we want it to is a disaster waiting to happen in my book.

Understand how it fits together - Understanding how different parts of a design fit together is important for knowing how to solve any problems that pop up and also useful for understanding the big picture and why certain decisions were made.

Learning by teaching - I’ve found this is the most effective method for knowing whether you truly understand something or not. Having to explain it to someone else requires you to not only understand something but be able to articulate it in a way that someone else can understand.