6 ms·

That's how I burned out of software. On a mature project in a small team, the only tickets left were hard bugs that nobody wanted. The kind of bugs where you c

That's how I burned out of software. On a mature project in a small team, the only tickets left were hard bugs that nobody wanted. The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions. Or maybe incorrectly crossing one out and then going on a wild goose chase until you circle back to it in a week, flustered. You're expected to commit all of your mental energy to these tickets day after day, and then once you finally triumph and solve the bug after coffee or amphetamine binges, you turn in the code, close the ticket, and you're expected to immediately work on the next ticket. You don't get a real break. But you can mentally rest at the start of the next ticket since nobody expects instant results. But now it's been a couple days and people are asking you what you've been doing so far—you must be blocked, right?—but you've barely started and you're pressured to invent small lies and excuses about why you're behind, each one risking yet another slip of the mask. And when you need some time off the most, it's when you're the most behind of all and people have begun to notice, so taking the time off doesn't even seem like an option.

vegetablepotpie 3y ago
Agile solves a lot of these problems.
- danwee 3y ago
  How so? If there are boring bugs to be fixed, someone will need to fix them regardless of the methodology used.
- Humdeee 3y ago
  Eureka! If only it was this easy...
- reflectiv 3y ago
  What kind of stupid statement is this...no it certainly does not. But humor me with an explanation, please...
  - vegetablepotpie 3y ago
    I don’t k now why I’m being downvoted. Agile lets you manage expectations and set boundaries by scheduling a finite amount of work into a bounded amount of time.
- fnimick 3y ago
  Does it? At one of my former jobs management would regularly pressure engineers into doing late nights at sprint end (every other week) if we were "behind". Then if we finished things a day into the next sprint, the PM would backdate the completion to make it look like we had hit the previous sprint, since sprint completion percentage was an OKR and people's bonuses and promotions depended on it. Then since we hit the sprint, obviously our velocity had to go up for the next one, even though we were starting a day late from scrambling to "finish" the last one. There's a reason I don't work there anymore.
  - robbintt 3y ago
    Name & shame
    - HeyLaughingBoy 3y ago
      Pretty much everywhere, unfortunately.
  - zimzam 3y ago
    The expectation that engineers work overtime to hit arbitrary metrics can’t be fixed by a process like scrum or waterfall though. Process can’t replace competent management.
- lowbloodsugar 3y ago
  Agile done right solves these problems. I have yet to see Agile done right, even once. And I've done XP since ~2003 and Scrum since 2006. It is now clear to me that Agile does not solve these problems: a solid leadership team solves these problems, and sometimes solid leadership teams use Agile (whether formally like Scrum, or informally, like just good communication). But Agile is the canary in the coal mine: it reveals very quickly if you have a solid leadership team or not.
  - marcosdumay 3y ago
    Agile done right is about some completely different problems. AFAIK, it does nothing to help here. But a solid leadership does help.
  - tremon 3y ago
    To me, "agile" in these discussions only apportions blame, it's orthogonal to the quality of software. When it's an agile project, either devs will choose to do the right thing, or too many developers will work on new features, whether because it gives them more visibility or because they like working on features more. And when it's not agile, either you have a product/team manager that understands the importance of not drowning in tech debt, or you have a manager that constantly prioritizes features over quality. Neither approach guarantees that the right choices will be made, just that in Agile, the developers mostly have themselves to blame.
  - augustk 3y ago
    > Agile done right solves these problems It's funny that Agile is always something else. It cannot be criticized because then your are doing it wrong. It's like a theory which is not falsifiable.
  - bedobi 3y ago
    no true scotsman is all agile advocates have don't get me wrong agile is an improvement in the sense that iterating on small deliverables is better than a single giant waterfall process, no disagreement there but yeah if your tool never delivers in the alleged benefits, ever, anywhere, then it's not good enough to say the problem is the people tools are welded by people if your tool doesn't take that into account and assumes and requires its users to be perfect, well, then it's not a very good tool
- edrxty 3y ago
  %s/solves/creates/ I don't care what the theoretical outcome is when the practical one is always this.
- liveoneggs 3y ago
  Now, of course, everybody is going to start moaning, "But I have all this speed. I'm agile. I'm fast. You know, this easy stuff is making my life good because I have a lot of speed." What kind of runner can run as fast as they possibly can from the very start of a race? [Audience reply: Sprinter] Right, only somebody who runs really short races, okay? [Audience laughter] But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
  - romanows 3y ago
    Agile isn't meant to imply speed in the sense of LoC/s, though right? The speed in Agile is about getting customer feedback sooner rather than later (so maybe a kind of latency?). I don't think sprints are mentioned in the Agile manifesto or related materials. And even within frameworks like Scrum, I don't think that "sprint" was ever intended to mean that programmers are supposed to be in permanent crunch mode.
    - rpeden 3y ago
      Words matter, though. Why call it a sprint if it's not supposed to be anything sprinting? We can literally call it anything we want, so why not pick a better metaphor? I think that many developers who say they dislike Agile really mean they dislike Scrum. I mean, a rugby scrum is pretty violent, and sprinting non-stop is a good way of dying of exhaustion. Come to think of it, some managers do seem to want the workplace to be a ruthless battleground with worker pitted against worker in a relentless flat-out sprint to seen as a "high performer".
      - nradov 3y ago
        The Scaled Agile Framework (SAFe) simply calls it an iteration. This is a neutral term with no implications about the pace of work. https://scaledagileframework.com/iterations/ https://scaledagileframework.com/iterations/
- marcosdumay 3y ago
  How?
- mateo411 3y ago
  Agile can help, but I think a vacation/time off is better approach in this scenario.
- miroljub 3y ago
  It's not that I don't believe you, I'd just enjoy reading an explanation how it solves the problems parent talks about.
- lelanthran 3y ago
  > Agile solves a lot of these problems Agile causes a lot of those problems. GP just described all the elements of agile, "pick up next ticket as a on as one is closed", "blockers", daily status updates, etc.
- bedobi 3y ago
  no it doesn't lol it literally causes them? i'm no waterfall advocate but at least with waterfall there's a clear beginning, middle and end to a software project with intuitive places for work, rest and celebration meanwhile doing maintenance on an existing system in an agile environment, esp with kanban, is very often literally what the poster is describing, an endless slog through tickets that aren't particularly noteworthy and thus don't really merit much consideration or celebration when done etc
  - nradov 3y ago
    Scaled Agile Framework (SAFe) has a regular program increment cadence of every 8-12 weeks. This provides intuitive places for work, rest, and celebration. https://scaledagileframework.com/planning-interval/ https://scaledagileframework.com/planning-interval/
lowbloodsugar 3y ago
Some people really like killing those kind of bugs. I know people who would move from project to project, at the end of each, killing the show stoppers. I've done that myself. But what I'm describing there is an environment where: 1. Developers are treated with respect 2. Different skill sets and different motivations of those developers are recognized
- digging 3y ago
  Actually what you're describing is completely different. Because if you're expected to only be working on those long, abstract, difficult tickets, none of the pressure to deliver features/bugfixes piles up as in the GP comment. But when you've got features on deadlines, there's not enough freedom to skip meetings and chug coffee all day without turning in any code.
  - eterm 3y ago
    So make that the expectation. Expectation management is a huge driver of quality of life. Knowing how to carve out your niche and not be expected to delvier feature after feature without a break is part of "managing upwards", which is another important life skill to gain.
    - johnnyanmac 3y ago
      "carving your niche" involves either through a lot of experience (power) or to be known in the industry (clout). The latter isn't all based on raw skill so you just hope you don't burn out before you get to such a point.
  - eschneider 3y ago
    A lot of those long, abstract, difficult bugs become blocking/ship preventing issues, so...no pressure. And alas, many (most?) developers suck at debugging, so if you're any good at it, you get everyone else's broken code to fix. sigh
Terr_ 3y ago
> The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions. Me, with zero C/C++ experience, being asked to figure out why the newer version of the Linux kernel is randomly crash-panicking after getting cross-compiled for a custom hardware box. ("He's familiar with the the build-system scripts, so he can see what changed.") ----- I spent weeks of testing slightly different code-versions, different compile settings, different kconfig options, knocking out particular drivers, waiting for recompiles and walking back and forth to reboot the machine, and generally puzzling over extremely obscure and shifting error traces... And guess what? The new kernel was fine. What was not fine were some long-standing hexadecimal arguments to the hypervisor, which had been memory-corrupting a spot in all kernels we'd ever loaded. It just happened to be that the newer compiles shifted bytes around so that something very important was in the blast zone. Anyway, that's how 3 weeks of frustrating work can turn into a 2-character change.
- belval 3y ago
  Personally these can be the best bugs though because you have an opportunity to learn something new (your work environment is everything though). Compare that to a ticket in an older codebase with hard multi-cause bugs that are just painful to debug and leave you with nothing but a deeper understanding of something that is slipping into irrelevance by the day.
  - Terr_ 3y ago
    "I found the bug, but it's because the business process you want to model is fundamentally insane and you're asking the computer to do magic."
    - belval 3y ago
      In my experience, administrative process that was previously done by a bunch of administrative assistants and then "computerized" around the year 2000. The original stakeholders are long gone, the system is too valuable to be replaced and each quirk handles specific cases that are not documented anywhere. Bonus point if it's in a semi-dead language like VBScript. Please fix.
swatcoder 3y ago
Who left bugs like that on the board until so late in development? Unless they're just "tricky / nice to haves" that everybody knows might not be tractable (taking the pressure off you), that's some "odd" management. No wonder you burnt out.
- superfrank 3y ago
  Working at a place like this now and I saw at least one previous workplace go from a healthy engineering org to something like this when they brought in new engineering leaders who all wanted to make their mark quickly. The problem is often systemic and a symptom of an engineering team not really having control over their own roadmap. You see it when an engineering team isn't agreeing to take on work, but rather being told what to work on by people outside of the team. Sometimes it's isolated to a single team, but sometimes it can be a whole org or company. It's caused by bad expectations around the amount of work that can be done and unclear priorities. How many people it affects depends on what level the bad expectations are being set at. In practice, this is how I've seen it play out. There are 10 developers worth of work that needs to be done by X date, but we only have a team of 8. No one has made it clear what the prioritization is or if they have, that priority isn't universally accepted or changes day to day. If everything is equally important, the tough work that may not have noticeable results is often what gets pushed into the backlog over and over. To people who see engineers as the "build new features" people, it's hard to regularly justify "I can't build feature X because I have to solve bug Y" and then a week later say "I still have no idea what's causing this issue". It's easy to say, well just get everyone to agree on priority and what a reasonable amount of work is, but that's far, far easier said than done.
- __loam 3y ago
  That's often how tech debt happens. Nobody wants to do them so they just build up
stiiv 3y ago
I hope that people who suffer from exhaustion and a lack of breaks are setting realistic expectations for themselves, and not simply assuming that they need to push themselves to (or past) their limit. It is a rare manager who encourages you to work less, but it is (in my experience) a common manager who understands that breaks and self care are important. They just need to be reminded sometimes. You can push back, and a healthy organization will respect you for it.
- lambersley 3y ago
  Crazy enough, I'm from the management school that believes the work is only the tool to develop the person and pay the bills. I will always sacrifice the work for the worker. It's sad that the majority of managers see this in reverse.
  - autoexec 3y ago
    > I will always sacrifice the work for the worker. The attitude I see most often is: "the worker is replaceable and therefore expendable, but the work will always be there until someone takes care of it so burn through as many workers as it takes to get it done"
    - gen220 3y ago
      I like to call this zero sum management, and the parent to your post is a good example of positive sum management. As long as the business is making money, the prospect of it continuing to make money in the near and medium term future is not in jeopardy, and the actors involved are rational, capable and trustworthy, you should always favor the worker over the work. IME, zero sum management is an emergent symptom of a poorly performing business (maybe if we make everybody work 150% harder we’ll hit our targets this quarter), insecure executives (who don’t understand the work they manage), or poor hiring/firing practices (the only way to let somebody go is by overloading them and rewarding it with a poor performance review, or you’re hiring people who aren’t capable or don’t care). If you’re a manager forced to make zero sum decisions and don’t feel empowered to change the root of that problem, you should probably consider leaving — good environments grow people instead of expending people.
kreeben 3y ago
Hombre, are you me? >> you turn in the code, close the ticket, and you're expected to immediately work on the next ticket. Yes. That's me. And then I crash. I used to call in sick when I go from heroically solving something unsolvable to start work on a new ticket. Then O thought, this is not sustainable. My boss is all over me for all of my sick time. So then I started to just say to my manager, hey, Mgr, amma gonna flex this whole Monday. Don't call me. Don't frakkin even think about me. Back on Tuesday, we cool? Turns out, we were cool. Whenever someone requires from you to be a hero, don't. Or be that guy, then take a Monday off.
- dpe82 3y ago
  This. Software engineering can be a mentally draining task, and just like with physically draining tasks your body needs time to recover its strength. Nobody would expect an athlete to last very long doing back to back events without recovery time between them - they'd end up injured. Your brain is similar. Recognizing that and accommodating it is a sign of maturity for both an engineer and a manager.
  - jdswain 3y ago
    And that is why I dislike the label 'sprint'. A sprint is a short (unsustainable) extreme effort, not something that you do continuously.
    - wetmore 3y ago
      > What kind of runner can run as fast as they possibly can from the very start of a race? > [Audience reply: Sprinter] > Right, only somebody who runs really short races, okay? > [Audience laughter] > But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- johnnyanmac 3y ago
vjust 3y ago
Agile is evil
- gen220 3y ago
  I think this generalizes to “cargo cutting process” is evil. If you don’t know or can’t reach consensus what your goals and principles are, no process will make your org functional.
- __loam 3y ago
  Agile itself was a response to this problem, and was invented by engineers who wanted more control of their work. It's become a whip for management but when it's done right it can be pretty freeing.
mckn1ght 3y ago
> taking the time off doesn't even seem like an option You don't get what you don't ask for. If you're asking and you feel like you're being overworked and reasonable requests for breaks are denied too much, work on finding somewhere more reasonable. Sure, easier said than done, but worth it to at least try in the long run.
nebula8804 3y ago
Man you have terrified me about my current situation. I'm currently on a team that is managing an extremely mature internal Angular project. The small team of two devs are just doing tickets like what you describe yet the management has no problem with this and does not hound us over why we haven't committed anything in days or a week+. This is due to their lack of technical knowledge and they have accepted this reality because the outcomes that they want do end up happening so they dont rock the boat(or know how to since they can't discern technical stuff). I know its a great spot to be in short term but Ive been scared because long term I will be in a big hole when the next role comes along and its more like what you describe and I haven't grown to match the role. I've considered leaving once the market improves but I don't think I can fathom giving up what I have either. Alternatively I have considered staying until I eventually get downsized but that could be years. I don't know.... :/
- DanielHB 3y ago
  If you are worried about your career prospects built a portifolio with what you want to work in the future. If your mental state with the project doesn't allow you to work in arcane bugs full-time, reserve some time for personal learning and portifolio building, but keep working full-time. A good personal open source project is worth more when interviewing than anything else really. Can't fake that in an interview.
  - nebula8804 3y ago
    I have been slowly doing this but in my experience, I have never had anyone care about my open source projects and the real problem is not raw coding skill, its being able to work in a large team and follow all modern processes that you'd pickup in modern teams. I am trying to learn and adopt these processes on my team (my coworker is onboard) but its a slog. For example we compile locally, then manually move the compiled code over to the server instead of using something like docker. Part of this is the restrictions we have over our environment, part of this is inertia. Fortunately I haven't given up trying to move to that paradigm but sometimes I actually dont want to be on a modern team. Its like I have plateaued to a comfortable state that I know wont always be there but I wish it did. I hope what I am explaining makes sense.

vegetablepotpie 3y ago

Agile solves a lot of these problems.

danwee 3y ago
How so? If there are boring bugs to be fixed, someone will need to fix them regardless of the methodology used.
Humdeee 3y ago
Eureka! If only it was this easy...
reflectiv 3y ago
What kind of stupid statement is this...no it certainly does not. But humor me with an explanation, please...
- vegetablepotpie 3y ago
  I don’t k now why I’m being downvoted. Agile lets you manage expectations and set boundaries by scheduling a finite amount of work into a bounded amount of time.
fnimick 3y ago
Does it? At one of my former jobs management would regularly pressure engineers into doing late nights at sprint end (every other week) if we were "behind". Then if we finished things a day into the next sprint, the PM would backdate the completion to make it look like we had hit the previous sprint, since sprint completion percentage was an OKR and people's bonuses and promotions depended on it. Then since we hit the sprint, obviously our velocity had to go up for the next one, even though we were starting a day late from scrambling to "finish" the last one. There's a reason I don't work there anymore.
- robbintt 3y ago
  Name & shame
  - HeyLaughingBoy 3y ago
    Pretty much everywhere, unfortunately.
- zimzam 3y ago
  The expectation that engineers work overtime to hit arbitrary metrics can’t be fixed by a process like scrum or waterfall though. Process can’t replace competent management.
lowbloodsugar 3y ago
Agile done right solves these problems. I have yet to see Agile done right, even once. And I've done XP since ~2003 and Scrum since 2006. It is now clear to me that Agile does not solve these problems: a solid leadership team solves these problems, and sometimes solid leadership teams use Agile (whether formally like Scrum, or informally, like just good communication). But Agile is the canary in the coal mine: it reveals very quickly if you have a solid leadership team or not.
- marcosdumay 3y ago
  Agile done right is about some completely different problems. AFAIK, it does nothing to help here. But a solid leadership does help.
- tremon 3y ago
  To me, "agile" in these discussions only apportions blame, it's orthogonal to the quality of software. When it's an agile project, either devs will choose to do the right thing, or too many developers will work on new features, whether because it gives them more visibility or because they like working on features more. And when it's not agile, either you have a product/team manager that understands the importance of not drowning in tech debt, or you have a manager that constantly prioritizes features over quality. Neither approach guarantees that the right choices will be made, just that in Agile, the developers mostly have themselves to blame.
- augustk 3y ago
  > Agile done right solves these problems It's funny that Agile is always something else. It cannot be criticized because then your are doing it wrong. It's like a theory which is not falsifiable.
- bedobi 3y ago
  no true scotsman is all agile advocates have don't get me wrong agile is an improvement in the sense that iterating on small deliverables is better than a single giant waterfall process, no disagreement there but yeah if your tool never delivers in the alleged benefits, ever, anywhere, then it's not good enough to say the problem is the people tools are welded by people if your tool doesn't take that into account and assumes and requires its users to be perfect, well, then it's not a very good tool
edrxty 3y ago
%s/solves/creates/ I don't care what the theoretical outcome is when the practical one is always this.
liveoneggs 3y ago
Now, of course, everybody is going to start moaning, "But I have all this speed. I'm agile. I'm fast. You know, this easy stuff is making my life good because I have a lot of speed." What kind of runner can run as fast as they possibly can from the very start of a race? [Audience reply: Sprinter] Right, only somebody who runs really short races, okay? [Audience laughter] But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- romanows 3y ago
  Agile isn't meant to imply speed in the sense of LoC/s, though right? The speed in Agile is about getting customer feedback sooner rather than later (so maybe a kind of latency?). I don't think sprints are mentioned in the Agile manifesto or related materials. And even within frameworks like Scrum, I don't think that "sprint" was ever intended to mean that programmers are supposed to be in permanent crunch mode.
  - rpeden 3y ago
    Words matter, though. Why call it a sprint if it's not supposed to be anything sprinting? We can literally call it anything we want, so why not pick a better metaphor? I think that many developers who say they dislike Agile really mean they dislike Scrum. I mean, a rugby scrum is pretty violent, and sprinting non-stop is a good way of dying of exhaustion. Come to think of it, some managers do seem to want the workplace to be a ruthless battleground with worker pitted against worker in a relentless flat-out sprint to seen as a "high performer".
    - nradov 3y ago
      The Scaled Agile Framework (SAFe) simply calls it an iteration. This is a neutral term with no implications about the pace of work. https://scaledagileframework.com/iterations/ https://scaledagileframework.com/iterations/
marcosdumay 3y ago
How?
mateo411 3y ago
Agile can help, but I think a vacation/time off is better approach in this scenario.
miroljub 3y ago
It's not that I don't believe you, I'd just enjoy reading an explanation how it solves the problems parent talks about.
lelanthran 3y ago
> Agile solves a lot of these problems Agile causes a lot of those problems. GP just described all the elements of agile, "pick up next ticket as a on as one is closed", "blockers", daily status updates, etc.
bedobi 3y ago
no it doesn't lol it literally causes them? i'm no waterfall advocate but at least with waterfall there's a clear beginning, middle and end to a software project with intuitive places for work, rest and celebration meanwhile doing maintenance on an existing system in an agile environment, esp with kanban, is very often literally what the poster is describing, an endless slog through tickets that aren't particularly noteworthy and thus don't really merit much consideration or celebration when done etc
- nradov 3y ago
  Scaled Agile Framework (SAFe) has a regular program increment cadence of every 8-12 weeks. This provides intuitive places for work, rest, and celebration. https://scaledagileframework.com/planning-interval/ https://scaledagileframework.com/planning-interval/

lowbloodsugar 3y ago

Some people really like killing those kind of bugs. I know people who would move from project to project, at the end of each, killing the show stoppers. I've done that myself. But what I'm describing there is an environment where: 1. Developers are treated with respect 2. Different skill sets and different motivations of those developers are recognized

digging 3y ago
Actually what you're describing is completely different. Because if you're expected to only be working on those long, abstract, difficult tickets, none of the pressure to deliver features/bugfixes piles up as in the GP comment. But when you've got features on deadlines, there's not enough freedom to skip meetings and chug coffee all day without turning in any code.
- eterm 3y ago
  So make that the expectation. Expectation management is a huge driver of quality of life. Knowing how to carve out your niche and not be expected to delvier feature after feature without a break is part of "managing upwards", which is another important life skill to gain.
  - johnnyanmac 3y ago
    "carving your niche" involves either through a lot of experience (power) or to be known in the industry (clout). The latter isn't all based on raw skill so you just hope you don't burn out before you get to such a point.
- eschneider 3y ago
  A lot of those long, abstract, difficult bugs become blocking/ship preventing issues, so...no pressure. And alas, many (most?) developers suck at debugging, so if you're any good at it, you get everyone else's broken code to fix. sigh

Terr_ 3y ago

> The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions. Me, with zero C/C++ experience, being asked to figure out why the newer version of the Linux kernel is randomly crash-panicking after getting cross-compiled for a custom hardware box. ("He's familiar with the the build-system scripts, so he can see what changed.") ----- I spent weeks of testing slightly different code-versions, different compile settings, different kconfig options, knocking out particular drivers, waiting for recompiles and walking back and forth to reboot the machine, and generally puzzling over extremely obscure and shifting error traces... And guess what? The new kernel was fine. What was not fine were some long-standing hexadecimal arguments to the hypervisor, which had been memory-corrupting a spot in all kernels we'd ever loaded. It just happened to be that the newer compiles shifted bytes around so that something very important was in the blast zone. Anyway, that's how 3 weeks of frustrating work can turn into a 2-character change.

belval 3y ago
Personally these can be the best bugs though because you have an opportunity to learn something new (your work environment is everything though). Compare that to a ticket in an older codebase with hard multi-cause bugs that are just painful to debug and leave you with nothing but a deeper understanding of something that is slipping into irrelevance by the day.
- Terr_ 3y ago
  "I found the bug, but it's because the business process you want to model is fundamentally insane and you're asking the computer to do magic."
  - belval 3y ago
    In my experience, administrative process that was previously done by a bunch of administrative assistants and then "computerized" around the year 2000. The original stakeholders are long gone, the system is too valuable to be replaced and each quirk handles specific cases that are not documented anywhere. Bonus point if it's in a semi-dead language like VBScript. Please fix.

swatcoder 3y ago

Who left bugs like that on the board until so late in development? Unless they're just "tricky / nice to haves" that everybody knows might not be tractable (taking the pressure off you), that's some "odd" management. No wonder you burnt out.

superfrank 3y ago
Working at a place like this now and I saw at least one previous workplace go from a healthy engineering org to something like this when they brought in new engineering leaders who all wanted to make their mark quickly. The problem is often systemic and a symptom of an engineering team not really having control over their own roadmap. You see it when an engineering team isn't agreeing to take on work, but rather being told what to work on by people outside of the team. Sometimes it's isolated to a single team, but sometimes it can be a whole org or company. It's caused by bad expectations around the amount of work that can be done and unclear priorities. How many people it affects depends on what level the bad expectations are being set at. In practice, this is how I've seen it play out. There are 10 developers worth of work that needs to be done by X date, but we only have a team of 8. No one has made it clear what the prioritization is or if they have, that priority isn't universally accepted or changes day to day. If everything is equally important, the tough work that may not have noticeable results is often what gets pushed into the backlog over and over. To people who see engineers as the "build new features" people, it's hard to regularly justify "I can't build feature X because I have to solve bug Y" and then a week later say "I still have no idea what's causing this issue". It's easy to say, well just get everyone to agree on priority and what a reasonable amount of work is, but that's far, far easier said than done.
__loam 3y ago
That's often how tech debt happens. Nobody wants to do them so they just build up

stiiv 3y ago

I hope that people who suffer from exhaustion and a lack of breaks are setting realistic expectations for themselves, and not simply assuming that they need to push themselves to (or past) their limit. It is a rare manager who encourages you to work less, but it is (in my experience) a common manager who understands that breaks and self care are important. They just need to be reminded sometimes. You can push back, and a healthy organization will respect you for it.

lambersley 3y ago
Crazy enough, I'm from the management school that believes the work is only the tool to develop the person and pay the bills. I will always sacrifice the work for the worker. It's sad that the majority of managers see this in reverse.
- autoexec 3y ago
  > I will always sacrifice the work for the worker. The attitude I see most often is: "the worker is replaceable and therefore expendable, but the work will always be there until someone takes care of it so burn through as many workers as it takes to get it done"
  - gen220 3y ago
    I like to call this zero sum management, and the parent to your post is a good example of positive sum management. As long as the business is making money, the prospect of it continuing to make money in the near and medium term future is not in jeopardy, and the actors involved are rational, capable and trustworthy, you should always favor the worker over the work. IME, zero sum management is an emergent symptom of a poorly performing business (maybe if we make everybody work 150% harder we’ll hit our targets this quarter), insecure executives (who don’t understand the work they manage), or poor hiring/firing practices (the only way to let somebody go is by overloading them and rewarding it with a poor performance review, or you’re hiring people who aren’t capable or don’t care). If you’re a manager forced to make zero sum decisions and don’t feel empowered to change the root of that problem, you should probably consider leaving — good environments grow people instead of expending people.

kreeben 3y ago

Hombre, are you me? >> you turn in the code, close the ticket, and you're expected to immediately work on the next ticket. Yes. That's me. And then I crash. I used to call in sick when I go from heroically solving something unsolvable to start work on a new ticket. Then O thought, this is not sustainable. My boss is all over me for all of my sick time. So then I started to just say to my manager, hey, Mgr, amma gonna flex this whole Monday. Don't call me. Don't frakkin even think about me. Back on Tuesday, we cool? Turns out, we were cool. Whenever someone requires from you to be a hero, don't. Or be that guy, then take a Monday off.

dpe82 3y ago
This. Software engineering can be a mentally draining task, and just like with physically draining tasks your body needs time to recover its strength. Nobody would expect an athlete to last very long doing back to back events without recovery time between them - they'd end up injured. Your brain is similar. Recognizing that and accommodating it is a sign of maturity for both an engineer and a manager.
- jdswain 3y ago
  And that is why I dislike the label 'sprint'. A sprint is a short (unsustainable) extreme effort, not something that you do continuously.
  - wetmore 3y ago
    > What kind of runner can run as fast as they possibly can from the very start of a race? > [Audience reply: Sprinter] > Right, only somebody who runs really short races, okay? > [Audience laughter] > But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
johnnyanmac 3y ago

vjust 3y ago

Agile is evil

gen220 3y ago
I think this generalizes to “cargo cutting process” is evil. If you don’t know or can’t reach consensus what your goals and principles are, no process will make your org functional.
__loam 3y ago
Agile itself was a response to this problem, and was invented by engineers who wanted more control of their work. It's become a whip for management but when it's done right it can be pretty freeing.

mckn1ght 3y ago

> taking the time off doesn't even seem like an option You don't get what you don't ask for. If you're asking and you feel like you're being overworked and reasonable requests for breaks are denied too much, work on finding somewhere more reasonable. Sure, easier said than done, but worth it to at least try in the long run.

nebula8804 3y ago

Man you have terrified me about my current situation. I'm currently on a team that is managing an extremely mature internal Angular project. The small team of two devs are just doing tickets like what you describe yet the management has no problem with this and does not hound us over why we haven't committed anything in days or a week+. This is due to their lack of technical knowledge and they have accepted this reality because the outcomes that they want do end up happening so they dont rock the boat(or know how to since they can't discern technical stuff). I know its a great spot to be in short term but Ive been scared because long term I will be in a big hole when the next role comes along and its more like what you describe and I haven't grown to match the role. I've considered leaving once the market improves but I don't think I can fathom giving up what I have either. Alternatively I have considered staying until I eventually get downsized but that could be years. I don't know.... :/

DanielHB 3y ago
If you are worried about your career prospects built a portifolio with what you want to work in the future. If your mental state with the project doesn't allow you to work in arcane bugs full-time, reserve some time for personal learning and portifolio building, but keep working full-time. A good personal open source project is worth more when interviewing than anything else really. Can't fake that in an interview.
- nebula8804 3y ago
  I have been slowly doing this but in my experience, I have never had anyone care about my open source projects and the real problem is not raw coding skill, its being able to work in a large team and follow all modern processes that you'd pickup in modern teams. I am trying to learn and adopt these processes on my team (my coworker is onboard) but its a slog. For example we compile locally, then manually move the compiled code over to the server instead of using something like docker. Part of this is the restrictions we have over our environment, part of this is inertia. Fortunately I haven't given up trying to move to that paradigm but sometimes I actually dont want to be on a modern team. Its like I have plateaued to a comfortable state that I know wont always be there but I wish it did. I hope what I am explaining makes sense.