5 ms·

If I may: what exactly is the reason for the SWE disdain? From your post, I can kind-of relate with my own disdain for enterprise practices attempting to turn t

If I may: what exactly is the reason for the SWE disdain? From your post, I can kind-of relate with my own disdain for enterprise practices attempting to turn the field into a factory job and piling on more and more responsibilities. Despite that, I still hold a love for creating things through code (which is also rapidly being taken away by these practices). This is not to dissuade your choice. Rather, I'm looking for similarities between myself and others, and potential pitfalls to avoid.

simonbarker87 6y ago
At the risk of putting words in OPs mouth, sounds like SCRUM burn out and continually keeping up with changing tech. I wish them the best of luck with their change of career.
- mangochutney 6y ago
  Eh, you're not wrong, amigo. And thanks for the words.
- hyko 6y ago
  SCRUM burn out?
  - simonbarker87 6y ago
    Daily stand ups, retros, refinements, planning, always striving for smaller tickets, deadlines every two weeks, not enough time to deal with tech debt, not enough time to focus on chunkier bits of work, story points, back to back to back to back never ending sprints. I don’t necessarily believe all of the points above are negative but scrum can be an exhausting way to work.
    - blunte 6y ago
      Most of my career has been solo generalist within companies and freelance, so what you describe wasn't my problem... but now I'm in the exact situation you so succinctly described! The not enough time to deal with technical debt problem is my biggest complaint.
    - hyko 6y ago
      This doesn’t really sound like SCRUM. One of the key notions is that teams work at a sustainable pace; if there’s not enough time to deal with tech debt and people are burning out then this pace is by definition unsustainable. The working conditions you describe also sound like they have no slack whatsoever (not a SCRUM requirement but not a bad idea either). There shouldn’t be deadlines every two weeks, instead you should be working towards a sprint goal. If the goal is not achieved then you can use that knowledge in the next sprint to reduce the amount of scope you try to complete. There are no deadlines per se, because deadlines try to fix scope and time, whereas a sprint only fixes time. The process of estimation and story pointing is where things become more art than science, but provided you are consistent in your approaches this mechanism prevents our inherent lack of foresight from becoming a catastrophic prediction failure. Meetings like stand ups, retros, and backlog refinement can be super effective tools but they have to be run properly and tightly, otherwise they become worse than nothing. I guess in this hypothetical team the thing to do would be to raise with the Scrum Master that you’re exhausted, raise in the retro that there are deficiencies in the process etc. and get back to a more sane baseline.
      - BlargMcLarg 6y ago
        This has already been repeated ad nauseam. If many people cannot implement the methodology without it becoming warped, we should put that methodology under scrunity. Additionally, many others have already argued against both the common implementation of Scrum, and its "ideal, perfect, theoretical" version. Just the idea of preserving asynchronous communication while introducing fixed, synchronous communication strikes me as an idea by someone who does not understand how people work.
        hyko 6y ago
        If Scrum is too hard for people to adopt, then that's a valid criticism when it comes to its impact on the wider industry. However, what we can't do is fail to adopt it properly and then generalise our criticism of that new process to encompass Scrum as a whole. Its ideal version is not some platonic form that cannot be realised in practice; I have experienced it first hand and it can work reasonably well. I have also experienced all sorts of 'flavors' that were less successful. They usually amount to people either not bothering to RTFM, low levels of investment in process, or senior management undermining the team efforts (through either not RTFMing or not believing in Agile as a concept). Whether that is down to the lack of adherence to the Scrum process itself, or just the lack of competence that would be required to stick to any process is an open question. Scrum as a set of process rules should not be particularly difficult for an engineering team to learn. I submit that if a team cannot operate under such a set of rules, it will be unable to adopt any set of process rules, and in addition to that, it will perform especially poorly under a system of no rules (i.e. direct rule by edicts from kings and queens).
- BlargMcLarg 6y ago
  The answer doesn't seem far from the truth. Unfortunately, I believe Scrum is only the tip of the iceberg. The diversity of responsibilities I experienced coming from university to my first job is immense, despite never doing anything technically complex or interesting. Couple that with a bunch of bureaucracy and a movement that is continuously pushing responsibilities of the upper layers onto the lower layers, without giving them the autonomy and agency to act out those responsibilities how they want. It is incredibly harmful. Yeah, I am a little salty about the state of things. I'd prefer programming in "my basement", and can understand why communication is important. Yet I can't help but feel we've thrown out the baby along with the bathwater.
  - simonbarker87 6y ago
    Interesting you use the word “agency”. I have used this exact word when trying to reconcile how scrum works. Some tickets are so detailed on acceptance criteria that if something is then missing I don’t feel like I have the agency to deal with it my self. I’ve used the analogy of fitting a kitchen, if everything is spec’d to super high detail and then it simply says “a cooler” no one in their right mind would just grab a cooker, they would ask the home owner/client what cooker they want.
    - BlargMcLarg 6y ago
      Same here. What's worse: my manager desperately wants people in the team to take on more responsibility and step forward. Yet everyone has a history of facing negative feedback when doing so. That ain't gonna happen. Reason I emphasize agency is that as long as it gives the best result and meets the requirements (including ethical ones), I don't care how it is done. Result being very broad: features, maintainability of the code, enjoyment of the team, etc.. Anything else that is pushed from the management layers without good reason is needless overhead. Now what do software devs usually do when we see needless overhead? Ah right, we remove it. If only it were that simple outside software.
mangochutney 6y ago
I used to struggle finding the words for it, then I found this thread[1]. Instead of a long diatribe more or less saying the same thing, I think that article sums up 99% of it. Generally speaking: I just don't have the energy for the amounts of bullshit that comes with being in this career anymore. No job is immune from bullshit, this much is true--but I kind of hate this cop out because it strips agency from people in minimizing the amount of bullshit they are subjected to on a daily basis. For me, that means to hell with this career. I very much want to do something different, so that's what's going to happen. [1] https://news.ycombinator.com/item?id=25251029 https://news.ycombinator.com/item?id=25251029 Good luck on whatever voyage and path you end up taking, I genuinely hope you find a spot of zen for you and yours. EDIT: BY THE WAY--I will probably never stop coding, as there are always opportunities to be efficient in bookkeeping and do some low level automation (in fact I do this already). I've also got a home lab running a few local services and I enjoy tinkering. I'm just not at all interested in writing and maintaining feature/production code for another SaaS platform or "tech company". Not at all. Never again. The idea of even interviewing for one of these jobs has the heart rate ticking up and the jaw to clinch up.
- BlargMcLarg 6y ago
  Thanks. The response is quite enlightening. It seems most people still hold their love for coding or what spawns from that coding. It is the environment in which they code, that creates most of the frustration (and doesn't seem to be stopping anytime soon). I wish you the same luck.
  - mangochutney 6y ago
    It is the environment in which they code, that creates most of the frustration Wholeheartedly agreed

simonbarker87 6y ago

At the risk of putting words in OPs mouth, sounds like SCRUM burn out and continually keeping up with changing tech. I wish them the best of luck with their change of career.

mangochutney 6y ago
Eh, you're not wrong, amigo. And thanks for the words.
hyko 6y ago
SCRUM burn out?
- simonbarker87 6y ago
  Daily stand ups, retros, refinements, planning, always striving for smaller tickets, deadlines every two weeks, not enough time to deal with tech debt, not enough time to focus on chunkier bits of work, story points, back to back to back to back never ending sprints. I don’t necessarily believe all of the points above are negative but scrum can be an exhausting way to work.
  - blunte 6y ago
    Most of my career has been solo generalist within companies and freelance, so what you describe wasn't my problem... but now I'm in the exact situation you so succinctly described! The not enough time to deal with technical debt problem is my biggest complaint.
  - hyko 6y ago
    This doesn’t really sound like SCRUM. One of the key notions is that teams work at a sustainable pace; if there’s not enough time to deal with tech debt and people are burning out then this pace is by definition unsustainable. The working conditions you describe also sound like they have no slack whatsoever (not a SCRUM requirement but not a bad idea either). There shouldn’t be deadlines every two weeks, instead you should be working towards a sprint goal. If the goal is not achieved then you can use that knowledge in the next sprint to reduce the amount of scope you try to complete. There are no deadlines per se, because deadlines try to fix scope and time, whereas a sprint only fixes time. The process of estimation and story pointing is where things become more art than science, but provided you are consistent in your approaches this mechanism prevents our inherent lack of foresight from becoming a catastrophic prediction failure. Meetings like stand ups, retros, and backlog refinement can be super effective tools but they have to be run properly and tightly, otherwise they become worse than nothing. I guess in this hypothetical team the thing to do would be to raise with the Scrum Master that you’re exhausted, raise in the retro that there are deficiencies in the process etc. and get back to a more sane baseline.
    - BlargMcLarg 6y ago
      This has already been repeated ad nauseam. If many people cannot implement the methodology without it becoming warped, we should put that methodology under scrunity. Additionally, many others have already argued against both the common implementation of Scrum, and its "ideal, perfect, theoretical" version. Just the idea of preserving asynchronous communication while introducing fixed, synchronous communication strikes me as an idea by someone who does not understand how people work.
      - hyko 6y ago
        If Scrum is too hard for people to adopt, then that's a valid criticism when it comes to its impact on the wider industry. However, what we can't do is fail to adopt it properly and then generalise our criticism of that new process to encompass Scrum as a whole. Its ideal version is not some platonic form that cannot be realised in practice; I have experienced it first hand and it can work reasonably well. I have also experienced all sorts of 'flavors' that were less successful. They usually amount to people either not bothering to RTFM, low levels of investment in process, or senior management undermining the team efforts (through either not RTFMing or not believing in Agile as a concept). Whether that is down to the lack of adherence to the Scrum process itself, or just the lack of competence that would be required to stick to any process is an open question. Scrum as a set of process rules should not be particularly difficult for an engineering team to learn. I submit that if a team cannot operate under such a set of rules, it will be unable to adopt any set of process rules, and in addition to that, it will perform especially poorly under a system of no rules (i.e. direct rule by edicts from kings and queens).
BlargMcLarg 6y ago
The answer doesn't seem far from the truth. Unfortunately, I believe Scrum is only the tip of the iceberg. The diversity of responsibilities I experienced coming from university to my first job is immense, despite never doing anything technically complex or interesting. Couple that with a bunch of bureaucracy and a movement that is continuously pushing responsibilities of the upper layers onto the lower layers, without giving them the autonomy and agency to act out those responsibilities how they want. It is incredibly harmful. Yeah, I am a little salty about the state of things. I'd prefer programming in "my basement", and can understand why communication is important. Yet I can't help but feel we've thrown out the baby along with the bathwater.
- simonbarker87 6y ago
  Interesting you use the word “agency”. I have used this exact word when trying to reconcile how scrum works. Some tickets are so detailed on acceptance criteria that if something is then missing I don’t feel like I have the agency to deal with it my self. I’ve used the analogy of fitting a kitchen, if everything is spec’d to super high detail and then it simply says “a cooler” no one in their right mind would just grab a cooker, they would ask the home owner/client what cooker they want.
  - BlargMcLarg 6y ago
    Same here. What's worse: my manager desperately wants people in the team to take on more responsibility and step forward. Yet everyone has a history of facing negative feedback when doing so. That ain't gonna happen. Reason I emphasize agency is that as long as it gives the best result and meets the requirements (including ethical ones), I don't care how it is done. Result being very broad: features, maintainability of the code, enjoyment of the team, etc.. Anything else that is pushed from the management layers without good reason is needless overhead. Now what do software devs usually do when we see needless overhead? Ah right, we remove it. If only it were that simple outside software.

mangochutney 6y ago

I used to struggle finding the words for it, then I found this thread[1]. Instead of a long diatribe more or less saying the same thing, I think that article sums up 99% of it. Generally speaking: I just don't have the energy for the amounts of bullshit that comes with being in this career anymore. No job is immune from bullshit, this much is true--but I kind of hate this cop out because it strips agency from people in minimizing the amount of bullshit they are subjected to on a daily basis. For me, that means to hell with this career. I very much want to do something different, so that's what's going to happen. [1] https://news.ycombinator.com/item?id=25251029 https://news.ycombinator.com/item?id=25251029 Good luck on whatever voyage and path you end up taking, I genuinely hope you find a spot of zen for you and yours. EDIT: BY THE WAY--I will probably never stop coding, as there are always opportunities to be efficient in bookkeeping and do some low level automation (in fact I do this already). I've also got a home lab running a few local services and I enjoy tinkering. I'm just not at all interested in writing and maintaining feature/production code for another SaaS platform or "tech company". Not at all. Never again. The idea of even interviewing for one of these jobs has the heart rate ticking up and the jaw to clinch up.

BlargMcLarg 6y ago
Thanks. The response is quite enlightening. It seems most people still hold their love for coding or what spawns from that coding. It is the environment in which they code, that creates most of the frustration (and doesn't seem to be stopping anytime soon). I wish you the same luck.
- mangochutney 6y ago
  It is the environment in which they code, that creates most of the frustration Wholeheartedly agreed