We question product requirements, code history, and learn the rationale behind decisions. We take ownership of the problems we solve and are open to trying new tools and patterns to solve new problems.
We understand the tradeoffs between quality, speed, and scope and prefer to ship quality code quickly by reducing scope. We understand the code paths and products that are business critical and never compromise on quality for those key areas.
We write tested code and are confident that the code we ship works as designed. We understand the consequences of the code that we write. We provide good context in our PRs for current reviewers and future curious minds. We vet external libraries that we add to our platform.
We break our changes into small understandable chunks. This allows us to ship more often, review code in more depth, better understand the inner workings of our code, and also minimizes the risk of shipping. Small changes allow for constant shipping.
We review others’ code frequently and diligently. We engage in thoughtful design discussions around small product changes. We share context effectively, by providing clear Pull Requests and commit messages, and documentation where necessary.
We don’t overbuild. We don’t know when or how customer requirements will change, so we push to release code quickly and then learn from customers.
We understand that not all tech debt can be resolved, but we strive to leave our code in a better state than we found it. Make the change easy, then make the easy change.
We can’t build a world-class product without focus. When available, we should integrate off-the-shelf solutions that can allow us to solve the most important problems elsewhere. Still, we are cognizant of the tradeoffs of outsourcing, and we seek to understand the code of OS solutions or API of hosted solutions before integrating them