>In the 1950s, there was the great promise of "the leisure society" - a future of such material abundance that most people would hardly need to work. That society became possible, but we systematically rejected it in favour of more consumption.
I'm not convinced this is true: there are also intense coordination costs and learning costs. Two programmers working 20 hours a week, for example, are way less productive than one programmer working 40 hours a week. And the one programmer will learn faster because she's putting in an extra 20 hours a week.
That's true in virtually all knowledge / creative / intellectual professions.
If people are simply executing a set of tasks, maybe working 20 hours a week can make sense, but those jobs are basically commodities, and commodity jobs are a) highly competitive, b) not that remunerative, and c) because of a and b, not that much fun.
EDIT: In response to the commenters below, take a look at Brooks' The Mythical Man Month if you'd like data, at least as far as programmers are concerned.
Sorry, I must disagree. Two people working 20 hours a week are refreshed, not burned out, have time for educationally side projects, etc.
I am in my early 60s and for my whole life I limited my work hours to 32 hours per week, even working for large companies. I had lots of time for educational side projects, exercise, extra time with family and friends, and mediation.
My only regret was not perhaps cutting this to less than 30 hours. I did not work Mondays, and every Tuesday morning I was refreshed and enjoyed my work. Leaving about 20% of my salary on the table was a good trade. Some of my bosses did not like this, but when I worked I gave them 100% effort.
Can I ask how you approached this issue with your employer(s)? I am willing to entertain that trade, but it doesn't appear many employers are willing to even think about it. They might fear it hurts employee relations or is simply too radical to comprehend.
I currently work three days a week for a reasonable salary.
Admittedly I live in New Zealand, so possibly the job market is different here (we're a pretty laid-back culture, and there's a shortage of good programmers).
I would suggest negotiating this arrangement when you're changing jobs. Your existing employer will likely be reluctant to reduce your hours, whereas (if you're any good) a new employer will be happy to have you for half of each week if the alternative is not having you at all. And it needs to be clear that that is the alternative. My current employer made me a couple of good full-time offers, which I declined: "I'm currently only looking for part time work, as I need the time to pursue my personal projects and interests."
Still on the theme of "It's better to have you part-time than not at all", you may be able to negotiate an ongoing part-time position at your existing workplace if you are seriously considering leaving (and thus the alternative is your leaving, and their not having you at all). Be careful about this, though. You want to maintain a good relationship. An ultimatum will do you no good. But if you're genuinely in-good-faith considering leaving, they may consider your offer.
You will probably have to try a number of different companies before you find one that will hire you on those terms. And, as with all bargaining, you need to be able to walk away.
DISCLAIMER: This worked for me the one time I tried it, but that may be complete coincidence.
Well, for example, at Google it's possible, some people I know work less than full week, however I doubt that this option is immediately available to a new hire.
That's a very subjective statement. I don't get even remotely burned out by 40 hours of work per week. I work every day of the week. I work when I want to. I don't have a family. I'm 32 years old. The organization of my life is by strict choice, and I love what I do, so I prefer to work longer hours. I'm more productive when I work 40+ hours.
I spend time learning, doing R&D / experimenting, doing product work, etc. The most fun I have is on the R&D. I've been doing it for 17 years straight and there's nothing else I'd rather be doing, I rarely suffer from exhaustion / burnout (and that's always when somethings fails, rather than feeling tired by the actual work).
This discussion is also going to vary dramatically based on the structure of your current life, including family / job / mood / etc. Adding further to the subjectivity of it.
I'm reading the Execute book by Josh Long and Drew Wilson and just last night they hit on the point that a few hours of 100% focused work mixed with a few 100% focused leisure hours a few times a day is more productive and satisfying then say 8 to 10 hours of 45% effort of work.
This is how Drew Wilson, creator of Space Box and many other works is able to achieve his high level of output. He manages his energy, listens to his body and mind, and does what is most suitable and productive knowing such things.
3 hours at 100% followed by 3 hours of leisure followed by 3 hours of 100% work would be 6 hours of 100% focused work. 6 solid hours of work is better than 8 hours of 50% focus (4 hours). Not only is the actual effort put in greater, but so is the focus and engagement which leads to even greater results.
>Sorry, I must disagree. Two people working 20 hours a week are refreshed, not burned out, have time for educationally side projects, etc.
Take a look at Brooks' The Mythical Man Month for data that demonstrates the opposite, at least in programming; I haven't followed the field closely, but education and industrial organization researchers have done similar work in other professions.
Brooks' was at IBM, they adhere to a 37.5 hours per week work schedule. Programmers who can produce 3-4 hours of real work per day are considered productive. Any more and you will start to burn them out.
We stuck to 37 when I was there, so everyone could take off a little early on a Friday.
I mean officially I was there 37, it was a good week if I was doing real, actual work for 20. Yes, I made up for it by working my tail off when it was needed.
We coders can be absurdly productive for short bursts, or be slow and steady. You can't have massively productive and steady for very long. In your early 20s you have a few years of this, but the more you push it then the more jaded you'll be later.
Not to detract from your overall point, but, as an IBMer, I can assure you that - while my full-time employment contract says max 37.5 hours - the reality is that at least 40 hours are expected.
1. That was about 40 years ago when the waterfall process was state of the art. Modern, iterative processes are much more flexible.
2. The loss of productivity levels off as the team size increases. Going from 50 to 100 developers is not the same as 1 to 2.
All said, I expect some loss of productivity is inevitable due to context switching and communication overhead but it isn't necessarily a major loss.
Pretty sure waterfall was never state of the art, rather an example of what not to do [0]. It's often held up as a straw man argument in promoting 'agile'. Brooks' book emphasises prototyping, and 'build one to throw away, you will anyway' which isn't 'waterfall'.
Brooks' book also clearly demonstrates that applying a dumb formula derived from the number of programmers doesn't predict the output, and using such a formula to estimate a project's timeline doesn't positively affect the project's outcome. It's main argument is that programmers added late to a project will actually cause it to take even longer to complete.
Brooks' book is remarkable - a lot of programming lore and culture originates there or is popularized by it. I'd compare it to casablanca or citizen kane rather than dismiss it out of hand.
In software, there is still economy in scale of a person's time. Throwing more people on a project is still detrimental even if you use something like Agile. It is a major loss.
The easy way to combat this is to have longer timelines for projects, or, if necessary, crunch periods followed by more relaxed recharge periods.
Brooks laid out a method as close to assembly line programming as he could, so yes, number of hours you mindlessly follow a formula would affect output. But no one programs like that now and I doubt they ever did. What we do now is closer to writing stories. How many writers do you know who spend a constant 40 hours per week writing for weeks on end?
It's meaningless to count hours for development work without also talking about how much of that time is spent doing actual work, and their velocity.
Someone who works 40 hours, takes regular breaks and keeps a moderate pace, sure. 40 hours of high pace concentrated development work? In the last 17 years of managing development teams, I've had maybe 1-2 people who could sustain that for more than a week or two at the time.
If it's 20 hours of time-on-task while in flow it's a TREMENDOUS amount of work in a knowledge worker job. We should all be so lucky to be so productive every week.
A lot of people's time is filled by very low-productive work such as excessive communication overhead, or fiddling around with low-quality tooling, etc.
I have some datapoints here. Twice in the last five years I have spent a year working half time (German parental leave is incredible). I noticed spending a higher proportion of my time on 'overhead' - emails, code reviews etc, but my overall productivity did not drop.
I measured the bugs fixed over time, commits made, lines and files changed, emails sent, all proxies for activity.
Bear in mind when looking at the charts that they are corrected for man months not calendar months - my calendar productivity remained about the same or slightly better over the measured period.
I recently reduced my hours to 27.5 just by asking. Without these positive experiences for all concerned that may not have been so easy.
Yes. It took decades of hard fights, including many that ended up in violent confrontations, to get the working day down from 12+ hours to about 8.
May 1 as an international day of labour demonstration was partly inspired by the immense effort of the US unions at fighting for the 8 hour day, and partly as a commemoration of the Haymarket massacre in Chicago that were part of that struggle:
Even today, there's plenty of people who want to reverse those gains. E.g. in the UK, our sitting PM is trying hard to get additional exemptions for the UK from the EU Working Time Directive because it limits how much extra time employers can demand and/or ask for.
>Two programmers working 20 hours a week, for example, are way less productive than one programmer working 40 hours a week. And the one programmer will learn faster because she's putting in an extra 20 hours a week.
From where did you pull out that data ? It is always possible that one programmer working 20 hours is more productive than two programmers working 40 hours. It depends what they are actually doing.
This is best seen through the lens and A type work and B type work. A work is what you get paid for - the delivering value to clients, committing code work. B work is education, design, clearing the desk, sharpening the saw.
40-60 hours a week of A work - or just tryi g to do A work leaves us without B work - soon this piles up into lack of education, lack of preparation.
I would be far better off and more productive if I limited myself to just 5 hours client work a day (or more likely 10 then 0) than the current mad rush.
We need to balance A work, B work and probably A leisure (time with kids) and B leisure ( housework, tv)
Major citation needed. 40 isn't some magical number, it's completely arbitrary. I've never seen a study that found a global optimal number for programming hours per week but if it somehow came out to be 40... that would be a coincidence of galactic proportions.
I'm not convinced this is true: there are also intense coordination costs and learning costs. Two programmers working 20 hours a week, for example, are way less productive than one programmer working 40 hours a week. And the one programmer will learn faster because she's putting in an extra 20 hours a week.
That's true in virtually all knowledge / creative / intellectual professions.
If people are simply executing a set of tasks, maybe working 20 hours a week can make sense, but those jobs are basically commodities, and commodity jobs are a) highly competitive, b) not that remunerative, and c) because of a and b, not that much fun.
EDIT: In response to the commenters below, take a look at Brooks' The Mythical Man Month if you'd like data, at least as far as programmers are concerned.