I currently work with 20 other folks in Flurry spread across two locations. I’d like to keep this focussed on why I felt the need to have engineers answer a few standard questions before merging any code. We have a diverse set of junior and senior engineers on the team. People are coding away at features, bug fixes and debugging ad hoc prod issues at any given time. Key thing I’ve been noticing more recently is that people are not conscious of the impact of their changes beyond their small realm of things. This has ripple effects on the entire team engineering wise and culturally. Every line item that says build x, ends up being build x and fix y.
Take an example. Lets say Bob creates a PR. The PR is a bug fix and another engineer on the team reviewed it. Bob worked on deploying the fix on the same day to prod. All is well. A day later, on-call gets pages saying we are sending 25% more events downstream. On-call has no clue why that could be and starts looking into the issue. Bob is asked if there could be something that could have caused this. He first instinctive answer is no. But few mins later realizes that his PR could have caused this since the downstream system depends on a flag he changed to decide yay/nay to send more events.
So this bug fix now ends up affecting multiple people. It has paged an on-call who was never involved in the code review process. On-call had to spend some time tracing the issue. Bob overlooked the impact of this code and failed to notify on-call.
The more such scenarios play out, the more it wears out the team. There is more wasted on-call work that could have been better spent on building something else. On-call is worn out when they are paged late at night. Additional time now needs to be allocated to verify if the issue is what we think it is. Managers now have to scramble to find resources to meet deadlines. Debugging in our current setup takes several hours esp. for data quality issues. With more time spent on such issues, engineers don’t feel satisfied leading to cultural issues.
As a result, I created a pull request template for engineers to consciously answer a few questions when creating pull requests. I hope this simple barrier makes us more conscious of the changes that go in and saves everyone a lot of time.
What do you do when this happens on your team?
Here is the pull request template I used - template . I certainly saw other sources online before ending up with what I liked.