I am not sure that the question is whether a 60 hour workweek is fine. There's a huge difference, like it or not, between on one hand answering tech support calls for 60 hours in a week, or coding 60 hours in a week, or the like, and working as a self-employed individual for 60 hours every week.
I probably work 60 to 80 hours a week, most weeks. During slow times I work less. It includes everything from software development to discussing tech support issues with customers, to doing my own billing, to accounting, to any number of other tasks. If I worked less than 60 hours a week I wouldn't have time for real work most weeks.
But a few points:
1. I don't have a commute. When I used to work at Microsoft I would work 40 hours a week, spend at least ten hours a week stuck in traffic, and have at least 5 hours a week in unpaid break time. That adds up to 55 hours by itself. Had I lived a little further away, those could have added up to over 60 hours committed to work for 40 hours of pay. I also find being stuck in traffic significantly more stressful and draining than working.
2. I don't spend more than 40 hours a week doing any specific kind of work. Most weeks, I do less than 20 hours of work software development, and I know that if I am doing particularly heavy software development work, that going above 20 hours a week is courting burnout (I would rather put in 20 hours of really good effort than have to throttle effort in order to stay sane). For lighter work? Sure I could go up to 40.
3. The 60 to 80 hours includes a lot of time that would otherwise be hobby or personal project time, but which I can count because I am self-employed ;-). For example, I spent 20 hours worth of work this week on a strategic project that has no immediate impact regarding revenue, etc, but is fun and I think will make the rest of my work a lot more fun (when I have examples of how I will certainly submit them here on HN). That counts.
4. I work from home so all kinds of break time are usually family time unless I am on HN ;-).
So my point is that there are so many factors that go into this. I think the author is talking about working 60 hours for a business, particularly where you don't work from home, doing just one job. That's fine for short bursts but I wouldn't recommend it as a lifestyle. On the other hand there are certainly contexts where over 60 hours a week for the long run makes sense once you escape the idea that "it's a job."
That's really true. Counting for hours regardless of the intensity of workload is meaningless. I also think the OP's meaning behind how the hours is counted is regarding the full capacity of work load during the day, instead of including everything work related.
The intensity of the software development prevents one to work over 8 hours a day, and even not for too long without a break. What I mean is pretty much continuous work, reading news, emails and making calls are not included. This number is usually 5 hours for some standard software companies, which usually have meetings and chatting from time to time during the 8 hours of office work.
Everybody has his own strength during different age range. As startup company, it's really necessary to work 60-80 hours a week including overall work related activities. Just make sure not to burn out yourself.
I can do 8 hours of light-weight development easily enough, things like minor bugfixes, minor tweaks, etc. and carry that on for months if needed. But for stuff like coding from scratch, aside from brief bursts, I usually find that 4 hours is a good general guide. Obviously when nearing release, the long stretches of 8-10 hours of coding is going to be much lighter. Most of the tweaks are going to be minor, you hope, and so you can throw the rules out the window for a bit.
If you are working 60-80 hours a week, hopefully you aren't just doing one thing. It's one thing to put in 20 hours a week on software development, 20 hours a week on sales and marketing, 20 hours a week on fundraising, and 20 hours a week on business administration. It is far worse to put in 40 hours a week on software development, IMO.
Yes, on top of the 40 hours of intensive work including design, coding, learn a new technology with intensive reading, or even tackling business/marketing strategies and tactics, etc., the rest hours are on lighter work related things, such as email, news, phone calls, book-keeping, etc.
Regarding how to dividing the time slots, my usual practice is to concentrate on one major task and get it done completely in the shortest time period. For example, while I'm doing patent application, I have to complete it with all the available resources being collected and everything in the real-time memory for 2-3 weeks until it can pass the criteria. If it's a software development or fundraising, it may take 3-4 weeks to finish one round of intensive development and reach a milestone. After that period, I'm pretty much exhausted, and have to switch to something else to concentrate on, just like what you said. Focus and hammer down the nails with a deadline in mind is so important. Bug-fixing is a side job, light but time-consuming to cover every possible exceptional cases, but it also depends on whether it needs a redesign.
At the same time, I find that being willing to quit and come back is important to. I usually devote blocks of 4 hours to achievable tasks in that case. However if I run into problems getting things where they need to go, after 2-3 blocks, I may shelve the task and come back later as needed.
There are times when quitting is necessary for perspective, and where you can get the same task done quicker by quitting and moving onto something else, and then when you need to, coming back, than you would by pushing for a deadline. Learning to recognize that there are signs of "I don't really understand this problem, so I should come back after I have a chance to digest my failure today" and recognizing when that's a good idea takes some time though.
You reminded me in some cases I did, but I don't feel well about that. But I've already spent too much time on one item, if I didn't quit, it would delay the rest of the tasks.
Most of the time, I have to do extra hours of work to get it completed. Otherwise, it's hard get chance to revisit again unless it's a critical feature or bug.
Another strategy is, just like what you mentioned, once we are stuck at somewhere for more than 4 hours, we have to move to other tasks, give it up temporarily and later on when we come back, maybe things changed or mind changed, it's no longer that hard any more.
I have found that if I never get the opportunity, chances are it wasn't important anyway. For a lot of things that seem to be moth-balled, they have an amazing way of coming up later.
For example, a month after I gave up on rewriting the financial logic for LedgerSMB, I got a project that required a small subset of rewritten code there. So I went ahead, took the short cuts required for that, wrote an implementation and such in a half a day, from scratch, when my previous attempt took two weeks with nothing to show from it.
That lead to starting the rewrite again which will begin again in earnest after 1.4 branches off. Instead of budgetting months, I am now budgetting only days.
Yes, budgeting for days instead of budgeting for months. When we well manage the task list, usually a feature implementation takes 1-3 days, a project may take 3-4 weeks to reach a milestone. So no feature can take more than a week to finish. Priority is the key.
I probably work 60 to 80 hours a week, most weeks. During slow times I work less. It includes everything from software development to discussing tech support issues with customers, to doing my own billing, to accounting, to any number of other tasks. If I worked less than 60 hours a week I wouldn't have time for real work most weeks.
But a few points:
1. I don't have a commute. When I used to work at Microsoft I would work 40 hours a week, spend at least ten hours a week stuck in traffic, and have at least 5 hours a week in unpaid break time. That adds up to 55 hours by itself. Had I lived a little further away, those could have added up to over 60 hours committed to work for 40 hours of pay. I also find being stuck in traffic significantly more stressful and draining than working.
2. I don't spend more than 40 hours a week doing any specific kind of work. Most weeks, I do less than 20 hours of work software development, and I know that if I am doing particularly heavy software development work, that going above 20 hours a week is courting burnout (I would rather put in 20 hours of really good effort than have to throttle effort in order to stay sane). For lighter work? Sure I could go up to 40.
3. The 60 to 80 hours includes a lot of time that would otherwise be hobby or personal project time, but which I can count because I am self-employed ;-). For example, I spent 20 hours worth of work this week on a strategic project that has no immediate impact regarding revenue, etc, but is fun and I think will make the rest of my work a lot more fun (when I have examples of how I will certainly submit them here on HN). That counts.
4. I work from home so all kinds of break time are usually family time unless I am on HN ;-).
So my point is that there are so many factors that go into this. I think the author is talking about working 60 hours for a business, particularly where you don't work from home, doing just one job. That's fine for short bursts but I wouldn't recommend it as a lifestyle. On the other hand there are certainly contexts where over 60 hours a week for the long run makes sense once you escape the idea that "it's a job."