Hacker News Reader

Comment by sharkbird2 | Hacker News Reader

I think one big factor in this is that as a developer, you don't (normally) have slow periods. A lot of other occupations will have their stressful high-tempo periods, but then they have the lower-tempo periods in between. But in software engineering there's no end to the constant demand of more features and more bug fixes. There's no slow time, no low-tempo periods.

Humans are just not made to always work at flank speed, but I feel like that's the expectation within the software industry, and I can easily see that leading to burnout.

View on HN

Perversely, because the industry creates this pressure, low-tempo periods that are employer-specific cause anxiety and paranoia. This is even more true right now as large companies continue to announce layoffs.

Is boreout actually a problem unless you're expected to be imprisoned in an office every day and maybe, even worse, expected to look like you're "working" even if there's not much to do? In a remote or hybrid working culture, periods of lightweight work should just be regarded as more leisure time for you. Embrace the opportunity for some self-care!

I agree, though I can see this being hard for many. Even when technically resting, knowing you are technically in working hours is often enough to prevent real leisure.

I don't think this is right. Every company I've worked at has had a busy season and a not-so-busy season. Plus I still take vacations.

But it's true at some companies, it's always the busy season.

> Every company I've worked at has had a busy season and a not-so-busy season.

And yet, more than enough companies plan their staffing for "can barely hold it together in not-so-busy season and expect overtime in busy season". That looks good for the beancounters, but is hell for the staff.

> Plus I still take vacations.

The US doesn't have mandatory PTO requirement. Europe does, but it still is nowhere near a level that would actually allow people to have enough free time to enjoy life.

I think this depends a lot on the nature of one’s work. Examples of busy periods:

- externally driven work (eg some obligation to a client; some change to an api that is relied on)

- intern season / spending time bringing someone new up to speed / when someone leaves a team

Quiet periods:

- the opposite of the above

- times when the business focus is on reliability (eg I think Facebook have a big hiatus on changes to the site during the run up to Christmas as it’s the most profitable time of the year for them).

> - times when the business focus is on reliability (eg I think Facebook have a big hiatus on changes to the site during the run up to Christmas as it’s the most profitable time of the year for them).

I work at Amazon and have been subjected to two versions of those periods (because I switched teams): one was every year around Black Friday and Christmas, and the other one was when a new big show releases on PrimeVideo (like LOTR).

Those periods are the total opposite of quiet.

You still have to work on normal deliverables, except you can't push them on your pipelines (not even beta) and on top of that you have to either support last minute critical demands for ad-hoc work, and then you have to work around the extremely strict deployment windows to actually release that ad-hoc crap to prod.

I have started deployments at 9AM and finished at 11PM routinely during those times because there's a single day where the pipelines are open and you have to complete your deployment before the next day.

I hated this at Amazon. The rest of the year we’d all be so pleased by our frequent deployments. Then for half of Q4 we’d be in code freeze but would be pressured to pile up feature work to go out in Q1. At least weblabs made feature flags easy.

Oh really, I actually find the slow periods of development work the hardest. Like when you start to suffer boreout when there's not much to do. It's kind of a burnout because the energy isn't there to go seek out busy work.

Reply on news.ycombinator.com