3 ms·
I'd question your definition of productivity. If reviewing PRs is part of your job, and you are doing it, but some measurement of your productivity is down, the
by codingdave 1y ago
I'd question your definition of productivity. If reviewing PRs is part of your job, and you are doing it, but some measurement of your productivity is down, then your measurements are wrong, not the code reviews.
I've seen teams try too hard to keep the seniors "productive", and they just end up with the juniors/mids bottlenecked because their code never gets reviewed. So if you measure productivity by overall flow of code through your process (think Kanban, not Scrum), you'll be able to resolve this conundrum.
- lenerdenator 1y agoI guess the problem I see with that is that the bigger "lifts" that we count on to carry out business strategy are typically carried out by the senior engineers, and reviewing PRs, while technically productive, delays those bigger lifts.
- codingdave 1y agoWhy wouldn't the senior break off smaller tasks within the "lift" and delegate those parts to juniors? Then reviewing those PRs is a productive part of the lift. Or, if you really cannot break down a task into smaller parts, have one senior take over more PR work while another does the lift.
- lenerdenator 1y agoRight now we're doing a lot of architectural stuff in the big lifts surrounding design patterns and stuff that perhaps junior devs might not understand as well. We're doing more of the latter suggestion, though that is coming with more "reviewer's burnout". We are trying to deal with it through smaller PRs, but then of course, you fall back to the problem of having more of them.