Well, as the matter of fact, one of these people is a compiler specialist and the other one is the most senior technical person in his company. We all agree from personal experience that not doing more than that amount of work works the best in practice. We've been in this field 10-15 years, each.
I have personal experience that working about 30 hours a week works well. I am energetic, my thinking flows well and I get lots of stuff done. I have also worked myself to the ground by attempting to do more. That doesn't work and my experience has been mirrored by other experienced people who have tried.
If you still believe in measuring in this field, you have a long way to go. There's no good measure of amount X of work done in time Y, because it cannot really be compared w/other work unless you're doing basically the same exact thing twice. And we mostly don't.
The bottom line is that there's things we can't really measure effectively. I know that this drives the managers mad. However, I can only tell them what works and what doesn't. What does is that you remove all the obstacles from doing only the real work and minimize task switching. Then let the people do that for 30 effective hours a week. That how I'd basically run a software company. Of course there's more to it, but that's out of the scope of this discussion.
Above all, however, do not take my word for this. Go and find out yourself. Trial and error, adapt and improve.
It depends a lot on what you're working at. Sometimes it takes me a week to write those ten lines. It really depends on the context. It's rather different if you're adding buttons to a GUI or if you're optimizing a communications module.
We once had a bug that took several months to fix and there were three people working on it. Eventually we created a partial solutions, because no better could be done w/o replacing the hardware. It just wasn't doable.
I have to admit, though, that I was quite junior at the time and wouldn't waste more than a week or two on such a problem these days. We spent lots of time trying to solve something that wasn't solvable.
I've done that as well. I know two other senior programmers (who are very good) also working only 30 hours a week. What I've learned from this is that you shouldn't even try to work more than that. If you really have to stay at work more than this, it's best just to spend the time talking to people.
I guess part of the problem is that many managers haven't been doing serious programming in their career. They just don't get it, because their work is so vastly different. I also think that most managers are afraid of losing control if they let people do "whatever they want" even if it is what works best for all parties.
Some of them learn. Many don't. Many are new and haven't even had the chance to learn how it really goes. Sometimes it helps when they see that it works the way you say it does, sometimes that's not as important as seat time.
See, when a project is getting late the managers need to make sure it looks like they're doing whatever they can to catch up. This means people have to put in the extra hours even if it just makes the project even more late. So we're not really operating in a rational environment. That's one reason why rational arguments might not work.
Well put! The last time I had a really difficult problem I had to do that at least two or three times. Finally, I got it, wrote the code and unit tested it and was very happy about the result.
A couple of weeks later the customer pulled the feature.
Of course, some people are still working on it, because our organization doesn't respond to change very well.:-D
Well it depends. If it's good challenging hard, you can get into a great flow and get lots done. When it's getting really/too hard, you can't make much progress w/o letting your subconscious work on it.
In any case, doing even the former for an extended period you will probably end up w/days when you're not getting much done. That's when you need to just let your internal battery reload and not push it.
I've seen a lot of code that's crap because of the deadlines. And I've seen what crap code does to schedules in the long run. It's a recipe for a disaster, but nobody looks that far nowadays. Everybody's just concentrated on the current project deadline w/o thinking what this approach is doing to the productivity in the longer run. Sadly, in many places this cannot be helped. It's just business as usual.
To me it seems that the sustainable maximum of actual real work is about six hours a day. Anything beyond that and it starts to get uncomfortable and uncomfortable is bad in the long run. Also, I've noticed that the harder I work the less tolerance I have for just sitting around when I have nothing more to give.
And sure, it depends a lot on the tasks. The more routine they are the more you can do. If it's really new/hard stuff, four hours a day may be the maximum.
I believe that developers are most productive when working about 30 hours a week.
I used to smoke and very often I figured things out when I got up from my desk and went for a smoke. Another old regular was that I figured things out when I was walking home, about 300 meters along the way. Nowadays a common time is in the morning brushing my teeth. So there's a lot of stuff happening in the background and what's on the foreground may be distracting. I also often take the old pen and paper way when I really need to design something or when I need to figure out a hard problem. For some reason when the problems are really hard changing your approach can help.
You know, it doesn't hurt to have us adults around. Sometimes you can raise above the stupid comments and sometimes not. When you can't, just take a break and come back when and if you feel like it. I've been gone and back quite a few times already. These days I rarely get pissed off about stuff because I know that some of us just can't or won't bother to act like decent human beings. I come back despite these people because this is a good place to come to easily get an overview regarding what's going on in the tech world.
If you have good people that might work. If you don't, they won't synchronize w/one another adequately and end up wasting time that way. The regular work day is there so that people can talk to each other when they need to. I have waited for another developer to show up for 8 hours on a certain Monday. When he finally came, I had to leave. It doesn't really work too well if you have some people who come to work at 7 AM and other who come at 7 PM...
Different time zones and different cultures - they're surely a challange. I think these kinds of arrangements are often so difficult that they hardly make sense at all unless you can get the group to work in the same place for the first few sprints so that they can get to know each other before you split the team.
But we gotta work w/what we got... It's never optimal.
I can see where you're coming from, but let me point out a few things.
I've worked in a company where people could come and go as they pleased. This ended up in a total disaster, because not everyone acted like responsible adults. So there certainly are talented people out there who just can't deal w/too much freedom. It'll go into their heads.
Then there's another scenario where you don't have an all-stars team. You could let some of the people do as they please, but this might hurt the team as a whole.
And then there's the problem w/recruiting only the best. It's very easily said and very hard to do. There are a lot of people out there who have the technical skills but w/such a horrible attitude that they can't work w/other people. Or they cannot deal w/technical solutions other than their own and insist on rewriting the whole world. It is tricky to be able to find the people who are both technically competent and also willing to act like normal human beings in a collaborative manner. There's just so much attitude and ego w/people who think they're irreplaceble. And so very few of us really are.
Probably so. The thing is that when contract negotiation becomes important, this is what always happens. And with some customers, there simply is no other way. Some people do not understand collaboration and always try to cheat the other party as much as possible to gain profit.
Of course this often backfires, but taking one fork in the road let's you only see the path you've chosen. So, I'm expecting at least another 5 to 10 decades of Gantt charts.
I'm surprised if your boss will agree to let you work fewer days, even if it would benefit the company. Many managers are afraid of losing control. Many are oft afraid that if they give someone special privileges there will soon be others demanding them as well.
Then there's the issue that who knows if you're really working in the evening if there's no-one to watch you do it? And if you would be trust-worthy, how about the others who will soon be demanding to be able to work evenings as well?
So, it's very likely that your boss won't agree, despite it being superficially obvious that they should. It's just so much more emotionally safe saying nay.
Truth be told, I would probably be the most effective if I worked just six hours a day, uninterrupted. However, having tried to explain in a job interview why I'd like to "slack" so much, I have given up the fight. There are just some things that are inexplicable to some people. At the end of the day, it's not all about being productive. You also have to work "in a proper manner", which means that you get up early in the morning and work at least a good solid 9 or 10 hours despite your brain starting to fart after the first six. See, you gotta be a team player - and team players play by the rules, no matter how ineffective they make you.
If your boss is more enlightened than I'm expecting them to be, consider yourself very lucky!
Slashdot Mirror
Well, as the matter of fact, one of these people is a compiler specialist and the other one is the most senior technical person in his company. We all agree from personal experience that not doing more than that amount of work works the best in practice. We've been in this field 10-15 years, each.
I have personal experience that working about 30 hours a week works well. I am energetic, my thinking flows well and I get lots of stuff done. I have also worked myself to the ground by attempting to do more. That doesn't work and my experience has been mirrored by other experienced people who have tried.
If you still believe in measuring in this field, you have a long way to go. There's no good measure of amount X of work done in time Y, because it cannot really be compared w/other work unless you're doing basically the same exact thing twice. And we mostly don't.
The bottom line is that there's things we can't really measure effectively. I know that this drives the managers mad. However, I can only tell them what works and what doesn't. What does is that you remove all the obstacles from doing only the real work and minimize task switching. Then let the people do that for 30 effective hours a week. That how I'd basically run a software company. Of course there's more to it, but that's out of the scope of this discussion.
Above all, however, do not take my word for this. Go and find out yourself. Trial and error, adapt and improve.
Oh sure, I was very productive, as well! :-)
It depends a lot on what you're working at. Sometimes it takes me a week to write those ten lines. It really depends on the context. It's rather different if you're adding buttons to a GUI or if you're optimizing a communications module.
We once had a bug that took several months to fix and there were three people working on it. Eventually we created a partial solutions, because no better could be done w/o replacing the hardware. It just wasn't doable.
I have to admit, though, that I was quite junior at the time and wouldn't waste more than a week or two on such a problem these days. We spent lots of time trying to solve something that wasn't solvable.
No ownership, no buy-in. That's more or less the way it is. A very good point, indeed.
I've done that as well. I know two other senior programmers (who are very good) also working only 30 hours a week. What I've learned from this is that you shouldn't even try to work more than that. If you really have to stay at work more than this, it's best just to spend the time talking to people.
I guess part of the problem is that many managers haven't been doing serious programming in their career. They just don't get it, because their work is so vastly different. I also think that most managers are afraid of losing control if they let people do "whatever they want" even if it is what works best for all parties.
Some of them learn. Many don't. Many are new and haven't even had the chance to learn how it really goes. Sometimes it helps when they see that it works the way you say it does, sometimes that's not as important as seat time.
See, when a project is getting late the managers need to make sure it looks like they're doing whatever they can to catch up. This means people have to put in the extra hours even if it just makes the project even more late. So we're not really operating in a rational environment. That's one reason why rational arguments might not work.
I once worked from home for two weeks. It took me about 7 hours to get about 4 hours of actual programming done.
I also learned that it's way more fun to be in the office w/other people than working like this for more than a few days at a time.
Well, if you choose to define it that way. :-)
Personally, I prefer to call a spade a spade, but whatever works for you.
Well put! The last time I had a really difficult problem I had to do that at least two or three times. Finally, I got it, wrote the code and unit tested it and was very happy about the result.
:-D
A couple of weeks later the customer pulled the feature.
Of course, some people are still working on it, because our organization doesn't respond to change very well.
Well it depends. If it's good challenging hard, you can get into a great flow and get lots done. When it's getting really/too hard, you can't make much progress w/o letting your subconscious work on it.
In any case, doing even the former for an extended period you will probably end up w/days when you're not getting much done. That's when you need to just let your internal battery reload and not push it.
When the money keeps flowing in there's no evolutionary pressure and things at best stay what they are.
I've seen a lot of code that's crap because of the deadlines. And I've seen what crap code does to schedules in the long run. It's a recipe for a disaster, but nobody looks that far nowadays. Everybody's just concentrated on the current project deadline w/o thinking what this approach is doing to the productivity in the longer run. Sadly, in many places this cannot be helped. It's just business as usual.
To me it seems that the sustainable maximum of actual real work is about six hours a day. Anything beyond that and it starts to get uncomfortable and uncomfortable is bad in the long run. Also, I've noticed that the harder I work the less tolerance I have for just sitting around when I have nothing more to give. And sure, it depends a lot on the tasks. The more routine they are the more you can do. If it's really new/hard stuff, four hours a day may be the maximum. I believe that developers are most productive when working about 30 hours a week.
I used to smoke and very often I figured things out when I got up from my desk and went for a smoke. Another old regular was that I figured things out when I was walking home, about 300 meters along the way. Nowadays a common time is in the morning brushing my teeth. So there's a lot of stuff happening in the background and what's on the foreground may be distracting. I also often take the old pen and paper way when I really need to design something or when I need to figure out a hard problem. For some reason when the problems are really hard changing your approach can help.
You know, it doesn't hurt to have us adults around. Sometimes you can raise above the stupid comments and sometimes not. When you can't, just take a break and come back when and if you feel like it. I've been gone and back quite a few times already. These days I rarely get pissed off about stuff because I know that some of us just can't or won't bother to act like decent human beings. I come back despite these people because this is a good place to come to easily get an overview regarding what's going on in the tech world.
If you have good people that might work. If you don't, they won't synchronize w/one another adequately and end up wasting time that way. The regular work day is there so that people can talk to each other when they need to. I have waited for another developer to show up for 8 hours on a certain Monday. When he finally came, I had to leave. It doesn't really work too well if you have some people who come to work at 7 AM and other who come at 7 PM...
Have you actually tried to explain that to your boss?
Different time zones and different cultures - they're surely a challange. I think these kinds of arrangements are often so difficult that they hardly make sense at all unless you can get the group to work in the same place for the first few sprints so that they can get to know each other before you split the team.
But we gotta work w/what we got... It's never optimal.
I can see where you're coming from, but let me point out a few things.
I've worked in a company where people could come and go as they pleased. This ended up in a total disaster, because not everyone acted like responsible adults. So there certainly are talented people out there who just can't deal w/too much freedom. It'll go into their heads.
Then there's another scenario where you don't have an all-stars team. You could let some of the people do as they please, but this might hurt the team as a whole.
And then there's the problem w/recruiting only the best. It's very easily said and very hard to do. There are a lot of people out there who have the technical skills but w/such a horrible attitude that they can't work w/other people. Or they cannot deal w/technical solutions other than their own and insist on rewriting the whole world. It is tricky to be able to find the people who are both technically competent and also willing to act like normal human beings in a collaborative manner. There's just so much attitude and ego w/people who think they're irreplaceble. And so very few of us really are.
It depends very much. One of my previous managers actually let me program two weeks at home. Another fired me for disagreeing w/him. YMMV.
And multiplying things by two or three...
Probably so. The thing is that when contract negotiation becomes important, this is what always happens. And with some customers, there simply is no other way. Some people do not understand collaboration and always try to cheat the other party as much as possible to gain profit.
Of course this often backfires, but taking one fork in the road let's you only see the path you've chosen. So, I'm expecting at least another 5 to 10 decades of Gantt charts.
I ordered both books already, I didn't know I had missed stuff he had written beyond the two I mentioned earlier on.
Linked to wikipedia -> # 2009. Software Engineering: An Idea Whose Time Has Come and Gone?. IEEE Software, Viewpoints. July/August 2009. pages 94-95.
I'm surprised if your boss will agree to let you work fewer days, even if it would benefit the company. Many managers are afraid of losing control. Many are oft afraid that if they give someone special privileges there will soon be others demanding them as well.
Then there's the issue that who knows if you're really working in the evening if there's no-one to watch you do it? And if you would be trust-worthy, how about the others who will soon be demanding to be able to work evenings as well?
So, it's very likely that your boss won't agree, despite it being superficially obvious that they should. It's just so much more emotionally safe saying nay.
Truth be told, I would probably be the most effective if I worked just six hours a day, uninterrupted. However, having tried to explain in a job interview why I'd like to "slack" so much, I have given up the fight. There are just some things that are inexplicable to some people. At the end of the day, it's not all about being productive. You also have to work "in a proper manner", which means that you get up early in the morning and work at least a good solid 9 or 10 hours despite your brain starting to fart after the first six. See, you gotta be a team player - and team players play by the rules, no matter how ineffective they make you.
If your boss is more enlightened than I'm expecting them to be, consider yourself very lucky!
Thanks! I'll look into them.