It should be noted that what is needed for assembly line productivity is different than what is needed for complex cognitive tasks. The more demanding the cognitive task, the more important sleep and relaxation are. That is why in Steve McConnell's classic Rapid Development he advocates a 35 hour week.
And the real limit for a lot of people may be less. For instance read http://www.kalzumeus.com/2012/05/18/kalzumeus-podcast-ep-2-w... to find out that patio11 thinks that he can only be productive 2-4 hours per day. This is a man who started a business on the side while working the insane hours of a Japanese salaryman. It isn't that he can't put in the hours, it is what he can do and be productive.
Greatly complicating all of this is are two simple facts. The first is that we can push ourselves and be productive for a short period, so over a couple of weeks we really can work insane hours and be productive. The second is that we have coping mechanisms to hide our own inability from us - so as our ability to function disappears down the drain, it is very hard for us to judge how impaired we are.
To that end, there was an interesting piece of research that I read about many years ago. The military was conducting research on sleep deprivation. One of their findings was that soldiers can be trained to operate on 6 hours of sleep, and will self-report that that they are functioning well and getting more done than they could if they slept longer. However the wives of those soldiers disagreed. And when ability to perform was judged on standard ability tests, the wives were right.
If you, personally, work long hours and consistently get little sleep, there is some food for thought. Could you be getting more done if you took care of yourself and put in more reasonable hours?
>>It should be noted that what is needed for assembly line productivity is different than what is needed for complex cognitive tasks.
Not actually. Assembly line work might be less intellectually appealing to us, but for a lot of people it is a complex cognitive task. If you were to talk to a every day assembly worker of an iPhone, he would find assembling complex circuitry pretty intellectually challenging.
Things become less intellectually challenging as your brain gets seasoned to it. Even coding for that matter these days has become pretty less intellectually challenging. Growth of modern day IDE's have rendered many programmers into kind of code assembly workers, autocomplete/intellisense does most of thinking these days.
>> The more demanding the cognitive task, the more important sleep and relaxation are.
My dad is a cab driver and he used to drive trucks before. I can tell you this is not true. You can easily argue driving is a repetitive task once learned. But you have no clue how tiring it becomes. In general a hobby is enjoyable, but any thing taken up full time as a profession is tiring.
In the book Flow by Mihály Csíkszentmihályi, he explains how once you get into Flow enough number of times, any job becomes boring and you have to keep moving higher up the ladder of difficult tasks to experience Flow again.
So its not that we programmers do jobs which are the center of the universe. What is true for others is generally true for us too.
Are you saying that the assembly line work that Ford studied was a complex cognitive task? Not according to the people who did it - in fact a major reason cited for quitting was that the work was so boring!
Luckily that type of work has been pretty much replaced by robots today.
Assembly line work is exhausting - very exhausting. However you can continue to do it while your brain is shot. This contrasts with programming where you simply usefully can't work on many problems unless you're in good enough shape to keep the necessary state in your head.
And an incidental note about your dad. Driving involves a lot of complex visual recognition and situational awareness of a constantly changing environment. We do not think of this as a complex cognitive task because we're wired to do it without even being aware of doing so. But when you look on a brain scan, huge parts of your brain light up and are working. This is real mental effort being made, and it is no surprise that you get tired after constantly doing it for long enough.
All I am saying is- the definition of a 'complex cognitive task' is highly subjective. And it depends on many other things.
To give you an example. Try writing code in Java these days. With Eclipse very soon(And trust me you will feel this in days) you will realize that you are hardly doing anything that is intellectually heavy lifting. Unless of course you are doing something that is totally new to your area of work. In that case its totally different. Which is the same case with assembly workers too(A totally new product unknown to you will be difficult to assemble).
But imagine doing applications which have nothing more than a DB interaction layer and some business logic. You can do this sort of a job for first 6 months of your programming career, and then you can have your muscle memory built to work with nearly auto completion method out there. Soon you will see that you will be doing nothing other than assembling already well known blocks of code without putting any sort of hard intellectual effort.
Rinse-Repeat this with a few domains/programming languages/architectures. Very soon you will find that you are doing nothing more assembling reusable blocks of logical pieces.
The only difference between hard labor and something like programming is the physical tiredness. This I completely agree with you that physical labor is more demanding to your body.
But other wise there is no reason for us to believe that the nature of our work is any different than anybody else.
I'd be curious to know where you've worked to form such an opinion. Sure programming CRUD apps gets repetitive and boring, but if you are literally needing to spend no mental energy on what you are doing, then you should move up the abstraction layer and write a script to do your job. If you're not using your full intelligence and capability as a programmer then you are doing it wrong (braindead body shop policies notwithstanding). This is not unique to programming by any means, but it's definitely not the same as assembly line work or taxi driving or line cook or any other rote job.
As one of those who actually stood at an assembly line, I can tell you that assembling an incredibly small part of product n+1 is not, in any way, comparable to implementing CRUD application n+1.
> Growth of modern day IDE's have rendered many programmers into kind of code assembly workers, autocomplete/intellisense does most of thinking these days.
Please tell me that there is irony involved in this quote. Otherwise the term "thinking" has been diluted to the point of existential crisis. What IDEs do is remembering and accounting. That's cognitive activity, but it's not something that involves sentience or thoughtfulness.
What separates the best programmers from the herd is thinking, and it's not embodied in an IDE.
> Nearly all creative work is delta improvements on remembering and accounting previous sources of knowledge.
[Citation Needed]
> What makes you think there are hundreds and thousands of best programmers?
There must be hundreds of thousands very good to pretty good programmers out there. To some extent what they do involves real thinking, though not necessarily all of it. Only the dimmest programmers are replaceable by a monkey with an IDE.
IDEs are to programmers as circular saws are to carpenters. The tools an automate a lot of work, but what distinguishes good from bad and the very best from the merely good is genuine skill and knowledge. Idiots will be quite capable of hurting themselves and incurring great expense to their employers.
> Things become less intellectually challenging as your brain gets seasoned to it.
That's obviously true.
>Even coding for that matter these days has become pretty less intellectually challenging. Growth of modern day IDE's have rendered many programmers into kind of code assembly workers, autocomplete/intellisense does most of thinking these days.
I don't think this is true. Of course IDEs made certain things easier like looking up class/method/function names and their documentation but imho that's not the hardest part about programming.
Besides that I agree with you. You can't make a general statement about what is tiring for someone. I think working as a craftsman is as tiring as working as a programmer - it's just different. A craftsman's body will be tired and a programmer's brain will be tired.
>>Of course IDEs made certain things easier like looking up class/method/function names and their documentation but imho that's not the hardest part about programming.
I would say this is true for programming tasks that are new to your already mastered problem domain.
But please think about this. How many times do we ever face situations where we sit down to do things that are totally new to us?
Vast majority of the programming world really writes repeated patterns of software meant solve repeated patterns of problems. And that perfectly explains why Frameworks, libraries, IDE's are such a religion these days.
Most of 'What needs to be written' and 'How it needs to be written' is already figured out. Of course this is not true for tasks that are new and require you to think a lot.
"How many times do we ever face situations where we sit down to do things that are totally new to us?"
The vast majority of my day, and the vast majority of my career. If you're not, it's most likely because you're not challenging yourself, and you've got nobody to blame for that but yourself.
When I first got out into the working world, I read all the posts that said "Really, the vast majority of programming is just plugging together pre-wired components and pulling stuff out of a database to stick on the screen, and all the interesting problems have been solved already." I thought that sounded terribly depressing, but I liked programming and it paid well, so I figured I'd deal with it later. And sure enough, after spending 3 years in college working on a PHP webapp and about a year at my first job wrestling with JSF/Hibernate, I was pretty bored.
So I quit. I founded a startup to let teenagers create their own casual games, basically trying to put Macromedia Flash on the web. On the way, I learned HTML, CSS, Python, JavaScript, and ActionScript; used MySQL, Postgres, MogileFS, Munin, Monit, Pylons, Django, and JQuery; wrestled with how to persistently store a "game" in editable form (eventually settled on an AST-based representation serialized to JSON and dumped into MogileFS, with metadata stored in the DB); wrote a compiler from that AST to JavaScript and ActionScript backends; learned some image processing so people could manipulate assets for their games; and implemented all these physics & collision-detection algorithms in the runtime library. The startup ended up failing, but I guess it was impressive enough to get me hired by Google.
When I entered Google, I thought I was a hot-shit frontend engineer because I'd been working intensively with JavaScript and Flash for a year and a half. It took me about 3 weeks to discover I knew basically nothing. Because Google Search really cares about latency, which means that all JavaScript libraries were banned, and we had to count bytes in our source code to make sure our new feature wasn't slowing things down too much for users. You design programs differently when every line of code you write is a cost not just to you but to your users; you actually think about what you write instead of tossing in a 100K library because you need a couple functions. Plus, when you don't have JQuery to hide all the browser details from you, you really need to know how each different browser performs and have a large catalog in your head of what works and what doesn't work.
I've moved off my home base in Search twice, once for a short stint working with Google+, and another for a recent project that'll remain unnamed. Both have their own array of challenges. Unlike Search, G+ is not latency-constrained; they expect you to stay on the site for significant periods of time. The whole site is a massive AJAX app, though, so you have the challenge of how to manage a million+ line JavaScript codebase. The new project is developer-constrained; it has a small headcount, and so once again I find myself working with the open-source Python/Django/AppEngine/JQuery/LESS stack, but each of those tools has evolved in the 5 years since I last used them, and we now have all these HTML5 goodies to play with.
That's not even counting backend stuff. After a year and a half as a FE SWE in Search, I was starting to get pretty bored, so I asked to do backend stuff. I ended up working on an LLVM-based JIT for a templating language; the spec for Google's Authorship markup; the implementation of said markup throughout the indexing & serving system; a bunch of unstructured data-extraction tasks; and most recently some machine-learning with libsvm. All of these were new, and all were challenging.
And that's not even including soft skills like code reviews, mentoring, interviewing, managing up, product & UX design, and project planning. Having 3000 lines of code dumped on you on Wednesday when they want to get it in by Friday, needing to quickly figure out how it all works, and knowing that if you screw up you'll break google.com is something entirely different from hitting autocomplete in your IDE.
I'm beginning to think that if you know exactly what to do, you probably have no clue what you're doing. Real engineering is all about trade-offs: it's knowing that if you implement this new feature, it'll cost you a millisecond in latency and 2 months of engineer time, it'll have some unspecified effect on future productivity, and it may result in X number of happy users. And then you have to weigh those unknowns and decide "Given what I know, is this how we should do it?" If you know the answer to that immediately, your product is probably lame, because it means you didn't even consider alternatives.
I've heard that argument before. I don't think I did anything that other people cannot do.
My overall point is that if you start believing that programming is just rote work that takes no skill, it becomes a self-fulfilling prophecy. Because then you never take on the challenges that will get you skills, and you're unqualified for jobs that will bring you more challenges, and eventually you end up falling so far behind that it seems hopeless. It really has very little to do with ability and a lot to do with constantly looking for ways that you can make the user experience a bit better at the expense of making things a little harder for yourself.
> Assembly line work might be less intellectually appealing to us, but for a lot of people it is a complex cognitive task. If you were to talk to a every day assembly worker of an iPhone, he would find assembling complex circuitry pretty intellectually challenging.
I doubt that. The way you make an assembly line efficient is by breaking down complex tasks into super-simple subtasks. Each person does one tiny thing, and does it over and over until the actions are automatic - you could practically do it in your sleep. If any task requires "intellectual challenge", you're doing something wrong; that is a bug in your assembly process that you should fix if you want a highly reliable, replicable result.
> It should be noted that what is needed for assembly line productivity is different than what is needed for complex cognitive tasks. The more demanding the cognitive task, the more important sleep and relaxation are. That is why in Steve McConnell's classic Rapid Development he advocates a 35 hour week.
In my personal experience this is 100% right. But the reason could be the level of pressure and the anxiety involved.
On manual jobs I can work more than 8 hours a day with a good productivity and without feeling tired. In software development I can't. Probably this depends on the pressure. If you are in a manual jobs with higher productivity pressure (like assemble <n> units a day where the average is less than that) will have a similar effect.
Also I find a difference between people who have an expertise in a more specific software development field (SQL databases) than on people who jump to different problems/languages/technologies in different computer fields all the time. You can maintain your productivity if you narrowed your areas of expertise.
"In a study on the effects of sleep deprivation, investigators at the University of Pennsylvania found that subjects who slept four to six hours a night for fourteen consecutive nights showed significant deficits in cognitive performance equivalent to going without sleep for up to three days in a row. Yet these subjects reported feeling only slightly sleepy and were unaware of how impaired they were."
I'll add to your comment just my observation of the necessity for good health. Some injuries without ready solutions disrupted my focus to the point where I simply couldn't perform at my prior level, no matter how much raw effort, willpower, caffeine, etc. I attempted.
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.
I wonder if one thing that distinguishes successful startup founders is that they are immune to some force that limits the amount of productive work that other people can do.
Of course everyone has a point where working another hour is not a good deal. But if that varies from person to person as much as other things do, it would be very convenient for a startup founder to be a couple standard deviations above the mean.
This is exactly the attitude everyone is challenging.
This is the superman myth, it doesn't exist.
If Bob, our intrepid entrepreneur, actually worked 40 hours a week he wouldn't spend so much time faffing. The 'busy work' disappears. Overall productivity drops the more you work long hours.
I've nowhere near your experience with entrepreneurs, I totally admit, but one of the symptoms I've noticed in crunch entrepreneurs is their mental diarrhoea, they take 15-20 minutes rambling on talking to you about a decision you've asked for that they normally would have made in a minute or 2. You start walking away and then suddenly they have another point/thought. They're mentally exhausted. I can reflect back on myself and see the same thing when I was doing crazy hours.
Some of these people have succeeded, some haven't.
But the person them self doesn't notice. They still think they are operating at high productivity.
Attitude? Your use of that word should set off alarm bells in your own head. I'm talking about a matter of fact, not a point of ideology.
I know people can work many more than 40 productive hours a week for years at a time because I did it myself during Viaweb. I know lots of YC founders who do as well.
I also know from my own experience that this ability varies between people. I can't work the hours now at 47 that I could at 30.
Why shouldn't ability to work vary among humans? Practically every other ability does.
I don't know. It seems you are confounding a couple of issues. First is the scope of the article. It seems more of a policy for good practices to adhere to in treating employees. Even if you are a marathon runner, it would not be in your self-interests to require long distance running as a job criteria. Secondly is motivation. The motivations of a founder are often counter to that of an employee. From the perspective of many employees, job satisfaction is much more desirable to a high reward outcome - irrespective of dedication, hard work, or talent.
While you know your experience, you don't have access to the alternative futures that might have resulted given different behavior. Which is why personal experiences and anecdotes do not substitute for actual causal analysis.
At a certain point (or at multiple points during a suitable long stretch), enduring the long hours becomes a top priority for an individual actor in an attempt to avoid the "slow-down". The actor may decide to switch to a task that they can more easily handle so as to remain "productive", but this switch is not necessarily to the most important task to complete the enterprise goal; or may be a "refresh task" which does not directly contribute to the enterprise goal (though may help with the productivity on future tasks).
[Edit]
As a result, they see high productivity, but do not see the focus shift. Staying on task is what is important in crunch mode, and there may be some utility to founders that have more tasks (and thus goals) in shifting focus, but larger organizations suffer from defocusing, task shifting, and worker collisions.
That was what I observed when working at EA (I was actually part of the EA Spouse settlement so this kind of comes home).
Probably 10-20% of the people on the dev team just loved it. They couldn't get enough. That includes engineers and artists. They could work from 9am to 11pm for months.
But then management expects 100% of people to be like that. And there's peer pressure not to let down your coworkers. But in reality some people just have more stamina, and can get more done with the incremental hour, while for others it was just clocking time and being a zombie.
I definitely couldn't get much more done in all those late nights, although it in part it has to do with the fact that there was some sort of "schedule". If you know that you can take a day or 2 off whenever you want, you're likely to have more stamina for a 16 hour bender.
Anyway, there is so much human variation in other things; it doesn't surprise me at all that it's true for how many hours you can productively work in a day. I would bet startup founders need that stamina, although I'm sure there are many more components to success.
"That includes engineers and artists. They could work from 9am to 11pm for months."
My experience through various sectors of the software industry (including gaming) is that virtually nobody really works 9 am to 11pm for months. But some people are happy being at the office from 9 am to 11 pm assuming the "work day" includes a multi-hour team lunch break, some random breaks for playing Doom II, Diablo 3 or the newest Battlefield or whatever is hot at the office, lots of slashdotting/redditing/HNing/etc, hours long discussions about what happened on the hot geeky tv show, etc. So what it comes down to isn't even the workaholics vs the non-workaholics, but the totally tech-focused geeks vs the people who have non-tech things going on in their lives.
FWIW, up until my early-mid 30s I was very much the former, so I don't entirely begrudge that lifestyle, but I think it is mostly fantasy that those people are putting in significantly more actual work hours than the other group. Personally, I know I'm vastly more productive putting in 8-ish hours day now than I ever was when I was putting in 16-ish hour "work" days, though everyone's mileage may vary.
That wasn't my experience. Like I said 10-20% of people could genuinely get more done in their 12th hour and such. It doesn't mean that they never got up from their desks, but it was true that they couldn't get that amount of work done in 8 hours. And it went on for months.
That said, there was lots of downtime, mainly for people whose brains were burnt like mine. Never multi hour lunches though.
It would be surprising if on a talented team there simply weren't people who had much more stamina than others, or just enjoyed their work much more. I'm not saying there's something to be glorified or emulated there.
>>But then management expects 100% of people to be like that.
All management that I've seen dislikes people with 'distinction', 'rock stars', 'mavericks'... The reason is they make rewards inevitable.
The cult of management likes to believe in comparative rewarding. Its believed if all are same, no one deserves a reward.
Besides I've met a few managers who mark awesome performances as just 'meets expectations' because they expected you to be awesome and you were just that. So no reward for you.
Management survives on averaging and normalizing people efforts to minimize giving away of rewards.
I think the main difference is engagement vs grinding. Take gaming for example. How many hours can you sink into that? My personal experience was that I could go pretty hard at it with very little sleep (I know, i know) and still be quite effective. I get the same way when im hacking away at something i love. Right now, im trying to put together a JS debugger for vim. Its 3am here and I can just keep on going.
Now, the same cant be said about writing TPS reports.
There's a necessary stopping point, even for one's own projects.
A few nights ago,I got jazzed-up on the Vietnamese Iced Coffee I'd had with dinner, and I literally coded all night and into the daylight. I probably started around 8PM and ended around 9AM, working on my hobby project.
And honestly, if I hadn't been jazzed up, I would have stopped somewhere around 1:30AM, to my own great benefit. By the end I was spending half my available effort just staying awake and remembering how my code is broadly structured.
If I'd had to do something other than cycle through compile-run-debug, I would have failed completely. No matter your caffeine or passion levels, at some point you lose sanity points and Cthulhu arises from the depths to eat your code and then your soul.
You have the choice to carry on working on your debugger or to knock off and have some sleep or downtime. I am assuming from your choice of words that this is a personal project.
Now, imagine the same hours on someone else's tasks and according to an inflexible schedule. Would it be the same? I think not. I imagine that is what you meant by 'grinding'.
Point well taken. Even a project you're totally stimulated by, committed to, and engaged in on multiple levels can become a grind if it enters the get-it-done-or-else phase.
Yeah for sure... I just spent about 25 hours in a single weekend coding on my own stuff. And I feel great now. I had that high today, on a Monday! But even though games are somewhat interesting, it wasn't my main passion and I wasn't that good at it, so I got burned out pretty fast.
So bottom line is that it's futile for management to push people that hard. Some people love the problem and they'll put tremendous hours int oit. But you can't force that upon anyone.
On the other hand, perversely, I can see the logic to it. There are 20% of people who are running full stream and being super productive for 14 hours a day. Maybe you just keep everybody in the office so that those people feel like everyone is making a sacrifice too? If you don't care about burning people out, I guess it is rational to keep people in the office if only 20% of people get more work done, if those 20% would leave if everyone wasn't there.
But how long did they keep this up for? Months-long crunch times popping up for, what, 5 years? Or did they keep this up for 10, 20 years? Burnout and health effects can take years to show up.
I suspect those that do this and keep up the pace move on to more organizational work later on, which isn't the same thing.
7-9 months... it's a yearly cycle. So maybe from January or so to August. Maybe only that max intensity for 3 months or so. For a couple months after the game ships there is a lot of goofing off and unwinding.
Lots of people leave the game industry like me, but there were definitely those who did it for 10 years straight.
Does RescueTime have any data on this? ISTR Tony posting here once that they measured the amount of time each startup in their batch spent in front of the editor, and the very top end came out to about 7 hours/day, with most clustered around 4-5 hours/day like the rest of us.
For example, at one point in my life I worked 8-hour office days and 8-hour evenings as a bartender. I was astonished to discover I could do this for months without getting exhausted at all, because they used completely different parts of my brains, with virtually zero overlap. Office work was intellectual, bar work was physical and social.
I personally can't do truly effective, intellectual coding for more than about four hours in a day. After that, it exhausts me. But I can happily deal with meetings, or project management, or marketing or whatnot. So because startup founders can often divide their time up into blocks of entirely different tasks, it makes sense they can work effectively over longer hours.
Note, I'm not talking about being interrupted all the time, though -- I'm talking about 4 hours of coding, 4 hours of meeting, 2 hours of product, 4 hours of marketing.
One possibility is that for a startup founder, there usually is a great variety of work.
One hour you could be writing code, the next answering a support email, the next pitching a prospective customer, and so on. It could be that by switching gears every few hours, people are able to retain some of their productivity.
Context switching is, in the literature, known to be productivity destroying, and while it may feel like a very productive day if I do things from four categories, I can tell you that when I actually go back and look at the results it is feelings-nothing-more-than-feelings.
e.g. If I were doing nothing but customer contact mode, I know that I can send 50 emails in a day of moderate complexity. (e.g. Consulting mini-proposal for a client, support issue for BCC customer, pre-sales question for AR, ... x50. I know this because I have verifiably done it on e.g. launch days before.)
I did four things today -- video recording, hopped on a call, sent emails, and... shoot, only three things but I thought I remembered four. My subjective experience is that 1/3rd of my day was email. How many emails did I send? 1/3 * 50 = ~15? No. Five. And it (subjectively) felt like pulling teeth even though three of those were the same email with a few hand-written edits in the middle of them, whereas after I get into email flow mode for I can normally do two hours without getting bored.
I've got at least two hours into working with video today. How many 5 minute videos have I completed? Umm, zero.
Contrast this with yesterday: yesterday I putzed around to 6 PM and then coded until 10 PM then quit for dinner. I got two features coded and tested then squashed a pair of bugs. Yesterday feels non-productive in some ineffable way ("I putzed around until 6 PM! I only worked 4 hours and my salaryman brain rebels against the sheer laxity! All I did was code six measly little commits!") but it almost certainly added more to the business.
I felt a strong urge to downvote this. It sounds like a paternalistic excuse to dismiss the whole article, but then...
Isn't it the case that they can do more in the same amount of time, not work longer? Either way it's a net win, but I don't think you need superpowers to be successful.
That could be the case; but it's also certainly possible that many or most successful founders are not much different from normal people in their ability to effectively work long hours. (And my personal intuition is that this second possibility is more likely than your theory.)
Incidentally: in your essays (which I enjoy), you often imply that founders should work long hours. If founders working long hours actually decreases the likelihood of a startup succeeding, then you've been giving bad advice for many years now. (And I'm sure that people have been taking it.) That's something that you should think seriously about.
You mention this as if you don't already have more than enough data to tell us whether it's true or not.
Is it?
When you run a spreadsheet and scatter plot hours worked over the first few months against your ROI on startups, do you see a meaningful correlation?
I say "first few months" because once a startup is successful, the founders are almost always going to put in more hours than those that languish in obscurity.
That's an interesting question. people obviously vary greatly in how much work they can get done in all sorts of ways. How much they can get done in an hour, how many hours they can do. They also vary within individuals in depending on circumstances, mood and seemingly unrelated things. I know someone who became extremely productive for a time after exiting a relationship.
I think everyone has experienced extreme bursts of productivity at some point where they think "If I could keep this up: I could work just 3 months a year / complete a degree in 6 months / build this thing in a 3 weeks." The differences between average and awesome, for the same person, are huge.
My guess is that the people who can consistently keep their productivity at the far end of the spectrum are there because of a combination factors, but I am really just guessing.
Of course a certain excitement can help doing more productive hours a day for a couple of weeks/months but I don't think this holds on for a longer time.
As a software engineer I exactly notice the things the article mentions. After 6-7 hours I'm getting tired and after 8 hours it becomes really hard to concentrate.
I agree it seems common sense that the maximum number of productive hours would vary per person, just as so many other things in life. I would also expect that the number of productive hours is highly dependent on the type of work, the variation in the work, and the incentives people get. Startup work would be very different from other work in that respect.
Lots of people with a 40 hour work week go home to play a computer game for several hours a night. If your work was as much fun as playing a computer game you would have no problem working 10 hours a day. Startup work might be just as much fun as computer games?
Whether it's purely emotional or a subconscious economic calculation, there's a big difference between work on something that you own and care about and work done because it's your job.
i'm curious: do you think you are or have been an outlier? I've had the occasional 16 hour stint on something I'm excited about, but this isn't the common case for me. 4-6 hours a day is what I produce in optimum ordinary conditions nowadays.
You did not read the article, did you? What it shows is that it... does NOT depend from person to person as, say, the hair colour or the ability to sing properly.
In my manager past, the times i've asked for crunch mode are few and far in between, and I always put a carrot at the end, depending on the severity of the crunch. Anywhere from a nice lunch at a fancy restaurant, to a few days off. I've even dangled a team building movie matinee. I've never found cash to be a real big motivator.
My 2 simple rules for crunch mode:
1. Manager better be there. Me personally, i would dive in and actually start doing code reviews. But even if I had absolutely nothing to add, I had to be there to show support. Even for window dressing. You call for crunch mode, you better be present. Even if its just to buy lunch or starbucks for the devs.
2. Coding is like breathing. Crunch mode inhale must be followed by re-tooling, decompressing exhale. You can only inhale so much.
I'm pretty sure you've never managed me, so don't take this as a personal attack, but nothing makes me more disgruntled than the management announcing that a month of overtime (estimated market cost to me: more than £1500) will be followed by a nice lunch at a fancy restaurant (estimated market cost to the company: less than £50). The two are not remotely comparable, and to think of it as a carrot (or worse, a quid pro quo) when in fact it's much closer to a thank-you for a favour is infuriating.
Your two rules are...minimally adequate, I guess. They're certainly nothing to pat yourself on the back about.
If the cash carrot works for you, then great. On the converse side, one of the main things i look for when building teams, above developer skill is craft and commitment. I try to say away from gunslingers as much as possible.
Which is why I can get away with my minimally adequate rules as you've put it. I certainly dont pat myself in the back about my rules. Its all about sharing the pain. I also forgot my 3rd rule. Only developers set deadlines so I can ask them to commit to it. If we have a date to hit, then we work on scope.
No, you misunderstand (though I didn't phrase what I meant very clearly). I'm not particularly interested in additional money above my salary, I'd prefer free time. My point is that if you are going to look at things in the light of P&L (and, as a manager, your superiors definitely will be), offering a "carrot" (which is a loathsome metaphor - developers are not donkeys) of less than 3% of the gain to the company is just insulting.
I think we're in some sort of agreement here. As I touched on my original comment, depending on the severity of the crunch, I will ask for (yes I was in middle management, blech) and offer days off. I agree that a lunch, no matter how nice it is, is no replacement for a 3 month death march. What you're latching onto are what I use for minor, not more than a few days things.
Though its usually a nightmare for me to work this out with HR, days off to me can mean actual vacation time which to me, is more precious than cash. It can also mean time doing cool stuff, or as the late Steven Covey would put it, time to spend "sharpening the axe" like making a presentation on the latest version of FizzBangWow product/language/framework, trips to conferences. I've even had devs prefer to work on clearing out technical debt. That's craft.
Productivity has various shades and maximizing productivity of a corporate slave is difficult.
What I have observed is people sprint only under to two situations- first when a lion is behind them or when they are chasing a gold treasure. Expecting people to sprint all the time doing work as normal without any gains or losses doesn't get winners in any situations.
In my experience my work day is generally divided into three sets of tasks. Periods which I spend firefighting, providing support to some urgent issue, providing information, routine chores, fixing bugs, adding features. The most productive periods of my work involve doing new stuff. The most unproductive and boring stuff involves manual testing, writing test cases and documentation.
So if you see it- money, fear of getting fired and interesting work form the biggest motivating factors in my daily productivity efforts. I never understood CEO/VP/Manager BS talk of expecting people to remain ridiculously productive regardless of rewards and quality of work. Especially when they themselves don't follow that advice. No manager/CEO/VP I've every met wants to work in a non growth area of work. They never want to touch anything that is not rewarding to their very own careers. Yet they expect their reports to the very thing they would never do.
Other wise personal productivity wise, my day breaks up into three parts 8:00-12:00, 13:00-17:00, 20:00-00:00. I skip the last part sometimes. Another thing that I've learned about productivity is to know how to tackle inevitable distraction. How not to get overwhelmed by tasks at hand, How to use GTD efficiently and learn to work from one session to another.
It's been proven repeatedly during the last 100 years that overtime doesn't work. Yet it falls on deaf ears in my industry. I've worked for 10 years in games development. Every single company had unpaid mandatory overtime. It's depressing.
Here's a solution. Pay your employees for overtime - suddenly you'll find a way to not do it. But it's too late, because it's now accepted (and expected). Even though it's counter productive.
When you work more than 40 hours per week, you're borrowing time from your future self. However, the interest rates are very high, and so usually it doesn't make sense to borrow this time.
This is so so true ... I've been doing 4.5-5.5 hour nights (sleep) for years and very recently have started to see the effects in aging ... greying and balding at a much earlier age than I anticipated (for example). I've made my peace with it now, but I can't help but wonder how much I would have cheated aging if I had been sleeping 7/8 hours a night instead.
More scary is how much of the detrimental effect of lack of sleep I am yet to encounter.
One thing I've observed while working at a tech company and then in trying to start my own is that "crunch mode" can be a protective mechanism to carve out some uninterrupted time. So it's not that working a 12 hour day coding is more productive than working an 8 hour day coding, it's that the first 8 hours are taken up with non coding tasks like meetings, project planning, marketing, responding to emails, intros, etc and the only way to get any coding done is to stay late when no one else is expecting you to be around or on email.
If you find yourself working 12+ hour days ask yourself, how many hours a day do you really have your full well rested mind at your disposal during an uninterrupted period of time? If it's 4 or less, chances are you aren't getting any more important work done, and you are quite possibly getting less done because the hours you have to spend on the creative tasks are not with a fully rested brain.
This will be my takeaway tl;dr: "Crunch does not make the product ship sooner — it makes the product ready later. Crunch does not make the product better — it makes the product worse."
Far too many people in management don't get, or just choose to ignore, that.
I think I've already left a comment on a similar thread about leading a team through crunch with one of the devs still doing 6 hour days. Some more time has passed and I have to say even when the rest of the team are doing 8 hour days it still feels like there's a difference in focus, intuition and problem-solving.
Of course all that is highly subjective, but it made me think about how to measure the.. craftsmanship? Anyway, intuitively it feels like having a few more hours away from the office would give us some more time to subconciously process the problems and tasks at hand, and when we come back to work we're better prepared for it.
It can't be impossible to conduct some kind of test on this, can it?
Useful output depends highly upon the nature of the work and how well-rested you are. I find myself capable of at most 4 hours of high-intensity programming per day, but easily capable of 10 hours of routine work. However, if I don't get at least 7 hours of sleep per night, I'm useless for most everything.
Commenting on the statistics themselves, though, I would very much like to see the data on working time disambiguated from the data on sleep. Perhaps the negative correlation between working hours and productivity stems from their mutual relation to sleep: it is not only possible, but probable that sleep declines about linearly with hours worked. I would argue that the difference in sleep is likely to make a far larger difference for the majority than the difference in the length of the workweek.
It's interesting that, after all the productivity gains in the last century, we are still worried about maximizing output, all while putting two adults to work in each household.
The productivity gains have happened _because_ people were obsessed with increasing output. What's even more interesting is that we've had to adopt a consumer culture to keep the economy rolling in the face of an excess of supply. Marketing is an entire field of pseudoscience devoted to increasing demand to meet an artifically inflated supply.
Even the web is funded largely by advertising, marketing. Could it exist if we in the west had a classical eastern philosophy of not desiring more than we needed? Given that china invented practically everything, but got "nowhere" doing it until they adopted consumer culture, i suspect that the web wouldn't have happened.
Admittedly, China didn't "go nowhere". Late Medieval China had living conditions better than any the pre-industrial and industrial West managed, while working less than the post-industrial West does today. Only the onset of social democracy and post-industrialization drove living standards up to what the Chinese enjoyed for ages.
Admittedly, they mostly managed this because large portions of their land area could naturally support plenty of people without too much work put into agriculture.
Why would it be surprising? Individuals tend to want to maximize their income to improve their situation, even if most other people think they are making "enough".
There are significant constraints on people's ability to choose. Many people, particularly in the upper-middle-class, would choose lower income for lower hours if it were an option. Of course, many others wouldn't. But if it were common for large companies to offer, say, a choice of working a standard workweek for regular pay, or a 32-hour workweek with every Friday off for lower pay, quite a few people would take the 4-day-week option.
This is one of the problems, the absurdities, of economic inequality.
The upper-middle class, in America and parts of Europe at least, is the highest anyone can rise by working for other people. It is surely a rat-race to get there, although a fairly meritocratic rat race. The result is that "upper-middle class" jobs are very highly competitive, and tend to remain at a highly competitive equilibrium level of salaries and working conditions even if there's an apparent skill shortage within the particular industry itself. Because after all, there might be a shortage of programmers, but if you don't want to work long hours, what're you going to do, get a fast-food job?
Thus we get ourselves an entire class of people who, by most standards, are rampantly overworked, but at the same time quite sufficiently paid. If only they were to stop competing with each other for status (inside and outside the workplace), they might be able to put an end to the poisonous equilibrium of the 50-hour workweek, simply by agreeing that the last $20k/year of salary isn't that important.
It's depressing that this still has to be discussed. Folks, if you're marketable, please don't reward companies with your employment if they continuously death march you.
Never seen a single hour of that extra time either paid back or returned to you? Time to go. However it will require everybody to do their part to defeat the system.
Seeing as the average age in my industry is probably 25 I'd say it's not going to happen. The young ones are quite happy to be abused (and take some perverse enjoyment out of it).
People change companies frequently, but all the companies my friends work at now have the same set of issues. Then there are friends who quit the industry and got proper jobs. They just laugh at the whole thing. Granted they have a different kind of bullshit to deal with (bureaucracy in code, formal development) but the working conditions and remuneration just don't compare to gamedev so none of them returned and they think it was a good trade.
For me the magic factor to maximize productivity is sleep.
I have worked consistent 70 hour weeks, where most of those hours are in sprint high-productivity coding mode, AND without getting burnt out or tired. The secret is simple: I was getting 9-10 hours of solid sleep every night.
Sadly it's far too easy to stay up late at night browsing the web, losing sleep for no good reason in particular.
Before arbitrarily drawing conclusions about software development, it would be necessary to actually run proper studies in this industry. It is simply not rational, or scientific, to apply the results of manufacturing-related studies to software development, when the nature of the work and the cognitive bottlenecks are completely different.
Based on anecdotal evidence, I would postulate that the average optimal workweek length for intellectual (and part-creative) work is significantly shorter than 40 hours (30 hours?), and probably varies wildly among individuals (while the optimal manufacturing workweek length is very stable over different individuals).
Can I ask everybody here, why is it so prevalent in the Software industry? What other industry accepts crunch mode? I can think of only 2 (military, banking/finance) I mean, do the developers actually like it? Wannabe heroes?
The staff at retail outlets don't work regular hours between Thanksgiving and Christmas, or your town's road department employees after a snowstorm, or the utility company crews following a hurricane. "Crunch time" as a programmer is kind of a joke. You sit in a chair some extra hours, mumble complaints about bad project management. and pat yourself on the back for your sacrifice.
Forums for tech self-select for ego stroking keyboard-warrior crunch time stories. Why would you see other industries complaining about crunch time bere?
I watched a facilities rep tell Big Payroll Vendor consultants that the 80 hour/week restriction had to be removed because crews work 100+ hour weeks to clean up the campus after storms. The consultants literally laughed in this guy's face and joked about how it would suck if someone actually had to work more than 80 hours in a week. Took a long awkward silence before they realized they had embarrassed themselves.
Thanks for this. Noticed the same phenomenon during my art school days. A lot of students would consistently "brag" about pulling all nighters. Was their work better? No. It may work at the end of a project when you need to get some stuff wrapped up and have the adrenaline to keep you focused, but regularly? No. This is especially true in programming and especially design, where making the right decision is all that matters.
In addition to [or may be instead of] this long article, one might look at the real examples of people, who achieved exceptional results whilst working less than 8 hours per day.
One such example is Roberto Goizueta, whose work habits at the helm of Coke were vividly described in this book - Greising, David (1989). I'd Like the World to Buy a Coke: The Life and Leadership of Roberto Goizueta.
And the real limit for a lot of people may be less. For instance read http://www.kalzumeus.com/2012/05/18/kalzumeus-podcast-ep-2-w... to find out that patio11 thinks that he can only be productive 2-4 hours per day. This is a man who started a business on the side while working the insane hours of a Japanese salaryman. It isn't that he can't put in the hours, it is what he can do and be productive.
Greatly complicating all of this is are two simple facts. The first is that we can push ourselves and be productive for a short period, so over a couple of weeks we really can work insane hours and be productive. The second is that we have coping mechanisms to hide our own inability from us - so as our ability to function disappears down the drain, it is very hard for us to judge how impaired we are.
To that end, there was an interesting piece of research that I read about many years ago. The military was conducting research on sleep deprivation. One of their findings was that soldiers can be trained to operate on 6 hours of sleep, and will self-report that that they are functioning well and getting more done than they could if they slept longer. However the wives of those soldiers disagreed. And when ability to perform was judged on standard ability tests, the wives were right.
If you, personally, work long hours and consistently get little sleep, there is some food for thought. Could you be getting more done if you took care of yourself and put in more reasonable hours?