The Dangerous Allure of the 70-Hour Workweek (2006) | Hacker News Reader

The Dangerous Allure of the 70-Hour Workweek (2006)

hbr.org

22 pointshtatche9 comments

I'm always just a little skeptical when somebody says they're "working all the time" and then mentions a packed travel schedule. It's possible that they're spending all of that time in airports and on airplanes working, but it's just as possible that they're spending it watching movies or reading novels, too.

I've met a lot of people who have this sort of personality. The article is accurate when they describe it like a sport. I fully believe many of them when they choose to avoid leisurely activities on a plane.

Interesting to see this posted now. I only have anecdata, but it seems like the past year of eternal wfh has left a lot of people burned out and quitting or reducing hours.

Very much the opposite of this view from 15 years ago of people who were energized by long work weeks and lots of time spent traveling for work and in offices.

I would honestly do 70 hour work weeks as long as it was in software (which I enjoy anyways), and I got paid appropriately for extra time and had a month of vacation time.

I would bank money/pay off mortgage agressivley, and then as I got older I would just quit and work part time or do contract work, not having any major financial obligations and plenty of money in reserves

Remember Q&A positions? What happened to developing software and handing it off to someone that has good testing skills, whether it's manual testing or writing automated tests. If I'm not mistaken, the majority of software eng./dev. positions will now require you to do a lot of testing with the help of other engineers/developers, and this basically shifted the Q&A responsibilities over to the people who used to only solve the problem. Of course this has a huge impact on how many hours a week you need to work.

Now I'm feeling like there are even more responsibilities being tacked unto engineers and developers, where effectively, we are arriving at two main roles in software companies: Technologists, and Managers. Of course everyone is going to have to work more hours because everyone has more roles to take care of.

At least the software industry has been consolidating roles, and from my experience I have gone from developing, to developing, testing, managing people, communicating goals, doing presentations, and much more, when all I want to specialize in is problem solving for code. If we still had specialty roles, there would be a lot less weight on people's shoulders and they could optimize their role to a comfortable spot where they are not overworking so much.

I think management got wise to the fact that when QA and engineering both said the product wasn't ready, it was 2 departments against management, and management's vote was bigger than either of the other two.

Now that QA is gone it's just us versus them, and they have a majority ownership in the decision process.

There's no relationship between role specialization and working hours. If you're being overworked then push back, or look for a different job.

In general it's best to "shift left" with quality control activities and write automated functional and system test scripts simultaneously with product code. Otherwise developers tend to write garbage, then pitch it over the wall to testers and wait for defect reports to come back. That back and forth is a total waste which causes long release delays.

> There's no relationship between role specialization and working hours.

How so? More responsibilities surely equals more work. Furthermore, if you can focus on one role, you are more likely to optimize it.

> Otherwise developers tend to write garbage,

Then the developer is not good enough. Perhaps the problem has always been a lack of appreciation of CompSci skills.

> If you're being overworked then push back, or look for a different job.

You can't really push back, you get replaced, and all jobs right now are this way. People are asking why is there a culture of overwork... this is my explanation. If we want less overworking, perhaps we should go back to DIVIDING the work such that people can properly estimate and optimize for their role and eventually find a balance that works for them. As it stands now, you can't optimize for all the responsibilities properly, and are always catching up in learning, while trying to deliver features that have tight deadlines.

More like what I’ve noticed is developers have just stopped writing real test frameworks. Instead spot-checking pieces of the code, occasionally with a few automated integration tests.

Reply on news.ycombinator.com