Hacker News Reader

Comment by dfxm12 | Hacker News Reader

In my experience (and I think also in the spirit of the analogy), it's not just maintenance. It's expecting to maintain everything you've ever done while also simultaneously being expected to keep producing new work at the same rate (and then being expected to maintain that).

It's that your work load seems to only increase. As the study found with regards to the causes of burnout, increased workload cited as the main reason.

I'm still providing updates to stuff from over five years ago (that has officially been retired), while my boss is breathing down my neck about new projects. The stress of doing this, the stress of trying to manage my manager's expectation, the stress of realizing you'll never be able to really put any of your work out of your mind or have a lighter load of responsibilities, etc. is what leads to burnout.

View on HN

One of the undersold advantages about getting a new job is that all the implicit commitments you built up go away. Try it.

Yes but then in the new job you need to maintain other people's stuff, which is even harder that maintaining your own stuff. And over time you get to own that, including all the previous tech debt that you didn't create

And you don't have that kind of "previous work bank" of stuff you accomplished when something runs late, in a new job. And things always run late. In my new job they said here's this major piece of work. We already committed to it. 2 other teams and outside customers are expecting it. Can you do it in 2 months? I don't know, maybe, I guess? There's a great starting point, they said. Then it turned out to take 5 months. Everyone is mad at me, it was incredibly stressful, I worked 7 days a week. This is kind of a summary of the modern dev job.

At some point in your career, you gain enough confidence to say no, I can't commit to that. If they fire you for not making unreasonable commitments, that's net benefit to you.

Dev shops don't have to operate like that, and all it takes is one person to have the fortitude to say no.

Yes, and as the list of items to maintain grows, you must perform more and more context switches as bugs or other fixes crop up, spreading you more and more thin. Meanwhile the number of new requests does not slow down.

This is too often ignored. Maintenance, even of applications which do not require new features, can often be non-trivial. In my past job, a lot of challenges were caused by the fact that nobody really budgeted for maintaining the existing stuff but it actually required 2 full time people to deal with.

Heh, it's like having a kid that is your total dependent for 18 years. And then having another, and another, and another. And unlike real children, they don't help take care of each other.

Reply on news.ycombinator.com