Probably one of the scariest and most interesting paradigms I’ve picked up from working remote for years now is post-merge/commit reviews. You write code, revie

Probably one of the scariest and most interesting paradigms I’ve picked up from working remote for years now is post-merge/commit reviews. You write code, review it yourself, and then merge/deploy it. Sometime in the next 24 hours or so, someone wakes up and reviews your code. They have some tweaks for you that you then write up and deploy to prod when you wake up. Then you review their code and repeat the process. Writing code like this was stressful at first, what if I break something? The truth is, if I really did feel like I was going to break something, I would wait for a review before merging. Most of the time, I could review my own code. If I did break something, I could just revert it and write up a post-mortem so others on my team could learn from my mistake. When doing a post-commit review, the rules are a bit different. There’s no point in bike-shedding because the code is live. Instead you’re looking for missed edge-cases, typos, and smells. Then you kindly point them out, maybe discuss for a couple of hours and it gets fixed. It’s a huge change from a synchronous environment where you wouldn’t think of doing code like that…