Hacker News Reader

Comment by mikewave | Hacker News Reader

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.)

View on HN

>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".

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

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.

Reply on news.ycombinator.com