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.
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.
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.
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.
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.
Israel is probably a knock-on effect of that, since most (jewish) israelis are (or descend from) eastern european migrants.
That's a popular, but unfortunate misconception. Majority of Jewish Israelis are Mizrahim that immigrated from middle eastern countries, running from persecution by Muslims.
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.
Isn't it the foundational concept of fizzbuzz that a lot of applicants to programming jobs are "completely unable to do anything"?
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.
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.)
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 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.
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.
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 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.
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.
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).
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.
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.
I've been fairly impressed with the Germans that I've worked with, but that may be sample bias.
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.
Or realize you don't need the code at all and there's a way to do it better.
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.
Somewhere between 20h and 30h and a 4 day working week would be best for performance imo
I genuinely believe a 4-day work week is the way to go. It's Friday and I'm already burnt out at 11am.
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.
They certainly can compete. Just raise more or adopt a stock comp model.
Tech at this point is needed to some degree in lots of products.
We don't have a worldwide labor shortage (!). Productivity going up and work hours not going is a travesty.
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...
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
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.
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.
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.
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...
From wikipedia: "In China the number is considered to be lucky and is often displayed in shop windows and neon signs".
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!
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 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.
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.
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.
I'd say that documentation that is expected to be used is every bit as difficult to create as good code.
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'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.
It's different job from software engineering. More time doesn't lead to 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.
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.
Blind men and elaphant? :)
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!
Three shifts works well for 24/5, each shift running eight hours a day.
This may just be a natural change as China shifts its core export.
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.
Very long working hours are very often associated with inefficient companies that are built on micromanagement.
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.
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.
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.
Not clear, could you explain?
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.
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 :)
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.
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.