5 ms·

Reviewing is switching gears as well. When you're coding you can't just jump into a code review mode for a moment. It's not a culture issue, this is IMHO inevit

by yason 11y ago

Reviewing is switching gears as well. When you're coding you can't just jump into a code review mode for a moment. It's not a culture issue, this is IMHO inevitable for any work environment that requires deep concentration and immersion into the work inside your head. So you'll want to batch the reviews somehow, based on your schedule. On the other hand, as a programmer, you don't want to be blocked by code reviews. So you'll want to finish a somewhat self-contained set of changes, push them out for a review, and continue on top of those locally. If the reviews suggest new modifications, you'll do those and rebase your local new work on top of those. It doesn't matter that much how the changes are reviewed as long as it's not blocking work. There should be an emergency vent for the cases when unreviewed changes do block significant other changes.

todorus 11y ago
I've made the same argument about the need for a programmer to not be disturbed. A colleague of mine has eloquently compared it to juggling: you start with one ball, add another and it gets complex over time. Disturb him and he starts over with one ball. In my experience as a programmer I've grown to think that this argument only holds partial value. An observation that helped in this, is that programmers hate to be disturbed, but can always manage to be on time for lunch or beers on friday (it's a dutch corperate tradition to drink a few beers after the workday on friday). I find myself, and others, to be capable of reviewing a PR within an hour. I just need to be aware that when I'm done with a coherent unit of code, that I should switch to review mode and check if there are outstanding PR's. To reuse the metaphor: I've stopped juggling and can choose which set of balls to pick up next. So I do think it is a cultural thing. You need to commit yourself to have reviewing be a part of the work process. I find IM services and PR's to cater perfectly to the way the usual programmer works. He can ignore the message while he's mentally keeping 5 balls in the air and look through his messages when he's ready to start his next activity of the day.
- deleted 11y ago
  [deleted]
- yason 11y ago
  Everyone is winding down during a Friday. After Friday noon, everyone is avoiding to start anything that will take hours. That's why they can leave the office. On the other hand, when we've had company parties at the office, I've seen people go back to programming after a couple of beers because they just had something on their mind that they need to finish. People can certainly review something within an hour or so, but only sometimes. If you just had another interruption your juggling balls are still on the table and you haven't picked them up yet. So this is when you can finish a code review ten minutes after someone requested it. But if the request came in a couple of hours later, you wouldn't be able to take a look at it until the next day. Culture can affect whether programmers are able to get long stretches at all. If they aren't, then they're obviously more available to short-term tasks such as code reviews. On the other hand, I know people who work best when left alone for days. There's no asking for a code review if the guy has been juggling since Wednesday because if you do he'll have to spend the next week as well working on the same task.
  - timr 11y ago
    "Everyone is winding down during a Friday. After Friday noon, everyone is avoiding to start anything that will take hours. That's why they can leave the office." Yeah, that's true...but it doesn't explain why programmers are almost never late for lunch. That's also been true, in my experience. And moreover, it's nearly universally true that the folks who complain the loudest about interruptions are the same ones who are johnny-on-the-spot for coffee-break, games, etc. In fact, a more cynical person might say that it's all about avoiding unwanted work. Ahem. Whether or not you believe me, the important point is that yes, it's a decision of culture: at some point, you establish a culture for your team. If that culture includes a maximum latency for code-reviews, then the people who don't like to do non-coding work for days at a time can go code in a cave somewhere else. People who can't be "interrupted" with reasonable non-coding communication activities tend not to be very good collaborators anyway, and probably aren't a good fit for a growing team.
    - ozim 11y ago
      For me doing code review is not just looking at diffs in git. Things that I can review by looking ad diffs are not worth reviewing. I have to at least checkout different branch, probably I have to change my configs (while stashing or saving copy of my current working context), rebuild solution to make code navigation works so I can at least navigate around. Now I start running variables and code paths in my mind which by changing context takes my cognitive load off my previous context. Going for lunch requires locking my computer, maybe taking some money. Then I eventually talk about stuff that is not heavy load just generic stuff.
- KuhlMensch 11y ago
  > I just need to be aware that when I'm done with a coherent unit of code, that I should switch to review mode and check if there are outstanding PR's This is exactly what I have ended up doing. I'm not always successful (perhaps because it is not always possible), but I've definitely improved my reactivity.

by yason 11y ago

todorus 11y ago

I've made the same argument about the need for a programmer to not be disturbed. A colleague of mine has eloquently compared it to juggling: you start with one ball, add another and it gets complex over time. Disturb him and he starts over with one ball. In my experience as a programmer I've grown to think that this argument only holds partial value. An observation that helped in this, is that programmers hate to be disturbed, but can always manage to be on time for lunch or beers on friday (it's a dutch corperate tradition to drink a few beers after the workday on friday). I find myself, and others, to be capable of reviewing a PR within an hour. I just need to be aware that when I'm done with a coherent unit of code, that I should switch to review mode and check if there are outstanding PR's. To reuse the metaphor: I've stopped juggling and can choose which set of balls to pick up next. So I do think it is a cultural thing. You need to commit yourself to have reviewing be a part of the work process. I find IM services and PR's to cater perfectly to the way the usual programmer works. He can ignore the message while he's mentally keeping 5 balls in the air and look through his messages when he's ready to start his next activity of the day.

deleted 11y ago
[deleted]
yason 11y ago
Everyone is winding down during a Friday. After Friday noon, everyone is avoiding to start anything that will take hours. That's why they can leave the office. On the other hand, when we've had company parties at the office, I've seen people go back to programming after a couple of beers because they just had something on their mind that they need to finish. People can certainly review something within an hour or so, but only sometimes. If you just had another interruption your juggling balls are still on the table and you haven't picked them up yet. So this is when you can finish a code review ten minutes after someone requested it. But if the request came in a couple of hours later, you wouldn't be able to take a look at it until the next day. Culture can affect whether programmers are able to get long stretches at all. If they aren't, then they're obviously more available to short-term tasks such as code reviews. On the other hand, I know people who work best when left alone for days. There's no asking for a code review if the guy has been juggling since Wednesday because if you do he'll have to spend the next week as well working on the same task.
- timr 11y ago
  "Everyone is winding down during a Friday. After Friday noon, everyone is avoiding to start anything that will take hours. That's why they can leave the office." Yeah, that's true...but it doesn't explain why programmers are almost never late for lunch. That's also been true, in my experience. And moreover, it's nearly universally true that the folks who complain the loudest about interruptions are the same ones who are johnny-on-the-spot for coffee-break, games, etc. In fact, a more cynical person might say that it's all about avoiding unwanted work. Ahem. Whether or not you believe me, the important point is that yes, it's a decision of culture: at some point, you establish a culture for your team. If that culture includes a maximum latency for code-reviews, then the people who don't like to do non-coding work for days at a time can go code in a cave somewhere else. People who can't be "interrupted" with reasonable non-coding communication activities tend not to be very good collaborators anyway, and probably aren't a good fit for a growing team.
  - ozim 11y ago
    For me doing code review is not just looking at diffs in git. Things that I can review by looking ad diffs are not worth reviewing. I have to at least checkout different branch, probably I have to change my configs (while stashing or saving copy of my current working context), rebuild solution to make code navigation works so I can at least navigate around. Now I start running variables and code paths in my mind which by changing context takes my cognitive load off my previous context. Going for lunch requires locking my computer, maybe taking some money. Then I eventually talk about stuff that is not heavy load just generic stuff.
KuhlMensch 11y ago
> I just need to be aware that when I'm done with a coherent unit of code, that I should switch to review mode and check if there are outstanding PR's This is exactly what I have ended up doing. I'm not always successful (perhaps because it is not always possible), but I've definitely improved my reactivity.