I didn't read through this entire page, but I saw a lot of debating about how overtime affects one's effectiveness as a programmer. Obviously, the more you work while tired, the more mistakes you make, and eventually you reach a point of negative contribution. I would like to point out another, indirect, but important, effect of overtime. My apologies if this has already come up.
The last time I worked substantial overtime was in 2000: about 215 hours in five months. That might not sound like much to some of you, but that included one 96-hour, 6-day stretch.:) At any rate, although I certainly experienced the effects of programming while tired -- I had to go more slowly to avoid making quite so many mistakes -- there was a greater problem brewing. I began to feel entirely unappreciated, and worse, I began to see the effects of this overtime on those around me.
Have you ever seen the film Metropolis?
In the opening scene, we see the workers performing an actual "Death March". It's the same thing I see people do in the mornings in subway tunnels and staircases: they more or less stumble up the stairs in this eerie rhythm.
That is what despair looks like.
So when I see everyone around me droning on, working excessive hours, I begin to feel less human and more like cattle. I find it difficult to enjoy building software if those are the conditions under which I am forced to do it, so I lose interest in my job, my career -- what was once my passion.
I think that's a stronger and more diabolical effect of excessive overtime on programmers. They might just stop doing it; they might not see the point in giving that much of themselves, only to have employees say, "Thanks. Now work more." No amount of money is worth it.
The book Lean Software Development (Poppendiecks) provides some of the theoretical underpinnings of Agile Development, including XP. As more people read this book, XP/Agile begins to sound less crazy.
I'm not sure Control Theory courses are required to see the connection, though. Just read Slack.
I really hate these books that attempt to codify management processes in some kind of all-encompassing, one-size-fits-all way.
1. Author describes a process that has been successful in a number of situations. 2. Author presents his description with (natural) enthusiasm for its effectiveness.
I just don't see how this necessarily translates to "all-encompassing, one-size-fits-all." It can, but I don't think it has here, with this book.
Other than as a way to make money for the authors, I just don't see any real sustainable benefit ever coming out of these books.
Have you ever written a technical book in this field? Do you think these authors get rich from their book royalties?! We wish.
Slashdot Mirror
I didn't read through this entire page, but I saw a lot of debating about how overtime affects one's effectiveness as a programmer. Obviously, the more you work while tired, the more mistakes you make, and eventually you reach a point of negative contribution. I would like to point out another, indirect, but important, effect of overtime. My apologies if this has already come up.
:) At any rate, although I certainly experienced the effects of programming while tired -- I had to go more slowly to avoid making quite so many mistakes -- there was a greater problem brewing. I began to feel entirely unappreciated, and worse, I began to see the effects of this overtime on those around me.
The last time I worked substantial overtime was in 2000: about 215 hours in five months. That might not sound like much to some of you, but that included one 96-hour, 6-day stretch.
Have you ever seen the film Metropolis?
In the opening scene, we see the workers performing an actual "Death March". It's the same thing I see people do in the mornings in subway tunnels and staircases: they more or less stumble up the stairs in this eerie rhythm.
That is what despair looks like.
So when I see everyone around me droning on, working excessive hours, I begin to feel less human and more like cattle. I find it difficult to enjoy building software if those are the conditions under which I am forced to do it, so I lose interest in my job, my career -- what was once my passion.
I think that's a stronger and more diabolical effect of excessive overtime on programmers. They might just stop doing it; they might not see the point in giving that much of themselves, only to have employees say, "Thanks. Now work more." No amount of money is worth it.
The book Lean Software Development (Poppendiecks) provides some of the theoretical underpinnings of Agile Development, including XP. As more people read this book, XP/Agile begins to sound less crazy.
I'm not sure Control Theory courses are required to see the connection, though. Just read Slack.
I really hate these books that attempt to codify management processes in some kind of all-encompassing, one-size-fits-all way.
1. Author describes a process that has been successful in a number of situations.
2. Author presents his description with (natural) enthusiasm for its effectiveness.
I just don't see how this necessarily translates to "all-encompassing, one-size-fits-all." It can, but I don't think it has here, with this book.
Other than as a way to make money for the authors, I just don't see any real sustainable benefit ever coming out of these books.
Have you ever written a technical book in this field? Do you think these authors get rich from their book royalties?! We wish.