> Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment.
A lot of the comments in this thread are pretty funny to me. CI systems are awesome when they are working. It is a real pain in the ass not knowing when something is broken or not being able to find out when it broke.
Similarly, writing good tests is really helpful for me. I do this even on my own personal projects.
These things are so helpful to me that these comments are like reading about people who hate source control.
I'd wager it's partly generational. If you came up in the agile world, then you likely see the upside but not the down since there's no reference point for the latter. Because, of course it's cool that these CI build processes kick off at commit points (or whatever). And, of course, the near instantaneous feedback that something is broken is more efficient than awaiting a nightly build. OTOH, we were much more cautious about the code we checked in because the stakes were higher and you didn't want to be the heel who broke the build. "Move fast and break things" was not a thing. Instead, "be thoughtful about what you're claiming to be good code" was the ethos.
But, this is not an argument about efficiency or whether these things can be made to work. The argument is about the cost to the developer of all of these things in sum, and the philosophy they serve.
Likewise with TDD. I'm not arguing that tests don't help code quality and I've heard others say they like writing them. YMMV and all that. But, it's more load on the developer and I've definitely seen it overdone.
So, again, without the reference of a "saner" world then you don't likely have the context to fully appreciate these costs. I see them, though, and frequently hear them when people complain about burnout. It's not CI/CD or TDD or whatever that's the problem. It's that these things are frequently used less as tools and more as the instruments of a philosophy that plugs developers in alongside them as just another part of the never-ending pipeline.
I disagree pretty strongly with your analysis. I have experience winging it without tests and CI systems. Of course it's not impossible or all bad, I still did it at the time because it was fun and I didn't know better.
Then I started working at a big company with a good engineering culture, I learned about writing tests and related tools, and had a much better experience. Now working without these things feels like driving without a seat belt, or maybe using a grinder without safety glasses (car accidents are too rare to be similar to bugs being introduced...).
I still have fun writing personal projects. It's just better with tests and CI. It sounds like you are pointing at issues with management styles that just happen to exist at the same time as useful tools like this, but I think they are almost if not completely orthogonal.
I hear you. My point here is not that every non-agile company is better than every agile company.
Not sure I'm getting my actual point across though so, rather than repeat myself, I'll just say the "continuous" part of CI/CD has implications on us as humans that are difficult to fulfill over the long-term. So, maybe really consider that word continuous in this context. We're just not made to be cogs in an automation pipeline that never ends, which is essentially where the philosophy (and its enabling tools) places us.
So, it can feel fine and you can see the merits of the tools, etc. But, none of that precludes the burnout that so many devs ultimately face over time.
A lot of the comments in this thread are pretty funny to me. CI systems are awesome when they are working. It is a real pain in the ass not knowing when something is broken or not being able to find out when it broke.
Similarly, writing good tests is really helpful for me. I do this even on my own personal projects.
These things are so helpful to me that these comments are like reading about people who hate source control.