zlacker

>>todsac+(OP)
I tend to consider bullshit any point that finds somehow acceptable thinking that people is lazy, in this society, in this world, on this planet, ffs we have to work 40 hrs per week per decades and rest after reincarnation, and you want to talk about laziness? Let's talk about how any bit of mental energy is extracted to built other's wealth and then when you are too old to do nothing other than watching work in progress they just spit you out

when I am supposed to fix tech debt? if every week there is another functionality going out that needs to be done yesterday? Do you think that I have to do it in my free time? Why should I even bother existing

>>lnxg33+h1
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.

>>hombre+U4
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.

>>swatco+r8
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.