7 ms·

This is a great point, laced with justified indignation. As a graybeard, I've seen multiple generations of "how to do software" and the most recent are the lea

This is a great point, laced with justified indignation. As a graybeard, I've seen multiple generations of "how to do software" and the most recent are the least fun. A lot of this is driven by the agile approach. It's tailor-made for dev burnout: from the endless tight cycles that force people into an infinite loop of productivity with scant satisfaction that comes with "completion", to all of the tools and philosophies designed to juice that endless loop to be successful/workable. CI/CD, Git, TDD, etc. These all impose on the developer's creativity, independence, and enjoyment. They turn devs into cogs--assembly line workers who must not stop the line at any cost. One example: back in the day there was a nightly build, not a continuous one. And, you checked out a file, worked on it, and checked it back in. If someone else needed it they had to wait. That obviously had its limitations and it seems laughable by today's standards. But, it was reflective of a human pace that considered devs as people vs. optimizable assets. That is, it was workable because the expectations on devs weren't insane. But, now we commit and merge. Think of how much less fun it is to spend your time resolving merge conflicts. More to the point, the approach itself implies a chaotic pace wherein code that meets the standards of a certain box must be produced at all times. Devs must bear the cost of resolving any conflicts (literally) that arise from this chaotic pace. 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. Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.

pnw_hazor 6y ago
The commodification/fungibilty of programmers is the goal. See, also open office plans. I think the bad started for me (long ago) when the Microsoft style management and so-called MS best practices began to conquer the PNW. In the late 90's a company I was in started driving to an exit. First they hired an ex-MS Group Program Mgr, whatever that means. Next, came tons of PMs pulling one or two devs into their projects/features. Doing it the MS way I guess (at least the MS way back then). I was a manager, I refused to dole out my team members to PMs -- everything my team did was run through me. I don't even think I let them enter individual devs into their project plans. Just the team. This worked well for us (my team) because I knew their capabilities, interests, family commitments, likes/dislikes, etc. I could adjust resources as needed to meet the team commitments. We had successes and failures as a team. PMs who tried put pressure on my devs behind my back would really catch it from me. My management style wasn't any new idea, it was what we did in the Army. Assign a team a task, then the team leader ensures the task is completed by the team. It was a good time, we were the only real team in the place as the other managers embraced the MS way of doing things. At end (right before dotcom bust) the company started doing some Agile-lite with two-week release cycles absent stories, standups, etc. I did like that enough to put it place at the next company I worked at. I did get burned out though, mostly because I didn't want deal with what the industry had become as the last startup I was at petered out. I still love programming but not enough to do it in modern shop.
- unclebucknasty 6y ago
  >The commodification/fungibilty of programmers is the goal This rings true. It's probably why I have always had a tendency to look sideways at these efforts to turn everyone into a coder. I get it: there's demand, opportunity, etc. But, for me, there's always been a cynical element of devaluing actual coders to it. The stuff you're talking about regarding your management approach almost seems like a relic from a bygone era at this point. So many companies now allow the process to manage devs. PMs back then frequently over-focused on the work vs. people, but even many of them have been replaced with some version of a scrum master with an even more relentless focus on the never-ending storyboard. They're driving the work over people approach without apology because it's what the process demands. This is not to say it's 100% the case across all companies. But, there's very much an inhuman element to the process that has manifested to some degree in nearly every place that employs agile.
throwaway839246 6y ago
I'd add open office plans to this. It's awful. You never quite get to focus, you don't build the rapport with your team, you don't get to customize your physical environment. Development really became a white collar version of the assembly line.
- fxtentacle 6y ago
  It's kind of weird by now. They will happily offer you $200k in annual salary, but an office with a window where you could keep a potted plant is out of the question.
  - highlysyntropic 6y ago
    exactly, what the hell is that about? is it a form of abuse like trying to keep everyone under control? is it a form of psychological conditioning to remind you that you just a resource whose top priority is to be interrupted at any time so knowing that you don't really have any personal space sovereignty or privacy to your own thoughts or creativity but that you must answer and create only for the collective? I don't feel I have a clear picture on what it's about any insights?
    - unclebucknasty 6y ago
      I can't say for certain, but I would guess it has something to do with the idea that all people must be available to each other at all times for the sake of raw productivity. So if there is a problem there is no time to wait. You just walk right up to the person you need to speak with and get it resolved then and there. Open offices facilitate that feeling of persistent accessibility and production. No closed doors to slow anyone down, and no notion that you are there to do anything but work every minute of every day. So why on Earth would anyone need privacy? This is full-on agile ethos. And, for the same reason, agile is also responsible for the reversal of telecommute policies at some companies.
      - fxtentacle 6y ago
creato 6y ago
> 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.
- unclebucknasty 6y ago
  >CI systems are awesome when they are working. >writing good tests is really helpful for me 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.
  - creato 6y ago
tonyarkles 6y ago
Reading through this thread, and looking in the mirror, it's reinforcing the fact that I, too, am becoming a graybeard. > 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. > Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs. I agree wholeheartedly with you. I'm by no means suggesting we move back to waterfall, but I am really enjoying the work I'm doing more and more of lately: embedded. Nominally it's a sort of Agile-type workflow (Kanban-ish), but because there's hardware design and manufacturing in the loop, things get planned out early and the multi-month plan doesn't change very much. New algorithm ideas pop up and get scheduled, new ways of doing sensor filtering pop up and get scheduled, but the direction of the wind doesn't change at the start of every "sprint". There are no sprints, just a prioritized/sequenced task list that gets reevaluated periodically. (Plus, I get to go back to my old days C-hacker roots. The thing builds with a Makefile and spits out a ~32kB binary that gets flashed onto the device.)
- cblum 6y ago
  How did you get into that space? What was your background? I hope you don’t mind me asking.
  - tonyarkles 6y ago
    I don't mind at all! Although I hate the question, because it's not a particularly actionable answer for most. I started writing out the whole story, but in a nutshell: my formal background is a dual EE/CompSci bachelors, followed by an Masters in CompSci that focused on distributed systems. When I was a kid, I learned to program very young: Basic around 8, C in DOS around 11, C on Linux around 13. I fiddled with electronics some, but didn't really get it. I took the EE part of my schooling specifically because I wanted to learn more about how computers worked "under the hood" so to speak. From there, I ran a web consultancy for a while, and ended up with a client that had a more math-heavy project. And then another client showed up with a project where a microcontroller made sense, and then another... My business partner was moving across the country, and I was enjoying what I was working on quite a bit more than I was in the web/mobile space, so we decided to part ways. I still do the occasional web/mobile project, but they're generally hardware-related (e.g. the Bluetooth connectivity portion of an IoT-type system). Over the years I've accumulated probably $15-20k worth of equipment and software license, and the customers keep showing up!
strken 6y ago
I don't really care about CI/CD (they just run), Git (better than project_name_final-03 on an unsecured ftp server), or TDD (just cheat and write post hoc tests). What I really hate is filling in form A, which directs you to form B, which you fill in to see whether form C is required. Form B was put in place by a legal team, who don't provide any point of contact, and who are not your friendly local legal team. Because the process of filling out forms is so time-consuming, your engineering team uses Asana to track it. However, your PMs use an excel spreadsheet, the legal team uses JIRA, your copywriters use a google doc, and the teams that own forms B and C use separate internally created tools. You update your form-filling progress in 6 different places, some of which have bugs and others of which aren't actively monitored, so you also have to use email/slack/skype messages to follow up the right people. Some of the right people are actually the wrong people. Some of the right people reject your proposal because they didn't read it properly. A few of them reject your proposal for reasons that are actually valid, but which you could not possibly have known, because they're based on tribal knowledge which is not documented anywhere. Filling in the forms and fixing the issues takes literally 3 months and at least 4 group meetings as well as several skype/zoom calls. One day you are finally allowed to write the code. It's 150 lines including tests, across two services, and you're done in two days. Everything that caused your proposal to be rejected would have been found in development. You quietly wonder whether you would have been happier as a bricklayer.
- mvind 6y ago
  I relate to this so much. At my work I have trying to a create a TABLE in a database for two weeks now. There is now 4 people involved in getting me the proper privileges to create the TABLE. It's weird how trivial things can spin into these horrible processes.
- unclebucknasty 6y ago
  That kind of bureaucracy predates agile, but it may have increased in some places as people try to grapple with the chaos of endless sprint cycles and continuous change. i.e. trying to figure how to manage the madness. But, I don't see how your shop can be agile with that level of bureaucracy? Anyway, I think my comments on CI/CD, Git, etc are being misconstrued. I'm not saying they don't have value. I'm saying they are frequently part of an ethos that leads to developer burnout. For instance, your CI/CID process is one you must "appease", along with the rest of the bureaucracy. It may not feel as odious (and may even seem a relief, relatively speaking), but it contributes to your total load. And, Git is fine. In fact, perhaps even perfect for the current culture (in philosophy, if not always in execution). Each developer has his/her own repo, you can work offline, you merge instead of locking check-outs, etc. But, that's the trick: it feels perfect because it allows you to work in the always-on philosophy of agile. Its popularity sprang up because this world of high burn-out, constant productivity demands it. So, we can see the utility of these things and even appreciate them. But, the model they enable and expectations they create can still ultimately lead devs to burnout.
ratww 6y ago
I think for TDD, CI and CD really depends. When it makes my job easier? Sure. A quick test framework that doesn't require too much boilerplate, a Github Actions CI that runs in a few seconds and help me, continuous deliver that has everything figured out for me? I think those are a net positive. When it makes my job a living hell? Nope. A CI that takes 40 minutes to run? A CD that requires manual intervention and has "a line" of builds and you have to babysit your build? Testing that requires multiple lines of boilerplate? Then I'd rather live without those things. Now... don't get me started about JIRA and other tools, which are a tool for micromanagement.

pnw_hazor 6y ago

The commodification/fungibilty of programmers is the goal. See, also open office plans. I think the bad started for me (long ago) when the Microsoft style management and so-called MS best practices began to conquer the PNW. In the late 90's a company I was in started driving to an exit. First they hired an ex-MS Group Program Mgr, whatever that means. Next, came tons of PMs pulling one or two devs into their projects/features. Doing it the MS way I guess (at least the MS way back then). I was a manager, I refused to dole out my team members to PMs -- everything my team did was run through me. I don't even think I let them enter individual devs into their project plans. Just the team. This worked well for us (my team) because I knew their capabilities, interests, family commitments, likes/dislikes, etc. I could adjust resources as needed to meet the team commitments. We had successes and failures as a team. PMs who tried put pressure on my devs behind my back would really catch it from me. My management style wasn't any new idea, it was what we did in the Army. Assign a team a task, then the team leader ensures the task is completed by the team. It was a good time, we were the only real team in the place as the other managers embraced the MS way of doing things. At end (right before dotcom bust) the company started doing some Agile-lite with two-week release cycles absent stories, standups, etc. I did like that enough to put it place at the next company I worked at. I did get burned out though, mostly because I didn't want deal with what the industry had become as the last startup I was at petered out. I still love programming but not enough to do it in modern shop.

unclebucknasty 6y ago
>The commodification/fungibilty of programmers is the goal This rings true. It's probably why I have always had a tendency to look sideways at these efforts to turn everyone into a coder. I get it: there's demand, opportunity, etc. But, for me, there's always been a cynical element of devaluing actual coders to it. The stuff you're talking about regarding your management approach almost seems like a relic from a bygone era at this point. So many companies now allow the process to manage devs. PMs back then frequently over-focused on the work vs. people, but even many of them have been replaced with some version of a scrum master with an even more relentless focus on the never-ending storyboard. They're driving the work over people approach without apology because it's what the process demands. This is not to say it's 100% the case across all companies. But, there's very much an inhuman element to the process that has manifested to some degree in nearly every place that employs agile.

throwaway839246 6y ago

I'd add open office plans to this. It's awful. You never quite get to focus, you don't build the rapport with your team, you don't get to customize your physical environment. Development really became a white collar version of the assembly line.

fxtentacle 6y ago
It's kind of weird by now. They will happily offer you $200k in annual salary, but an office with a window where you could keep a potted plant is out of the question.
- highlysyntropic 6y ago
  exactly, what the hell is that about? is it a form of abuse like trying to keep everyone under control? is it a form of psychological conditioning to remind you that you just a resource whose top priority is to be interrupted at any time so knowing that you don't really have any personal space sovereignty or privacy to your own thoughts or creativity but that you must answer and create only for the collective? I don't feel I have a clear picture on what it's about any insights?
  - unclebucknasty 6y ago
    I can't say for certain, but I would guess it has something to do with the idea that all people must be available to each other at all times for the sake of raw productivity. So if there is a problem there is no time to wait. You just walk right up to the person you need to speak with and get it resolved then and there. Open offices facilitate that feeling of persistent accessibility and production. No closed doors to slow anyone down, and no notion that you are there to do anything but work every minute of every day. So why on Earth would anyone need privacy? This is full-on agile ethos. And, for the same reason, agile is also responsible for the reversal of telecommute policies at some companies.
    - fxtentacle 6y ago

creato 6y ago

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

unclebucknasty 6y ago
>CI systems are awesome when they are working. >writing good tests is really helpful for me 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.
- creato 6y ago

tonyarkles 6y ago

Reading through this thread, and looking in the mirror, it's reinforcing the fact that I, too, am becoming a graybeard. > 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. > Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs. I agree wholeheartedly with you. I'm by no means suggesting we move back to waterfall, but I am really enjoying the work I'm doing more and more of lately: embedded. Nominally it's a sort of Agile-type workflow (Kanban-ish), but because there's hardware design and manufacturing in the loop, things get planned out early and the multi-month plan doesn't change very much. New algorithm ideas pop up and get scheduled, new ways of doing sensor filtering pop up and get scheduled, but the direction of the wind doesn't change at the start of every "sprint". There are no sprints, just a prioritized/sequenced task list that gets reevaluated periodically. (Plus, I get to go back to my old days C-hacker roots. The thing builds with a Makefile and spits out a ~32kB binary that gets flashed onto the device.)

cblum 6y ago
How did you get into that space? What was your background? I hope you don’t mind me asking.
- tonyarkles 6y ago
  I don't mind at all! Although I hate the question, because it's not a particularly actionable answer for most. I started writing out the whole story, but in a nutshell: my formal background is a dual EE/CompSci bachelors, followed by an Masters in CompSci that focused on distributed systems. When I was a kid, I learned to program very young: Basic around 8, C in DOS around 11, C on Linux around 13. I fiddled with electronics some, but didn't really get it. I took the EE part of my schooling specifically because I wanted to learn more about how computers worked "under the hood" so to speak. From there, I ran a web consultancy for a while, and ended up with a client that had a more math-heavy project. And then another client showed up with a project where a microcontroller made sense, and then another... My business partner was moving across the country, and I was enjoying what I was working on quite a bit more than I was in the web/mobile space, so we decided to part ways. I still do the occasional web/mobile project, but they're generally hardware-related (e.g. the Bluetooth connectivity portion of an IoT-type system). Over the years I've accumulated probably $15-20k worth of equipment and software license, and the customers keep showing up!

strken 6y ago

I don't really care about CI/CD (they just run), Git (better than project_name_final-03 on an unsecured ftp server), or TDD (just cheat and write post hoc tests). What I really hate is filling in form A, which directs you to form B, which you fill in to see whether form C is required. Form B was put in place by a legal team, who don't provide any point of contact, and who are not your friendly local legal team. Because the process of filling out forms is so time-consuming, your engineering team uses Asana to track it. However, your PMs use an excel spreadsheet, the legal team uses JIRA, your copywriters use a google doc, and the teams that own forms B and C use separate internally created tools. You update your form-filling progress in 6 different places, some of which have bugs and others of which aren't actively monitored, so you also have to use email/slack/skype messages to follow up the right people. Some of the right people are actually the wrong people. Some of the right people reject your proposal because they didn't read it properly. A few of them reject your proposal for reasons that are actually valid, but which you could not possibly have known, because they're based on tribal knowledge which is not documented anywhere. Filling in the forms and fixing the issues takes literally 3 months and at least 4 group meetings as well as several skype/zoom calls. One day you are finally allowed to write the code. It's 150 lines including tests, across two services, and you're done in two days. Everything that caused your proposal to be rejected would have been found in development. You quietly wonder whether you would have been happier as a bricklayer.

mvind 6y ago
I relate to this so much. At my work I have trying to a create a TABLE in a database for two weeks now. There is now 4 people involved in getting me the proper privileges to create the TABLE. It's weird how trivial things can spin into these horrible processes.
unclebucknasty 6y ago
That kind of bureaucracy predates agile, but it may have increased in some places as people try to grapple with the chaos of endless sprint cycles and continuous change. i.e. trying to figure how to manage the madness. But, I don't see how your shop can be agile with that level of bureaucracy? Anyway, I think my comments on CI/CD, Git, etc are being misconstrued. I'm not saying they don't have value. I'm saying they are frequently part of an ethos that leads to developer burnout. For instance, your CI/CID process is one you must "appease", along with the rest of the bureaucracy. It may not feel as odious (and may even seem a relief, relatively speaking), but it contributes to your total load. And, Git is fine. In fact, perhaps even perfect for the current culture (in philosophy, if not always in execution). Each developer has his/her own repo, you can work offline, you merge instead of locking check-outs, etc. But, that's the trick: it feels perfect because it allows you to work in the always-on philosophy of agile. Its popularity sprang up because this world of high burn-out, constant productivity demands it. So, we can see the utility of these things and even appreciate them. But, the model they enable and expectations they create can still ultimately lead devs to burnout.

ratww 6y ago

I think for TDD, CI and CD really depends. When it makes my job easier? Sure. A quick test framework that doesn't require too much boilerplate, a Github Actions CI that runs in a few seconds and help me, continuous deliver that has everything figured out for me? I think those are a net positive. When it makes my job a living hell? Nope. A CI that takes 40 minutes to run? A CD that requires manual intervention and has "a line" of builds and you have to babysit your build? Testing that requires multiple lines of boilerplate? Then I'd rather live without those things. Now... don't get me started about JIRA and other tools, which are a tool for micromanagement.