3 ms·

>automation (and I mean mainly business process automation) has sucked the humanity out of work What's interesting though is I don't hear a lot of people on HN

>automation (and I mean mainly business process automation) has sucked the humanity out of work 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.

mikewave 5y ago
The big difference here is that CI/CD should ideally be taking away annoying work from devs so that they can more smoothly go from problem/feature -> hard thinking work -> code -> out the door, without having to deal with the highly repetitive part of the job. 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.)
- unclebucknasty 5y ago
  >The big difference here is that CI/CD should ideally be taking away annoying 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".
  - kilobaud 5y ago
    I dont automate CI/CD because I'd rather be sword-fighting on roller chairs, I automate because I value the cost of my own work time and truly would rather spend it on a more interesting problem. (To say nothing of the fact its all too easy to make mistakes where processes arent automated, and I dont enjoy making mistakes) I dont disagree with your observations, just saying "productivity" gain is pretty far down the list of benefits to me personally
    - unclebucknasty 5y ago
      Mine is not an "automation = bad" position. Obviously, it has value. It's more to say that automation is frequently implemented in a way that treats devs as just another part of an automated pipeline, not much different than software. >"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.
XorNot 5y ago
I don't know, my general rant on why all CI/CD is complete junk and everyone is cargo-culting a copy without an original in implementing it just never feels like something I want to post over and over again. 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.
- unclebucknasty 5y ago
  I'm laughing because it seems every company has some variation of this kind of madness. They're like flavors. >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".

mikewave 5y ago

The big difference here is that CI/CD should ideally be taking away annoying work from devs so that they can more smoothly go from problem/feature -> hard thinking work -> code -> out the door, without having to deal with the highly repetitive part of the job. 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.)

unclebucknasty 5y ago
>The big difference here is that CI/CD should ideally be taking away annoying 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".
- kilobaud 5y ago
  I dont automate CI/CD because I'd rather be sword-fighting on roller chairs, I automate because I value the cost of my own work time and truly would rather spend it on a more interesting problem. (To say nothing of the fact its all too easy to make mistakes where processes arent automated, and I dont enjoy making mistakes) I dont disagree with your observations, just saying "productivity" gain is pretty far down the list of benefits to me personally
  - unclebucknasty 5y ago
    Mine is not an "automation = bad" position. Obviously, it has value. It's more to say that automation is frequently implemented in a way that treats devs as just another part of an automated pipeline, not much different than software. >"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.

XorNot 5y ago

I don't know, my general rant on why all CI/CD is complete junk and everyone is cargo-culting a copy without an original in implementing it just never feels like something I want to post over and over again. 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.

unclebucknasty 5y ago
I'm laughing because it seems every company has some variation of this kind of madness. They're like flavors. >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".