The experiments cited in this paper are largely from the manufacturing age, where workers were doing largely mindless work on an assembly line. I'd imagine that for today's highly-trained, heavily knowledge-oriented creative class, the optimum workweek is roughly 25-30 hours. That seems to square with the amount of actual productive coding time I got when working on my startup, with the data RescueTime got on actual coding time for their YC class, and with conversations I've had with friends in Ph.D programs.
It's probably possible to squeeze another couple hours of mindless work in there (eg. checking e-mail, triaging bugs, meetings) to round out an 8-hour day. But if you're interested in getting the maximum coding output on hard, creative programming problems, 40 hours is way too much.
>>The experiments cited in this paper are largely from the manufacturing age, where workers were doing largely mindless work on an assembly line.
What do you think herds of corporate Java/C# programmers do with their auto complete/intellisense laden IDE's? That is nothing short of coding equivalent of assembly line work.
>> I'd imagine that for today's highly-trained, heavily knowledge-oriented creative class, the optimum workweek is roughly 25-30 hours.
People who fit into that description probably account for a very miniscule minority in the programming world today.
What do you think herds of corporate Java/C# programmers do with their auto complete/intellisense laden IDE's? That is nothing short of coding equivalent of assembly line work.
Do you actually know what assembly line work is?
You have power screw driver, an endless line of doors coming towards you, and an endless supply of screws also coming towards you. Pick up screw, place in hole, push on it with your screw driver. Repeat. There is no variation, only endless repetition.
It is a little known fact that the assembly line was originally inspired by a disassembly line. Specifically disassembling dead animals from whole bodies to specific cuts of meat in a meatpacker's plant. The body is coming towards you, whack off the leg, toss in that basket over there. Repeat.
The fact that different popups have different associated messages makes even the most routine coding infinitely more varied than an assembly line.
Try this. Spend an hour typing out:
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
...
That will give you a taste of how boring an assembly line is. (But not really, the task you're being asked to do there is more complex than the repetitive task than what an assembly line worker in Ford's day would be asked to do. Unless, of course, you cut and paste instead of typing.)
>>Do you actually know what assembly line work is?
I know what assembly line work is, I did it once during my engineering college days for a start up. And yes I did it for a small company so we would generally test what we assembled.
>>That will give you a taste of how boring an assembly line is.
Trust me auto generating get/set methods, try/catch blocks, javadocs, mass refactoring, import/package statements, Generating design pattern templates and getting used often used Framework functions(And all this getting autocompleted) sounds very similar to writing 'The quick brown fox jumps over the lazy dog' many times.
This is true if somebody asks you to check if you are writing 'The quick brown fox jumps over the lazy dog.' correctly every time.
> What do you think herds of corporate Java/C# programmers do with their auto complete/intellisense laden IDE's? That is nothing short of coding equivalent of assembly line work.
I'm sorry, but I need to ask you where you're getting your data from. There are some pretty dim coders out there who are mightily impressed with their ability to be a code monkey, despite the mindless nature of what they do. That's not what the majority of coders I've met are like, and I've spent over a decade in corporate environments. (Smalltalk shops may be atypical.)
When I was young and in larval stage, I would work very, very long hours on my hobby projects. Today, I think of myself as having a programmer's virtues of laziness, impatience, and hubris, I despise all-nighters (even for hobby projects), and I place a lot of value on leisure activities and time with friends and family. My passions have changed, even though I like having the time to work on my hobby and business projects (I've got two at the moment).
But then again, my skill level has increased far more than my desired work hours have decreased. When I started, I could barely use the Delphi graphical debugger, often dealt with null pointer errors from bad object-destruction or initialization practices, crashed my machine from copying data to the wrong location in memory half the time, reinvented the wheel most of the time, knew no math above high-school level (I was in middle school, after all!), knew only three similar imperative programming languages (QBasic, Delphi, and C++), and only knew how to use Windows ME. "Version control" was not even in my personal vocabulary, and I only knew the build system that came with my IDE.
Today, I know more programming languages than I can remember to list, I run all three major desktop OS's and program for them when desirable and necessary, I know enough calculus and linear algebra to make my way as a computer scientist and real programmer, either use garbage collection or practice strong memory discipline, almost never follow bad pointers, and do most of my debugging with System.err.println and command-line debuggers. I have used git, Mercurial, Subversion, and CVS, the former two professionally, and I've had the misfortune to use not only CMake, ant, SBT, and Python install/packaging scripts for build systems but autotools and manually-written Makefiles as well.
My desired hours of work have shrunk linearly, but my skill, knowledge-base, and sheer experience have grown polynomially if not exponentially. I don't just hit things with sticks anymore, I know where to hit things with sticks. Just who the hell does the world think I am?
But all that said, many employers most likely deal with a lot of larval-stage college grads and amateurs who remain unproductive enough to require long working hours well into their careers. There's also a gigantic signaling issue here, because not even 10 or 15 years in the field actually indicates that you're this kind of experienced, intuitive, get-it-done-quick-and-slope-off-down-the-pub hacker, nor that you're an "A player" for any specific field of problem.
So if I'm a hiring manager who wants to run a company full of lazy people (that is, "lazy" in the sense of short hours or even a reduced workweek), how do I find the programmers with the sheer skill to not require late-night debugging binges at least occasionally?
This is me pretty much. I crush problems under my foot at work, and then leave after putting the requisite hours in.
I've had employers tell me to work more hours so they could bill our clients more. I was naive, and asked why, as my components didn't require all-day debug sessions at client sites, and I regularly hit my milestones. I didn't understand the perverse incentives that come into play when consulting. No doubt they wanted me to work on something; but all they saw was the dollar value I was worth. In the time I would have spent at the office, I arguably put it into something more productive (long-term), such as working on side projects, or practicing a musical instrument.
These days I consult at a strict 30 hours a week. I have workaholic tendencies, so I'm on a rest cycle WRT work.
It's probably possible to squeeze another couple hours of mindless work in there (eg. checking e-mail, triaging bugs, meetings) to round out an 8-hour day. But if you're interested in getting the maximum coding output on hard, creative programming problems, 40 hours is way too much.