3 ms·
> Taking code review away, because we all know we're not going to sit around waiting for a review while a patch needs to go out urgently I worked at a trading
by mumblemumble 6y ago
> Taking code review away, because we all know we're not going to sit around waiting for a review while a patch needs to go out urgently
I worked at a trading firm where you could add a zero to that cost for a 3-hour outage, and I can tell you that the one thing we would absolutely never skimp on was code review. Because the cost of a bad "fix" that actually makes things worse has the potential to be greater still, and because humans are most likely to make silly mistakes when they're working under intense pressure.
What we would do instead is slightly intensify the code review process by pair programming the hotfix, and ensuring that a third developer who was familiar with the system in question was standing by to follow up with an immediate review.
- codemonkey-zeta 6y agoI really like that approach. It also takes pressure off the tech lead or whoever is implementing the fix, and transforms the patch into a full-team responsibility. I bet this sort of behavior makes for strong and effective teams.
- deleted 6y ago[deleted]
- allannienhuis 6y agoPair programming anything as urgent as a hotfix works really well. It takes some pressure off of the developer working on it and turns it into a team event. We will even sometimes keep the video call open until deployment is done and production validation is complete - the devops guys get the information they need, someone else is keeping an eye on the checklist and calling out items if necessary, etc.
- mumblemumble 6y agoOh yeah, absolutely. I was happiest when I also had the attending ops person looking over my shoulder while I worked on the fix.