4 ms·

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.

by 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.
- todorus 11y ago
  "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." I'm assuming here , but that sounds like people who appreciate a lot of structure in their working day. I can imagine them to respond very negatively to something as fluid as reviewing when they make the time. My experience is, that it's the type of personality of solid programmers with very, very high attention to low level detail. High level stuff on the other hand, like planning or architecture is not their forte. They need help from their team for that, maybe even let someone else make those decisions for them. I want those guys and gals on my team, though, as I'm more of a high level guy myself. Has your company tried to accommodate that type of personality, or do you weed them out during interviews or probation? I'd hate to see you guys miss out on that talent. I'd try setting a rule, like: first thing after standup and lunch is code review. This allows for structure and responsive code review. I'm interested in what you think about this, as you seem to have a strong opinion on the matter, backed by experience.
- goldbrick 11y ago
  Well don't you just sound like a charming guy to work for.
todorus 11y ago
"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." Good point. I do like to distinguish between tasks of an architectural level, or at an implementation level. An architecture task can take a few days, an implementation task can take an hour. I find myself to be able to think only on one level at a given time. Doing code review while in my lead and architectural position is very hard, as that is on an implementation level. I also feel the need to lock myself away from the team to "think technical thoughts" when I have an architectural task to complete. I usually plan a meeting before I start on such a task, where I can present the design and discuss it. It's the architectural equivalent of a code review. I do find it important to differentiate between the two types. Stories that are all about implementation can usually be split up into smaller tasks. A rule of thumb is that you should be able to finish a task a day. This keeps people from repeating the same things at a standup (the same story as yesterday) and organises tasks in small enough tasks, that you can do code review. A culture reflects how the company is structured and vice versa. Is this kind of stuff explicitly planned at your company, or do you guys use a more laissez-faire kind of approach and everybody seems to find their own way contribute to the whole?

by yason 11y ago

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.
todorus 11y ago
"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." I'm assuming here , but that sounds like people who appreciate a lot of structure in their working day. I can imagine them to respond very negatively to something as fluid as reviewing when they make the time. My experience is, that it's the type of personality of solid programmers with very, very high attention to low level detail. High level stuff on the other hand, like planning or architecture is not their forte. They need help from their team for that, maybe even let someone else make those decisions for them. I want those guys and gals on my team, though, as I'm more of a high level guy myself. Has your company tried to accommodate that type of personality, or do you weed them out during interviews or probation? I'd hate to see you guys miss out on that talent. I'd try setting a rule, like: first thing after standup and lunch is code review. This allows for structure and responsive code review. I'm interested in what you think about this, as you seem to have a strong opinion on the matter, backed by experience.
goldbrick 11y ago
Well don't you just sound like a charming guy to work for.

todorus 11y ago

"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." Good point. I do like to distinguish between tasks of an architectural level, or at an implementation level. An architecture task can take a few days, an implementation task can take an hour. I find myself to be able to think only on one level at a given time. Doing code review while in my lead and architectural position is very hard, as that is on an implementation level. I also feel the need to lock myself away from the team to "think technical thoughts" when I have an architectural task to complete. I usually plan a meeting before I start on such a task, where I can present the design and discuss it. It's the architectural equivalent of a code review. I do find it important to differentiate between the two types. Stories that are all about implementation can usually be split up into smaller tasks. A rule of thumb is that you should be able to finish a task a day. This keeps people from repeating the same things at a standup (the same story as yesterday) and organises tasks in small enough tasks, that you can do code review. A culture reflects how the company is structured and vice versa. Is this kind of stuff explicitly planned at your company, or do you guys use a more laissez-faire kind of approach and everybody seems to find their own way contribute to the whole?