Name your functions and variables well

• Function naming is the manifestation of problem definition, which is frankly the hardest part of programming.
• Names are the boundary conditions on your code…Names are what you should be solving for. If you name correctly and then solve for the boundary conditions that that name creates, you will almost inevitably be left with highly functional code.
• A good function promises what it will deliver and then delivers it. Good function and variable naming makes code more readable and tightens the thousands of contracts which criss-cross your codebase. Sloppy naming means sloppy contracts, bugs, and even sloppier contracts built on top of them.

Learn to detect the smell of bad code

• An important part of your improvement arsenal is your ability to detect bad code – even when it’s only slightly bad or perhaps “a bit smelly”.
• It’s not an easy thing to do but over the years you should learn what bad code smells like and also what beautiful code looks like. Physicists and mathematicians understand this. They feel very uneasy about an ugly theory based on its ugliness. Simplicity is beautiful and simplicity is what we want.
• It may be that you’ve used 60 lines of code for something which feels fundamentally simpler, it might be something which feels like it should be handled by the language but has been manually implemented instead, it might just be code that is as complicated as hell to read. These are your code smells.

Write code to be read

• [Code] will be written just once by you and you alone. However it will be read and edited many many times, by many others.
• Your code has two functions: the first is its immediate job. The second is to get out of the way of everyone who comes after you and it should therefore always be optimised for readability and resilience.
• Write every line to be read through the eyes of a disinterested and time-pressured team mate needing to extend it in a year’s time. Remember that that disinterested and pressured team mate may be you.

Do actual work for at least (only) four hours every day

• Do proper work for at least four solid hours each day, every day and you will be one the best contributing members of your team.
• Software teams don’t slow down because people work four pure hours a day rather than seven (which is insanely hard to do consistently by the way). They slow down because people spend weeks with no direction, or because the louder and emptier vessels dedicate their paid time to discussing Google v. Facebook’s acquisition strategies over endless extended coffee breaks.