In 11 years as a software engineer, not once have I reviewed a pull request. I jump on them quickly, check how long they are, and wait an appropriate length of time before waving them through. If there's a bug I'm sure it'll be caught in testing, and it's nice to unblock people.
@fesshole This explains a great deal.
@fesshole
Very obvious rage bait, and given the number of comments, I would say a successful one.
@fesshole Code reviews are not for finding bugs. 🤡
@fesshole big “I pee on the toilet seat” energy here.
@fesshole ~Amateur. Every third PR should have an easily addressed nitpicky comment on it, to make it look like you're actually paying attention.~
@fesshole bug caught in / units of work to fix:
Development / 1
Code Review / 2
Dev Testing / 4
UAT / 8
Production / 16
EDIT: bug fixed (typo).
@fesshole Truly the most evil fess on here.
*clicks approve, merges*
@fesshole so you're missing opportunity to not just check the work of your team, you're also missing learning from them or teaching them anything you've learned in your 11 years.
Congrats on missing one of the major points of code review.
@fesshole Did the same for a small, non-critical, well insulated, portion of our codebase because a junior dev was clearly getting frustrated with my reviews. Worked great until I became sole maintainer of that code 😞 I got what I deserved.