Hacker News Reader

Comment by audunw | Hacker News Reader

I wonder if this will be good or bad for the competitiveness of China if they are able to enforce it.

The company I work in now has no problem competing with Chinese companies working 996, despite us working 7.5h days and having way more vacation days. I believe part of that is that working longer hours doesn't necessarily make you more productive, as has been discussed in tech communities for a while now.

The thing is, to be productive with shorter working hours requires a very different culture. The company I work in now has a very flat structure, and people are encouraged to work on side projects that can improve productivity, and there's a focus on continuously improving methodology. The last company I worked for was Chinese-American (based in US, but 99% Chinese working there), and it was the exact opposite. Decisions on what to work on was made top-down and results were mainly achieved through brute force. Although since we worked in a somewhat independent office in Europe we ended up with a hybrid system.

So the question is, will a shift away from 996 lead to a shift in work culture that increases productivity, or will they just work fewer hours with the same culture?

That seems to be the problem for the CCP in general. They want to make improvements, but they don't really get to the root of the problem. They crack down on after-school tutoring for instance, but they don't change the Gaokao system, so tutoring will just go underground.

View on HN

I actually think in this case CCP is playing the right cards (unlike in the case of tutoring). I also believe that Chinese are quite tired of having to put up with the exploitative work practices and I highly doubt 996 is anything of a competitive advantage.

The whole mentality of 996 goes back to the time when most of the jobs were manufacturing jobs. If you are a garments factory whats the simplest way to increase throughput? Well, make your workers work harder. If you are in a country the size of China and your workers revolt, replacing them is simple enough. This unfortunately does not work for tech companies. Making software engineers work long hours will just piss them of. Also by its nature spending more time on a piece of code doesn't mean you'll be more productive (in fact I've found the best way to deal with a bug is often take a break and come back and reread your code likely you'll spot the mistake far more easily). Also if a software engineer is good enough they may simply choose to work for an American firm which gives them much more free time and are equally competitive. Furthermore, the more turnover there is in a software firm, the less efficient it is as new hires will have to learn the code base from scratch. So now firing an individual and replacing him may not be as easy as before. Hence, I doubt CCP will actually have to enforce the rule, the firms themselves will self enforce the rules.

> Also if a software engineer is good enough they may simply choose to work for an American firm

This seems a bit unlikely to me:

1. Ignores patriotism.

2. The number of good programmers in China is going to overwhelmingly outnumber the opportunities for them to work for a US company.

There are vanishingly few good programmers in China, proportionally. I have a friend that heads a computer science department at a regional university in China. He's an old friend of my wife. The vast majority of graduates from his department have never run a single line of code on an actual computer. The teaching and assessment is 100% theoretical on paper, and this is typical.

Now I'm sure there are colleges and universities where this isn't true, and there are lots of Chinese programmers that do it for fun and love it just as much as any 'westerner'. I've actually met some shit hot C and C++ coders in china professionally and these people absolutely knew their stuff. However the base level education system is woefully unfit for purpose and the vast majority of computer science graduates cannot be assumed to have any practical knowledge of the subject.

This was as of about 5 years ago, so maybe things are changing.

5 years in china is equivalent to 15 years in the outside world. Things have definitely changed.

So China is the heavenly palace and the rest of the world is earth? What will Sun Wukong think?

It is the other way around. "Year for three" is a staple of hard work in harsh conditions, such as foundry work.

Honestly, this genre of venting about new grads has long been applied to new grads here in the West too. It's a long-standing complaint of the industry that academia isn't willing to serve as vocational training.

I mean sure, but most of the time Comp Sci degrees have Freshman compiling code on day one. This is a pretty be qualitative difference if the above comment is true.

I took a freshmen level C/C++ class in community college as a requirement to get an Associates in Science. All we did was compile. We didn't learn any high level CS theory.

My mother's friend's husband is a math professor at a university in Kansas. A major complaint of his is students coming in who aren't able to add fractions.

So I don't see the big qualitative difference between complaints about bottom-end Chinese college students and complaints about bottom-end American college students, no.

If it's of interest, I looked into gaokao test scores a while ago and the cutoff for being admitted to a Chinese university lies around the 40th percentile. The schools are officially divided into two tiers (obviously, there are finer distinctions you can make), and the cutoff for the higher tier is around the 80th percentile. So a large number of Chinese universities should have almost the entire student body within what you might think of as an IQ range from 96 to 112.

Your mother's friend's husband is a math professor who complains about the quality of Freshmen entering into a math course, therefore the quality of computer science students in the United States are on par with the one's in China. Do you see a problem with this logic?

Having interviewed new grads from the west and new grads in China, I can guarantee you that a lot of the new grads in China had had exactly the education the OP described and were completely unable to do anything. It's not just venting, it's the reality.

There are some great universities in China and there are definitely some who know their stuff but the average mid level university in China? Nope, completely useless.

To be fair, this was in 2009 to 2014. I have left China since.

> I can guarantee you that a lot of the new grads in China had had exactly the education the OP described and were completely unable to do anything. It's not just venting, it's the reality.

Isn't it the foundational concept of fizzbuzz that a lot of applicants to programming jobs are "completely unable to do anything"?

FizzBuzz isn't a programming challenge for interviews anymore, that was like ten years ago. Now its more like a data structures and algorithms exam.

Did the observation that "hey, a lot of our applicants can't even do anything" become less true?

Hell if I know, if I'm going to be frank I responded more from stress and wishing FizzBuzz was still a common test than anything.

If it's still true, then why do the tests get harder and harder?

FizzBuzz was never a programming challenge, it was just a very quick filter before getting to real challenges.

Real tech interviews have always been about understanding and applying data structures and algorithms, with some emphasis on problem solving with those tools.

A really long time ago, there used to be questions that were more like "do you know some very common C/hacker idioms", like write a one line strlen or reverse a linked list in place. I used to get asked stuff like that in the late 90s.

(There were also the brainteaser style things, like how many golf balls fit in a 747, but those were often for non-programming roles where people were looking for your ability to problem solve in a vacuum with little information. Those were rarely aimed at engineers, but at engineer adjacent non-technical roles.)

We're not talking about graduates not able to solve theoretical exercises. These graduates might well be able to solve an on-paper algorithms exercise like that, after all their teaching and assessment was all theoretical.

The problem is they don't know how to actually compile and run a "Hello World" program, or write and run any kind of program on a physical computer, because they never had to do it as part of their computer science education.

I've never really done traditional interviews, but is this true? I've been able to do a fizzbuzz since I was like 14 years old :/

https://blog.codinghorror.com/why-cant-programmers-program/

(internal link to https://www.joelonsoftware.com/2005/01/27/news-58/ )

I realize this may have changed, but at least at the time, was this partially due to access to computers at the university (i.e. lack of funds for computer labs)? Or just prioritizing the theoretical side?

I think it was both of the factors you mentioned but also due to the fact that in early/mid 2000s, China increased the number of university student by an order of magnitude (almost ten fold). This caused some growing pains in universities in the late 2000s beginning 2010s which means that in the race to hire enough teacher to fill demand, not every teacher was competent (I've met some remarkably incompetent CS teachers when visiting universities) and there weren't necessarily enough funds to handle the influx of students.

It was common knowledge that people who had graduated before 2004-2005 tended to be much better candidate and had received a better education. In the end, it was necessary for the country but any big systemic changes like this cause growing pains. I do not know what the current landscape in China is nowadays, I would assume that this is much less of a problem since time probably helped with those growing pains, on the other hand, as the PRC starts creating tighter and tighter restrictions, the best elements might be more likely to want to study abroad.

The Chinese attitude to academia is very different to that in the West. This distinction you draw between the academic and vocational goals of institutions just isn't really a thing over there in the same way.

Which is crazy. No University can teach the kind of skills needed to be a good commercial developer.

The best approach would be apprenticeships; learning the craft while doing the job. But the industry has always been ridiculously opposed to training its own staff - echoing your point that this is seen as something that the education system should do (why?).

I've heard managers say crap like "but if we train them then they'll leave us when they finish the training and go somewhere else - we'll have paid for their training and get no benefit". This is a staff retention problem, not a training problem.

> Which is crazy. No University can teach the kind of skills needed to be a good commercial developer.

You sorta can.

https://missing.csail.mit.edu/

I've also met grads that basically had a dedicated software engineering class where they learned: What's a package manager, build system, how to compile C++ code (linking and compilation), makefiles, agile, waterfall and source control and a few quality metrics to look out for.

The tech skills, maybe. But does the course cover stuff like "How to deal with a project manager who has no clue what they're doing", or "How to manage expectations in a customer who is way overenthusiastic about their new idea for a feature", or even "How to deal with Aspy Dave who thinks he's a rockstar 10x coder but actually churns out buggy crap that the rest of the team have to fix".

The non-tech skills of how commercial software development actually works in an actual organisation are really important, and the only way of learning them is on the job.

I almost feel like this is a place for a corporate onboarding/training process.

I'm mentoring a new developer at my firm. He's fresh out of college. His code works on a basic level. The things he's stubbed his toes on:

* Naming conventions. We have probably more rules about this than some, but things like branch and commit names matter because we tie them into our issue tracking process.

* Strictly reading specifications. We had a couple days rework because he used a different suggested name for something, and it ended up propagating into dozens of class names.

* Knowing when and what can be cleaned up. This I can forgive, as it normally waits towards the end of the project and he isn't quite there yet, but when we paired to work on it, there was a lot of leftover baggage.

* Bulletproofing/exhaustive coverage. I suspect there's a lot of university projects where "what if the remote server hands us HTTP 418" is answered by "the test service doesn't".

* Multiplayer and advanced Git. "The main branch is going to update without you, and eventually there's going to be merge conflicts" and you'll need to merge/rebase was a problem for him, as was dealing with a feature branch with multiple task sub-branches (keeping too many of them open at once is a huge risk for weird merge conflicts and hideous histories when they're finally resolved).

> I've heard managers say crap like "but if we train them then they'll leave us when they finish the training and go somewhere else - we'll have paid for their training and get no benefit".

The clever response to that is: but what if we don't train them and they stay?

I'll say this: programming isn't a profession. If I was being particularly unkind, it's more like a collection of wild west gunslingers.

It probably won't be a profession either until we've settled the whole C++ vs Rust vs Lisp vs JavaScript vs $LANGUAGE_DU_JOUR debate, and stopped acting like egotists. "Rockstar programmer" is a problematical phrase. What it tells us is that programming is one big dick-measuring contest.

I trained as a UK chartered accountant, having graduated in mathematics. I had to go through a set of professional exams. I was under a training contract, started as a junior. I couldn't sign audit reports. That was for the partners. My work was reviewed, and as I moved up through the ranks, I reviewed others. When I was a senior, the juniors asked me for advice. When I finished my work, I spoke to a partner, he reviewed my work, and I reworked whatever was necessary.

There was also "calling and casting". After the accounts were typed up, a more junior clerk would have an old copy of the accounts with corrections, and the more senior clerk would have the revised copy. The junior clerk then read aloud what was on the accounts, and the senior checked it against his copy.

See that? Professional. I imagine lawyers, engineers and manifold other professions have similar appropriate procedures.

What do us programmers do? Release our shit onto the world and fix it later via patches. And issue licences that say we take no responsibility for the fitness of our programs.

That's why I call what we do gunslinging.

Maybe one day the queen will create an Institute of Chartered Programmers, but that day is not only far over the horizon, it's not even in the same solar system.

> It probably won't be a profession either until we've settled the whole C++ vs Rust vs Lisp vs JavaScript vs $LANGUAGE_DU_JOUR debate

I don't see how it's a debate. Different languages have strengths and weaknesses.

> and stopped acting like egotists. "Rockstar programmer" is a problematical phrase. What it tells us is that programming is one big dick-measuring contest.

And yet law is extremely bi-modal. It's not surprising software is similar; you can't argue the average offshored programmer is in any way similar to John Carmack for instance.

> See that? Professional. I imagine lawyers, engineers and manifold other professions have similar appropriate procedures. What do us programmers do? Release our shit onto the world and fix it later via patches. And issue licences that say we take no responsibility for the fitness of our programs.

Sounds like you are hiring wrong. You are hiring programmers and then whine they aren't acting like engineers. Software Engineers have code review, proper release pipelines and methodologies. The bargain-bin programmers don't, of course.

Accountancy has been around for a few hundred years. Lawyers longer. Eventually what you wish for will be true.

But I'm not sure I'd want to work in that industry. I like that I can just start hacking away at something that I think will work and create value.

> The clever response to that is: but what if we don't train them and they stay?

Not really. I mean, I get the reference and it is smart. But we're talking about why most tech companies don't hire juniors and train them up. Instead they prefer to hire seniors, not provide any training, and lose them after two years because they can't give pay rises over 5%.

And my impression of "professionals" is not nearly as good as yours. I've seen "professional" managers behave like egotistical idiots way more often than devs. My first startup was destroyed by a "professional" accountant behaving wildly inappropriately. The last time I was a CEO I was quietly informed that I should get a new desk because the previous CEO (an accountant) had a habit of humping hookers on it during his lunch breaks.

I have been told, anecdotally, that German college curricula are very "vocation-based," with students being quite well-versed in the needs of the workplace upon graduation.

I've been fairly impressed with the Germans that I've worked with, but that may be sample bias.

There are vanishingly few good programmers anywhere. SV has more because it attracted them from around the world.

In my experience college education has nothing to do with who is really a good programmer. Sure MIT grads are better than average, but that's because they have a reputation to attract the people that are the most interested in it. CS fundamentals definitely make you a better programmer and able to solve harder problems, but it's somewhat orthogonal to the daily grind of keeping a mental model of a large obtuse system in your head while solving hundred arcane micro-hurdles one after another.

Eastern Europe and Israel seem to have a decent proportion.

My hypothesis there would be cultural factors drawing out a greater percentage of those with the potential.

In eastern europe it's pretty simple. The collapse of the soviet union left a strong education system and also poverty. Learning to program is one of the most straightforward and doable ways to a good income, so lots of people do it.

Israel is probably a knock-on effect of that, since most (jewish) israelis are (or descend from) eastern european migrants.

> most (jewish) israelis are (or descend from) eastern european

That's a popular, but unfortunate misconception. Majority of Jewish Israelis are Mizrahim that immigrated from middle eastern countries, running from persecution by Muslims.

Huh, thanks. Wiki says it's about 50/50, fwiw.

> SV has more because it attracted them from around the world.

There's also a filter here: To immigrate to the US as a dev you need to be able to secure a job as a dev, and the employer must be willing to sponsor you.

That puts the bar way higher.

I hear this often and I realize that there are not enough programmers to meet the demand, however I have seen estimates of at least 500,000 software engineers working for large tech companies in the United States. It seems like that is a large number of people that presumably passed difficult algorithm-based interviews. Are programmers really that rare in this day and age?

> I have a friend that heads a computer science department at a regional university in China. He's an old friend of my wife. The vast majority of graduates from his department have never run a single line of code on an actual computer. The teaching and assessment is 100% theoretical on paper, and this is typical.

At a regional Chinese university you are basically looking at those who couldn't go abroad and to the tier one institutions. And same thing for the TAs and teachers there.

That doesn’t really work except for the lowest quality tier, because tired workers make mistakes, and mistakes cost time. Automate more to remove the human factor, and the remaining people need to be more focused, not less. There is a sort of maximum amount of net useful work you can get out of a person, taking into account slacking off and correcting for errors, and for most people that is not working 996.

> Also by its nature spending more time on a piece of code doesn't mean you'll be more productive (in fact I've found the best way to deal with a bug is often take a break and come back and reread your code likely you'll spot the mistake far more easily).

Or realize you don't need the code at all and there's a way to do it better.

Coming out of one of those 996 companies, I would say that most of my working time are wasted.

I would do almost nothing in the moring. I did most of my work in the afternoon. In the evening I just pretended to be working.

Forcing a real 7.5h day would not hurt most companies. But it would hurt the ego of middle managers, who want to prove that their teams are trying their best by working long hours.

yeah I am skeptical that people are putting in full 12 hour days

I am working 40h in a Middle European country and think that a lot of my working time is wasted.

Somewhere between 20h and 30h and a 4 day working week would be best for performance imo

I agree, and I'm in Toronto, Canada.

I genuinely believe a 4-day work week is the way to go. It's Friday and I'm already burnt out at 11am.

My experience is that the burnout and wasted time comes from all the crap that distracts from real work -- the meetings, emails, bug boards, etc. When I don't have all these things getting between me and the IDE, I'm far more productive and get a lot more enjoyment from my work. Of course, if all the crap were cut out, I'd probably be looking at two days of work per week, never mind four.

In the past several years most of the burnout and wasted time I’ve experienced has come from libraries, frameworks, build/CI systems, architectural patterns, and so on that simply suck, or at the very least fail to properly work together. Unfortunately, they’re all mainstream technologies that people seem to think are perfectly okay, and that fighting against your tools simply in order to develop good solutions to the actual domain problems is just what coding is supposed to be.

I'm genuinely curious which of those items you consider as sucky and why. I am asking because I've recently been moved from a C++ to a JS team at my current workplace, and now I am exposed to this wide range of new tools which are all alien to me.

But moving to a 4 day week doesn’t eliminate any of that, it simply means you’d get less done.

If we adopted a four day work week do you think people would feel a burned out feeling at Thursday at 11am? I honestly _don’t know_ and think some long term experimentation is needed

I honestly don't think I would. I am exhausted by Friday and then the weekend is basically just Saturday so there's hardly any time to recharge during it.

I'm not burnt out on Thursdays. I feel empowered. That said, I've only been on a 4-day work week for a month and half now.

Not nearly enough time to adjust. Any job switch the first month is like the honeymoon phase.

Possibly, but at some point it has to stop, right? Take the extreme example of working 4 hours, one day a week. If you are even marginally interested in what you’re doing, I can’t imagine anyone feeling burned out by that. I just don’t know what the threshold is (and it’s certainly different for different people). A lot of it probably has to do with how busy people’s lives are outside of work, and if they feel like they’re able to manage their lives at least somewhat stress free.

Yeah it would have to stop obviously. But let’s take it the other way! Do you think working 20 hours a day 7 days a week is optional efficiency? We need to find the right balance!

Who cares. Even if I feel just as bad during the week, I have more weekend time. That's worth it.

We don't have a worldwide labor shortage (!). Productivity going up and work hours not going is a travesty.

There's a labor shortage in US right now. You can feel it everywhere: from having to book car mechanic appointment weeks in advance to construction projects going to standstill.

And there's also millions of people that could be working but aren't:

https://rooseveltinstitute.org/wp-content/uploads/2021/07/RI...

Further, low labor productivity and bad on the job training pipelines directly result from squashing uppity labor

https://phenomenalworld.org/analysis/construction-labor-shor...

Everyone I've ever known has loved working 4 10's and honestly 4 8's would be even better. They never complain about burnout and a 3-day weekend every week leaves them energized and recharged for the next weeks' work. I only ever hear complaints from people working 4 12's which at that point you'd hear the usual complaints of anyone working 8 hours of overtime a week.

The fact I've never once heard a complaint about 4 10's from anyone I've ever known to work them says a lot compared to the usual 5 8's which I hear complaints from about everyone (including myself).

n = 19~21 people or so

I've recently negotiated a 4-day work week with my employer. It's been a huge quality of life improvement. Whether I make $80k/yr or $150k/yr, it doesn't matter as much to me as quality of life. Maybe I'm an outlier, but money isn't everything.

If smaller companies can't compete on the huge salaries and options that larger companies provide, they can certainly compete on flexible work schedules. A developer working 4 days a week is pretty much just as useful to me as the engineering manager as a developer who is working 5 days a week. Budget and schedule.

if everyone does it, labor will become more scarse, and wages should go back up too to recover the some or all of missing 1/5, so please everyone do this!

Only if total production goes down. If productivity increases enough to compensate (what really looks like the case), it should have no impact on wages.

> If smaller companies can't compete on the huge salaries and options that larger companies provide, they can certainly compete on flexible work schedules.

They certainly can compete. Just raise more or adopt a stock comp model.

Not all companies looking to hire devs have massive injections of VC money to play with.

Tech at this point is needed to some degree in lots of products.

Maybe they need better founders.

I’ll play devils advocate. Say you work 40 hour work week with 20 hours of “productive” time. If we moved to a 30 hour 4 day work week would you actually only have 15 hours of productive time per week? I say this because I don’t think all the non productive parts of working life would go away, instead we would just get less done.

So how do you spend those morning and evening times? It just seems depressing to have your butt in chair all those hours doing nothing...?

Same way people have been doing it for decades.

Chit chat with your friends online, have a cup of coffee, spend 30 min listening to an audiobook or reading. And hey, what do you know, it's lunch time already!

Yep. Your writing makes me miss the morning coffee. I used to have a lot intereting talks beside the coffee machine. Coffee was better. Now I have to drink cheap instant coffee alone.

I read Hacker News and Reddit, or read tech docs, or write some code, or talk with friends. Then I quit. I am making a Reddit for China now. I want to help all those boring souls like the old me :).

It is truly depressing. I would never go back. I earn 1/20 of my old salary as a solo developer. I can't make ends meet, yet. But I would never go back.

Paul Graham wrote somewhing like, if you fail, you would have to go back to those boring companies. This fact provides a lot of motivation. I can't remember the exact phrase. But yes, that's exactly how I feel.

Good luck, my satanic potato friend.

Maybe you know, but if you do not; 666 is a lucky number in China. I was surprised to see the number of beast everywhere when I first visited ShangHai & Suzhou, while it's very rare in the west.

From wikipedia: "In China the number is considered to be lucky and is often displayed in shop windows and neon signs".

> read tech docs, or write some code

How's that not work? I suppose you meant write some code not for your work, but reading tech docs is ABSOLUTELY part of your job...

I worked at a US company that wanted us to put in the extra effort and do work after hours. They tracked this with a summary report of work submitted after 5.

So I worked normally and then I'd sit on all my work and wait until just after 5:15 to submit it all and then leave immediately. I didn't get in until 9:30 or 10 anyway so there was literally no difference except my work was delayed.

They praised our team for all the extra work. They really had no clue.

This is a perfect example of "you get what you measure."

I worked in an Asian country that was notorious for it’s “always on” work culture.

What I realized is people just created their own down time during the work day. The attitude was “if you want me available from 9am to 9pm, then I’ll just just a 2hr lunch, a 1hr dinner and a bunch of 30 min coffee breaks”. They end up doing about 6-8 hrs of actual work. And on top of it end up with a really resentful attitude about their work and boss as well.

Far better to find competent, motivated (not rah-rah, but more like “lets just get it done”) people and tell them what you need done and leave it up to them how to do it.

> The company I work in now has no problem competing with Chinese companies working 996, despite us working 7.5h days and having way more vacation days.

My previous employer rushed to open offices in China because the CEO was convinced that 996 and China’s lower wages would double our productivity while cutting costs in half. They opened an expensive office and got recruiters to hire well credentialed people.

Despite having twice as many people and supposedly working twice as many hours, they struggled to deliver comparable work. We spent a lot of time fixing the work that came out of the 996 office in China.

Don’t get me wrong: There were some talented people in that office who I enjoyed working with. However, the 996 schtick always felt more like a performance art than actual productivity technique. The CEO was ecstatic that he could ask a question in Slack at any time day or night and within minutes they would all respond with many enthusiastically positive Slack responses. Whenever they talked about accomplishing something, they made sure to specifically mention that they accomplished it late at night or on the weekend. They seemed to send more e-mails on Saturday than any other day.

But they weren’t actually doing as much as you’d expect for as many people as they had and as much as they claimed to be working. Their code was notoriously unpolished and was often submitted in “good enough” form as soon as they got it to compile or work enough for demos. We also had strange problems with a lot of employees who were trying to use company resources to do freelance work for other companies, assuming we wouldn’t care or notice.

Unfortunately, their 996 performance worked on the CEO for a while. He was convinced they were our highest performing, most dedicated office. It took several years of buggy software and imminent product launches that never materialized for management to realize that they weren’t actually getting more work out of that office, contrary to their impressions.

The lesson is that you get what you reward: If you try to build an office or company around rewarding people for the appearance of long hours and weekend work, that’s what you’re going to get. If you build the culture around expectations of solid software shipped reasonably fast, people will start figuring out how to accomplish that within their own time.

The performance of working long hours has been a staple of Chinese culture for many years (and Japanese culture, while we're at it). And everyone knows it's a performance.

The number of people that come into the Samsung HQ on saturdays, just to take a 4 hour nap and then go home is staggering.

Reading this post gave me a tremendous feeling of anxiety.

I work in China but european company so 965, pretty nice.

The problem as always is: will they deeply want to solve the issue because they understand it, or is it instead now illegal to say that you work 996? :D It's not the same thing: I hope it wont come to that, but sometimes top down systems like ours create the appearance of the result before the result itself.

My former colleagues who was trained for PSP/TSP said that it is recommended to count on 4 hours per day in time-on-task activities. Planning for more ToT hours will result in project being late as if it was planned for 4 hours/day ToT and people will have to work overtime (weekends).

I have to say that remaining 3.5-4 hours are spent on other tasks like documentation reviews, etc.

For time being we can assume relationship of performance regression is 4/ToT if ToT more than 4. This means that these Chinese workers perform 3.5 less work per hour or even less so. One can try to compensate by hiring more workers, say, 3.5 more workers but then the amount of communication will increase quadratically and there will be more than 12 times increase in communication needed for team(s) to work.

That means that "996" policy results in great underutilization of people's potential. My napkin calculation is that each "996" worker performs less than 1/30 of what he/she can do.

Regardless of culture, it is sad.

Documentation is time on task.

I haven't written a lot of documentation, would you say that it requires the same level of mental focus? I understood the dividing line of 'time on task' as being what is difficult/taxing, whereas admin or docs (important tasks!) are relatively light weight.

I would; it’s a bit like teaching. For general documentation you need to refresh your mental model of the system and organize it to be explained to somebody without your familiarity. For specific areas (APIs, for example) you must review the assumptions in that domain and summarize them.

Writing _good_ documentation absolutely can be just as tiring as creating the thing being documented. It's quite common to not particularly value documentation quality and be happy with a mess of words churned out with little thought because at least it exists, but ensuring that it's accurate, covers all of the little details, and is organized well requires some careful thought and editing processes.

With a formal division between "deep thought" work and "easy" work, I'd be inclined to churn out a rough draft of documentation in the second time box but then spend at least as much time as that in the first time box cleaning it up.

TSP/PSP makes no task differentiation according to what is difficult. If it directly relates to project deliverables, then it's considered time on task.

I'd say that documentation that is expected to be used is every bit as difficult to create as good code.

Sensible working hours and good productivity require good management. Working extended hours like "996" is just brute-forcing results.

You need teams with clear objectives and project plans so employees are able focus on a task without getting side-tracked due to too many responsibilities or bad planning.

This shouldn't mean that agency or creativity is removed, it's simply about providing the right environment for people to work on complex problems.

I suspect people going home, working out, living their lives, decompressing, and relieving stress would increase productivity.

I'm not screwing caps onto bottles, the number of hours I work has NOTHING to do with how much I get done.

I get 80% of the work done in 20% of the time, the rest is gathering information.

Depends on the job. Most manufacturing jobs is done on a conveyor belt. More time is more stuff.

It's different job from software engineering. More time doesn't lead to more stuff.

Also not true with manufacturing (btw software engineering is manufacturing too). More time = More errors = More damaged Machines = Worse QA etc....it's the same as with software.

Many factories, utilities, and other tricky hw like 24/7 b/c less restart errors

Blind men and elaphant? :)

We talk about humans NOT the Machines, Servers are 24/7 the admins are Not...i hope ;)

Those facilities are also typically running three shifts, whereas you seem to be implying it is common for individuals to be working.. 24 hours a day, 7 days a week.

24/7 would usually be four shifts. The most common schedule is for each shift to run 12 hours, working three days one week and four the next, for a total of 84 hours per two weeks.

Three shifts works well for 24/5, each shift running eight hours a day.

Thanks!

Hospitals prefer 12 hour shifts for similar reasons. Their "restarts" are called "handoffs". A tired nurse in hour 11 of their shift is less dangerous than a fresh nurse who doesn't know everything that didn't make it into the patient records. There's a large body of research into handoff errors, and the lessons have mostly been put into practice. Unfortunately, this doesn't seem to be the case in "knowledge" based industries where failure isn't as easy to measure as death and malpractice lawsuits.

Wouldn't the handoff suffer more at the 11th compared to the 8th hour. I wonder if they take employee constant sleep deprivation transferring into patient experiences vs legal coverage when making these decisions.

The trade-off is whether patients see tired staff vs patients rotate through more staff with no context (= multiply chance of onboarding mistakes, more delays, ...). Tempering this a bit, a lot of smaller-staffed late shift care is more about handling emergencies and otherwise keeping folks fine until the bigger day shift comes in.

Most software IT/ops is luckily generally much smaller in time scale of most incidents, and much more tolerant of hand-off errors and delays. Ex: For 24/7, you get an instant email acknowledgement of ticket receipt, someone triages it, and if on a boundary, OK for current shift to ignore and leave for the next one. Likewise, for bigger incidents, better for throughput for the same person to pick across shifts to avoid hand-off errors, even if that introduces delays when it spans shifts. But not universally true across orgs, nor for incident types. Ex: For tricky & sensitive incidents that take 8-24 hours, the hospital results show longer shifts might make sense, so I'd want to see experiments before making assumptions!

> More time is more stuff.

That's the Taylorist position, but I think Deming would like a word. And in the more sophisticated manufacturing world with shorter more bespoke runs, the problem-solving ability of your employees and their time spent performing non-recurring setup matters as well.

> Most manufacturing jobs is done on a conveyor belt. More time is more stuff.

The 40 hour work week actually comes to us from research on the original assembly line. Henry Ford's analysts apparently concluded that 40 hours was optimal for overall productivity. Past that point and the cost due to the greater number of human errors more than canceled out the additional work.

I would wager that this optimal number is different for different people but also for different professions. In professions where fatigue doesn't result in more mistakes or mistakes are cheaper to rectify then the "optimally productive" hours per week might be higher. In professions where fatigue results in even more mistakes and mistakes are more expensive to rectify then the reverse might be true.

And this says nothing of the leverage of the workers themselves -- I suspect software engineers can get away with working fewer hours if they want to due to the fact that they have more leverage than most workers.

I'd imagine the system is probably similar to Japan where they stay at the office a long time but don't work for most of it. Unless China has something special in the water it's not really possible for knowledge workers to be highly productive based on more hours worked.

I don't know a lot about how the 996 culture came to be but it makes sense to me that is you're a country that is heavily invested in manufacturing goods you could enforce something like this and it would equal a boost in goods produced. But once a large portion or eventually a majority of your exports are high skill knowledge based work (like programming) then the returns will diminish as has been reported many times over the years.

This may just be a natural change as China shifts its core export.

I think there is no way 996 work culture improves productivity. Working that long only causes burn out which makes developers slower and more prone to mistakes, and with more mistakes leads to more effort devoted towards fixing those mistakes.

Personally, my productivity varies greatly depending on my mental state, days when I am feeling fresh/sharp/motivated I can accomplish more in a few hours than I could over days burnt out, and the resulting code is more resilient and thought out than I anything I could produce burnt out. When I am burn out, my mind is foggy and less able to reason about various branches of the program and I am way less motivated.

IMO like other posters have stated, 996 culture is less about productivity and more keeping up appearances with management. In China/SK/Japan you don't leave until your boss leaves, even if your work is done, so you will see people staying late a work shopping online or playing video games. The more the office becomes your home the less productive of an environment it becomes.

This is an insightful comment.

Very long working hours are very often associated with inefficient companies that are built on micromanagement.

What is the root problem of 996?

The crack down on after-school tutoring is mainly to drive the capital away from it, it is not designed to eliminate every single after-school tutoring. CCP does not want the after-school tutoring to be a lucrative business for unicorn IPOs.

A bit of a tangent, but how would you change the gaokao system? It's certainly a huge strain on the child, but I'm not sure how to design a different system that allows a similar level of class mobility and fairness either.

I would think they will become more productive. I love working hard but working hours have dependency when it comes to being unproductive.

That many hours is just hard work signaling or some kind of test of commitment.

Working that many hours is ultimately a cortisol problem that only less work can solve. This is obviously sub-optimal.

Anything China ever seems to do is rather smart and reasoned so I assume they have just figured out this makes no sense and will lead to an increase in productivity.

> Anything China ever seems to do is rather smart and reasoned

Not sure if this was meant as sarcasm? China imposes their fair share policies that are shortsighted and eventually self-destructive, the same as almost all groups of people larger than 0.

Are yours 7.5h in the office or hours of work? Just curious whether they include lunch and breaks.

Working overtime is usually an antipattern

> an antipattern

Not clear, could you explain?

I think the poster means that it's a symptom of (and a temporary solution to) underlying issues.

Sometimes I have to do a bit of overtime to fix a time-sensitive issue, and I'm fine with that. The underlying issue, though, might be lack of code review, insufficient testing, fatigue or anything else.

It's good to remember that overtime is a viable solution, but as any solution it has its costs. This can build resentment among employees (making them quit earlier), increase fatigue (this requiring even more overtime to fix issues caused by fatigued employees), build dissatisfaction (resulting in loss of motivation), etc.

In other words, if you're finding yourself plumbing leaks every week, a better solution for the long term might be to replace the whole pipe :)

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

https://en.wikipedia.org/wiki/Anti-pattern

There are two reasons to use OT (IME):

The occasional and unpredictable issue. Construction crews took out the internet for half the city (happened to us a few weeks ago, maybe not half the city but it was bad). This broke a lot of communication systems (how can you deploy your work even working remotely when the systems you need aren't reachable?) and other things. Once service was restored, this forced a scramble the next week to get things done that had to be delayed and also hit the expected deadlines for that week (or risk a cascade effect of everything being delayed). One week of OT for a few people, everything was back in order. This is rare, unpredictable, and so not an anti pattern. It's a thing that happens.

Regular OT is the anti pattern. If your team is working long hours every day, regularly coming in on the weekend, if deployment always runs long and the team has to stay all weekend (even if this is an annual thing because you didn't get the memo on CI/CD), you have a problem.

It could be understaffing. It could be just lousy work. Working long hours seems to induce a decline in quality on its own. It could be a cultural problem. It could be abuse of the system (especially if OT is paid at a higher rate). It could just be bad processes. But regardless, if it happens regularly it warrants investigating.

Except for maybe rare exceptions of temporary pushes to get a project further along, working overtime is more of a symptom of mismanagement, than a sign of dedication.

The days just keep coming. You need downtime, and off days. There's a strong case to be made that we don't get nearly enough, at least in the USA. Trying to mortgage that time because you didn't set appropriate goals, have appropriate staffing, or make good use of your time will only result in burnout. Often times you don't even get the extra work, because productivity goes down, but everyone must pretend to work, so they're not one of the bad ones.

You will pay for these mistakes eventually. You will not be able to retain people. They will leave, end up in the hospital, or have a meltdown and get fired. Or everyone is just miserable, but things go the same speed, or slower.

Reply on news.ycombinator.com