The state of Amazon's blue collar working conditions are widely considered to be crap of course, and there are a lot of complaints about labor laws, unions, outsourcing and immigration, etc. I didn't quite see how he connected the issues in the post though. I mean beyond state of labor = not good (and maybe that's all you were saying too).
What's really grating is that these people and "low skill" jobs that form the backbone of our functional society have been abandoned by the political movement they bled to create (which is obviously now hijacked and totally perverted by the ruling class).
It makes me cringe every time I hear a "left" wing voter or politician boast about how much the uneducateds dislike them, and gloat about how worthless those people must be to be concerned about immigration policies affecting their jobs. It's no surprise their lot is not improving. I only hope they can band together and affect real change again before the ruling class is able to irrevocably divide people against one another. Maybe it's already too late :(
What's interesting though is I don't hear a lot of people on HN complaining about CI/CD, which IMO is part of an overall approach that treats devs like cogs in an automated process.
In some ways, I think we even celebrate it because, as devs, we are the automators. But increasingly, we're becoming more beholden to the processes we've automated.
The problem is that there's an expectation that this increase team velocity more than it increases quality of living.
15 years ago in IT if you could automate things, you just ended up with less active work to do. Now that automation is the norm instead of a bonus cool thing, it has become formalized and measured, and you may not have the saved time as free time, you have to now double down on doing the hard parts of the job.
This doesn't actually work in reality for most people as we can't actually think hard for more than a few hours out of the work day (10x'rs exempt, of course.)
True. OTOH, I feel like some version of this is always sold as the worker-facing rationale for automation and increased productivity. For some jobs, it's "hey, we're going to automate your job away so you can go do something meaningful with your life". For devs, it's "we're going to automate this for you so you can focus on meaningful work here".
>The problem is that there's an expectation that this increase team velocity more than it increases quality of living.
That's it in a nutshell. The "gains" don't accrue to devs, but to the never-ending hunt for still more productivity.
And, I think that's a feature; not a bug. That is, from an organizational perspective, agile and all that it's ushered in (including devops and CI/CD) were never intended to improve dev quality of life. Instead, they're all about the highest LOC in the minimum time, a.k.a "productivity".
I dont disagree with your observations, just saying "productivity" gain is pretty far down the list of benefits to me personally
>"productivity" gain is pretty far down the list of benefits to me personally
Yeah, in reply to the other comment, I was saying that automation from an organizational perspective is not so much about improving the quality of life for devs, as it is about increasing their productivity.
The entire concept of how people do code-reviews with PRs is completely broken and everyone's experienced it: when someone leaves a review, asking you to change a variable name, what is even the process? Can I just say "no"? Why didn't they with full access to the branch, just submit the commit? Or open a PR against the branch (did you know you can do that?)? Why aren't code reviews just cherry-pickable commits against branches by default? Why doesn't the PR process let me do a partial rebase as acceptance? Why does everyone do code reviews looking at diffs, when they can't possibly have enough context? (its because the tools are junk and make it difficult to do - I had an idea of doing some line number magic to do full-code commenting in gitlab review mode, but never got round to it).
Like...the situation is about as bad, we're all just salaried.
>Why didn't they with full access to the branch, just submit the commit? Or open a PR against the branch (did you know you can do that?)?
As for some of these why questions, I think the answer is that they want to enforce that you follow the process. I've seen people get cartoonishly bent out of shape over exactly this kind of stuff, "you're supposed to do x!". It's part of how devs are "automated".
Given enough time, and a smooth process, eventually this should not be so painful; but when it is painful, it is supposed to be the job of a human (especially once in HR) to act as a bridge between process and person, so as to keep morale at a good level and to provide a channel for feedback from employees up to the teams responsible for process automation. It doesn't sound like this is in place here, at all; instead we have people who are displaying all the signs of not caring about the human anymore because they have become so subservient to the machine that they cannot afford to.