• Make the API modular so it is easy to separate experimental pieces from stable ones. Also, make it extensible.
• Use the same style and conventions for each class. Document those conventions and impose them as a required standard for contributors.
• Grow your API by layering new APIs on top of it. Avoid exceeding the current one’s scope.
• Minimize the visible surface area of the API.
• Keep your API portable across OSes and don’t let system concepts leak into it.

Full post here, 4 mins read

• Even if you have continuous deployment, Fridays are the worst day to push to master. You only get half a day to fix bugs.
• Keep a couple of backups (for redundancy) of your database, cryptographic keys, configuration files, VM images, images and videos, even imported packages. Git is not enough.
• Wait for complete specs before you begin a build. Avoid assumptions and ask lots of questions, to pinpoint requirements as precisely as possible. Especially, probe corners and edge cases.
• Try to gently stop or prevent unproductive discussions. It is okay to ask for a longwinded discussion to be shelved for more productive work.

Full post here, 4 mins read

• Whittle down big tests into smaller, shorter ones.
• Don’t wait for the perfect tool, perfect use case, perfect resources. Just start with small automation.
• Smaller tests let you learn faster, contribute sooner, create forward momentum, and get more frequent feedback.
• Let teams focus on learning test automation first before you ask them to focus on complex business logic.
• Automate in small sprints so you can gauge progress, iterate and gather feedback on them from testers, developers and product owners.

Full post here, 5 mins read