We write the acceptance criteria before we write code. By following the Red-Green-Refactor loop we write code that is easy to change and maintain. Continuous delivery requires a quick quality feedback, which is accomplished by automated test runs. Shorter feedback times lowers risk. Integration tests cover happy path scenarios and known bugs, edge cases are checked in faster tests.
Using open source components instead of closed source enables us to contribute with improvements and handle bugs rapidly without a delaying third party. Make sure that included open source components allows commercial usage and are approved by the CTO or technical lead.
Code is not only be understandable by computers. We are able to read code written by all developers. The boy scout rule is applied, and changing code and variable names to the better is always a good practice. Rather keep a large amount of small classes with well defined functions than a small amount of large classes.
The code, not the comments, describes the intent of the author. If you cannot describe the intent well enough, grab a colleague! Avoid comments as they mostly are thoughts not communicated in code. To make code even easier to change we avoid having tight coupling between different areas.
Pair programming, mob programming or just a small chat by the coffee machine. Working together means that we should leverage each other and use all competence available in the company to deliver great products.
We write code that is secure. Users must not access information they are not entitled to. We are always cautious with user input to avoid known attacks. Awareness of the OWASP top 10 is highly recommended.
We strive for making better things every day. Read blogs, books, and code to keep up to date. Always continue work to write code that is easier to change.