We care about code quality up to a baseline, but only because that contributes to the getting shit done part. The baseline may vary depending on how experiment

We care about code quality up to a baseline, but only because that contributes to the getting shit done part. The baseline may vary depending on how experimental the feature is (proofs of concept are written to be rewritten; upgrades of existing major and heavily used components are written with the long term in mind) and how business critical it is (we put a lot more time and effort into e-commerce related code than into "share this listing on twitter" code). As our codebase and feature set stabilize, and as the drag of tech debt has become more obvious, things like automated testing have transitioned from being discouraged to optional to encouraged and now required for significant new development. We don't enforce code coverage standards, but our team is now fully on board with the idea that tests help us move faster with higher quality. In short, be pragmatic. Quality and speed are always a balance, and the right balance depends on company and development stage as well as the particular piece of code you're working on.