3 ms·

It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting. If the

It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting. If the discussion can add more value than those costs, then go for it.

criddell 9y ago
We did stand-ups at my previous employer and for some reason they happened early in the morning. That's my most productive time. I always thought we should move them to after lunch or maybe later in the day. In that office, productivity and energy definitely dropped as the day wore on and it seemed foolish to spend some of the best time in discussions.
- mixmastamyk 9y ago
  I had the opposite problem, but it was a morning problem also. First thing in the morning, I am very foggy, and remember very little from yesterday. It is not until I've worked for an hour or two that everything comes back. Paged in from disk, so to speak. So I often had to make things up on the spot to sound busy when I had no idea what happened yesterday at the crack of dawn. What a waste of energy.
onion2k 9y ago
That can be mitigated somewhat by having the stand up meeting first thing before people have started other tasks, but really that rarely works if people are interested in their work enough to get to the office early. You just have to take the hit, and readily accept that people will skip the meeting if they're deep in to something else.
- curun1r 9y ago
  The other time to hold it is just before lunchtime. This has the dual benefit of encouraging people to be brief (hunger is a powerful motivator ;-) and breaking at a time when people would have to break anyways. I also like holding it midday rather than the very start or end of the day because those times encourage staying late or coming in early to resolve an issue before standup. Lunchtime is also usually a time when everyone (apart from remote team members) is in the office no matter what schedule they keep.
BeetleB 9y ago
>It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting. Sorry - same thing. When GP is talking about "loss of time", he's not referring to "Oh, I lost X minutes of my life I'll never get back!" He's talking about lost productivity, just as you are. And if a simple 5-15 minute meeting once a day saps your productivity so much, then what the GP is saying does apply to you: That you feel your job is just to sit on the computer and do software development. And if you can't organize your work around that 5-15 minute meeting, you have other problems. You never take breaks during the day? This is just another "break", except it has a prescribed time. Plan around it! This isn't a "surprise interrupt" that occurs while you are working. It's not an interrupt, any more than your sleep is, or eating lunch is. It's a predefined part of your job. Sorry, I'm not even saying standups are good. I'm not an advocate for them. But this attitude is silly. If you are not getting value from the standup, improve the standup! Don't complain about context switching.
- couchand 9y ago
  Context switching isn't free, so you shouldn't pretend like it is. You mention lunch, but that's a facile comparison: humans need calories, and if a person is in a flow they can take lunch solo and continue the thought process. We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
  - BeetleB 9y ago
    >and if a person is in a flow they can take lunch solo and continue the thought process. And my question is: If you know there is a scheduled meeting at a given time, why are you trying to get in flow around that time? Sorry, that's just poor planning. >We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either. No one's disagreeing with you there. No one is saying you should randomly take up lots and lots of meetings. But I'd be worried if a developer - whether a colleague or one under me - said that a 15 minute meeting at a predefined time once a day is significantly impacting his productivity. That's usually a sign of him trying to solve the wrong problem - or a sign that he is not thinking the problem through. I wish I could find the quote, but there's a famous quote from a SW manager saying that it's often cheaper for him to pay people not to code than it is to let them code a lot. Someone who is coding all the time (unless it is boilerplate work) is creating a lot of technical debt. Unless it is a cutthroat market, he should not be doing that. If I were a manager, I would rather my SW developers: 1. Spend more time talking to the customer and refining their requirements (yes, I advocate more meetings than most people like) (part of solving the "right" problem). 2. Spend more time improving the infrastructure (automated builds, whatever). 3. Spend more time writing documentation. I could keep adding to the list. If they are spending the majority of their time in "flow" mode, they are doing too little of the above, and in the long run, creating headaches for many people. Frankly, writing code is a last resort. Almost all our code is to solve a problem, and a lot of code is an attempt to solve a social problem using technology. If my developer can solve the original problem without writing code, he deserves a bonus - not the guy who came up with a fantastic algorithm to solve it. I'll grant there are niche roles where it is really beneficial to be in flow mode most of the day. But over 90% of the folks who want to be in that mode are not occupying one of those niche roles.

criddell 9y ago

We did stand-ups at my previous employer and for some reason they happened early in the morning. That's my most productive time. I always thought we should move them to after lunch or maybe later in the day. In that office, productivity and energy definitely dropped as the day wore on and it seemed foolish to spend some of the best time in discussions.

mixmastamyk 9y ago
I had the opposite problem, but it was a morning problem also. First thing in the morning, I am very foggy, and remember very little from yesterday. It is not until I've worked for an hour or two that everything comes back. Paged in from disk, so to speak. So I often had to make things up on the spot to sound busy when I had no idea what happened yesterday at the crack of dawn. What a waste of energy.

onion2k 9y ago

That can be mitigated somewhat by having the stand up meeting first thing before people have started other tasks, but really that rarely works if people are interested in their work enough to get to the office early. You just have to take the hit, and readily accept that people will skip the meeting if they're deep in to something else.

curun1r 9y ago
The other time to hold it is just before lunchtime. This has the dual benefit of encouraging people to be brief (hunger is a powerful motivator ;-) and breaking at a time when people would have to break anyways. I also like holding it midday rather than the very start or end of the day because those times encourage staying late or coming in early to resolve an issue before standup. Lunchtime is also usually a time when everyone (apart from remote team members) is in the office no matter what schedule they keep.

BeetleB 9y ago

>It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting. Sorry - same thing. When GP is talking about "loss of time", he's not referring to "Oh, I lost X minutes of my life I'll never get back!" He's talking about lost productivity, just as you are. And if a simple 5-15 minute meeting once a day saps your productivity so much, then what the GP is saying does apply to you: That you feel your job is just to sit on the computer and do software development. And if you can't organize your work around that 5-15 minute meeting, you have other problems. You never take breaks during the day? This is just another "break", except it has a prescribed time. Plan around it! This isn't a "surprise interrupt" that occurs while you are working. It's not an interrupt, any more than your sleep is, or eating lunch is. It's a predefined part of your job. Sorry, I'm not even saying standups are good. I'm not an advocate for them. But this attitude is silly. If you are not getting value from the standup, improve the standup! Don't complain about context switching.

couchand 9y ago
Context switching isn't free, so you shouldn't pretend like it is. You mention lunch, but that's a facile comparison: humans need calories, and if a person is in a flow they can take lunch solo and continue the thought process. We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
- BeetleB 9y ago
  >and if a person is in a flow they can take lunch solo and continue the thought process. And my question is: If you know there is a scheduled meeting at a given time, why are you trying to get in flow around that time? Sorry, that's just poor planning. >We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either. No one's disagreeing with you there. No one is saying you should randomly take up lots and lots of meetings. But I'd be worried if a developer - whether a colleague or one under me - said that a 15 minute meeting at a predefined time once a day is significantly impacting his productivity. That's usually a sign of him trying to solve the wrong problem - or a sign that he is not thinking the problem through. I wish I could find the quote, but there's a famous quote from a SW manager saying that it's often cheaper for him to pay people not to code than it is to let them code a lot. Someone who is coding all the time (unless it is boilerplate work) is creating a lot of technical debt. Unless it is a cutthroat market, he should not be doing that. If I were a manager, I would rather my SW developers: 1. Spend more time talking to the customer and refining their requirements (yes, I advocate more meetings than most people like) (part of solving the "right" problem). 2. Spend more time improving the infrastructure (automated builds, whatever). 3. Spend more time writing documentation. I could keep adding to the list. If they are spending the majority of their time in "flow" mode, they are doing too little of the above, and in the long run, creating headaches for many people. Frankly, writing code is a last resort. Almost all our code is to solve a problem, and a lot of code is an attempt to solve a social problem using technology. If my developer can solve the original problem without writing code, he deserves a bonus - not the guy who came up with a fantastic algorithm to solve it. I'll grant there are niche roles where it is really beneficial to be in flow mode most of the day. But over 90% of the folks who want to be in that mode are not occupying one of those niche roles.