Yeah, I’ve been guilty of coming up with “cute” solutions that are extremely optimized and concise, but you needed to take a hundred times as long to work through what was going on.
Usually I would put an explanation comment, but sometimes a less optimized solution is the better option for readability sake.
I’m not saying it’s a good individual metric. In fact, applying individual metrics to developers (or most workers really), will only land you in Goodhart’s hell.
But as part of holistic operational health tracking, it’s a useful team level metric, as there is ample evidence that shorter PRs tend to result in less operational issues. And, of course, this is only valid if you don’t try to tie financial rewards to it, otherwise people will forget that PR size is a proxy measure for how easy changes are to review and rollback.
Then Devs focus on minifying the code into an unreadable mess
deleted by creator
Yeah, I’ve been guilty of coming up with “cute” solutions that are extremely optimized and concise, but you needed to take a hundred times as long to work through what was going on.
Usually I would put an explanation comment, but sometimes a less optimized solution is the better option for readability sake.
I’m not saying it’s a good individual metric. In fact, applying individual metrics to developers (or most workers really), will only land you in Goodhart’s hell.
But as part of holistic operational health tracking, it’s a useful team level metric, as there is ample evidence that shorter PRs tend to result in less operational issues. And, of course, this is only valid if you don’t try to tie financial rewards to it, otherwise people will forget that PR size is a proxy measure for how easy changes are to review and rollback.