Live data from Hacker News

Mental health in software engineering

vadimkravcenko.com

311–320 of 440 posts

Re: Mental health in software engineering

#311

Earlier quoted context omitted.

As someone who crossed over from medicine, I can attest that software engineers have it very very good. Appreciate what you have. I accept everyone's personal experiences with bad management, unreasonable timelines, and uninspiring projects, but those things are everywhere. Now add in patients and their families having the worst days of their lives in your presence day after day, high-pressure decision making, not ge…

You’re wrong about the mentally taxing bit because you’re comparing Apples and Oranges. Most doctors are not spending solid 4hr blocks in flow focusing on a highly complex problem (surgeons being the obvious exception) but instead dealing with a sort of multi-tasking complexity which is a completely different type of mental taxation.

I mean, most doctors are spending their entire shifts trying not to inadvertently kill or disable anyone. Yeah that's a completely different type of mental taxation - one far worse IMO than any highly complex problem I've ever encountered in software engineering (and quite frankly, the problems aren't that complex most of the time. If anything, personally the SE stuff that's actually hard is fun and the rest is rather mind-numbing).

Re: Mental health in software engineering

#312

One thing I've realized more and more over the years: it's the operational roles (infra, SRE, Devops) that are actually most stressful. Sure, if you're building product, you get deadlines, but they are predictable and they come and go. But being oncall for a shakey infra stack? That shit is hell. No deadlines, just the threat of incidents or downtime at any time of day.

It's especially frustrating that I firmly believe operations is a solved problem, but good luck getting a company to adopt the practices that every other mature tech company has already figured out.

Re: Mental health in software engineering

#313
post #275

Earlier quoted context omitted.

> most deadlines were entirely arbitrary Yes. As are most tasks, in my experience. Looking back on your almost 30 years, what percent of tasks could have been skipped entirely and, in the long run, it wouldn't have mattered? For me, it's easily >50% ... catch me on a grumpy day and I'd say it's closer to 90%.

Honestly, most companies and projects fail completely. In my 25ish year career I can only think of a handful of lines of code that I've written that are still in production (or that I think might still be in production) and only a few employers that still exist. When you pan out far enough it all seems a bit silly.

Why is that an appropriate measure? Are chefs sad that none of the meals they created are still around?

Re: Mental health in software engineering

#314

I'm not terribly convinced that software engineering is harder on someone mental health than being a doctor, lawyer, sales, engineer, professional athlete, teacher, or any other white collar profession is. All of these have their specific stressors, all of these professions have loads of articles about how people are leaving these professions due to how hard they are. All of these jobs tend to lead to them consuming…

As someone who crossed over from medicine, I can attest that software engineers have it very very good. Appreciate what you have. I accept everyone's personal experiences with bad management, unreasonable timelines, and uninspiring projects, but those things are everywhere. Now add in patients and their families having the worst days of their lives in your presence day after day, high-pressure decision making, not ge…

There’s a certain type of person that always has to comment whenever anyone says they have it hard by pointing out how actually those problems are nothing compared to X. It’s like a weird obsession with having to win the suffering competition.

Re: Mental health in software engineering

#315
post #231

What in software engineering adds more than the usual stress to working? - Automation is the rule, not the exception. Replace your own work with a script, whenever you can. - Our work product in theory works forever (i.e., until conditions change). You really are not needed when you're done. Script monkeys can copy and fix your stuff. - New technologies and platforms: hardware drives software and vice-versa, leading…

You can make a list like this of stressors specific to a particular profession that NO other profession has, and all it will really tell you is that every profession has something unique about it.

And while I can't speak for every kind of mental health issue, software engineering is not even close to being one of the worst professions when it comes to job-related depression and suicide risk. There are whole fields that are known to turn workers into high-functioning alcoholics (see e.g. hospitality, construction and law). I feel like one has to be pretty deep inside the tech bubble to not realise just how off plenty of people in other professions are.

Re: Mental health in software engineering

#316

"An example of uncertainty in business is when your CEO tells you they promised a feature to your biggest client and it needs to be built ASAP as highest priority, so all hands on deck. Then a day later they tell you another feature, completely contradictory to the first one, needs to be built as well and is also highest priority. When you tell them they both can't be highest priority, the answer is: make it happen."…

One of the strongest skills as a business facing developer is being able to say no.

Stakeholder management is an art and sometimes you have to say "yes, but here's your choices"

Re: Mental health in software engineering

#317
post #275

In almost 30 years of software engineering, I came to the conclusion years ago that most deadlines were entirely arbitrary. The business isn't going to fail if you slip a week, or frequently even six months and if it does its probably not the fault of engineering unless its so dysfunctional as to repeatably blow through its own delivery estimates. Sure there are regulatory deadlines, customer POC or delivery deadline…

> most deadlines were entirely arbitrary Yes. As are most tasks, in my experience. Looking back on your almost 30 years, what percent of tasks could have been skipped entirely and, in the long run, it wouldn't have mattered? For me, it's easily >50% ... catch me on a grumpy day and I'd say it's closer to 90%.

Sure, but that inertia carries you over the myriad alignment traps strewn like potholes over the face of your production–possibility frontier.

Re: Mental health in software engineering

#318
post #26

Earlier quoted context omitted.

It's always sales it seems. We're doing stuff under the gun right now because sales promised a huge new client we had something that wasn't ready yet. They didn't bother to ask us, they just promised so they could get their commission.

Good salesmen can sell the product that we already have. Terrible ones can't, and instead sell a product we don't have and then frantically beg R&D to make that product right away.

Agreed on this. And there's also great people in the middle who keep sales people up to date with new features and deprecations if you want the system to work.

Re: Mental health in software engineering

#319

In almost 30 years of software engineering, I came to the conclusion years ago that most deadlines were entirely arbitrary. The business isn't going to fail if you slip a week, or frequently even six months and if it does its probably not the fault of engineering unless its so dysfunctional as to repeatably blow through its own delivery estimates. Sure there are regulatory deadlines, customer POC or delivery deadline…

> I came to the conclusion years ago that most deadlines were entirely arbitrary.

To add to this, many manager/leaders assume some kind of deadline is needed for every tasks.

They themselves manage their schedule by timeboxing and setting arbitrary due dates, feel extremely productive doing so, and expand that insight to the whole business. The base assumption is a task won't be done in a timely manner if there isn't a threat with a time limit on it.

On a human level, I also understand the appeal of having a set date for something to be done: there's a warm and fuzzy feeling of a well oiled machine churning stuff on a predictable schedule. But it's just cruel to subject so many people to a forced schedule just to manage someone's anxiety and scheduling OCD. Reality is complex, longing for making it fit into neet boxes is delusional and unproductive.

Re: Mental health in software engineering

#320
post #10

I'll dump this one here as it's still annoying me a bit. So one afternoon I'm sitting there and our sales guy John came in (you know who you are if you're reading this) and described what he'd managed to sell a client. I sat there and I scribbled on bits of paper for hours, did some research and went back to him with the point that it wasn't possible from an algorithmic perspective. Basically he'd assumed that if it…

The Silicon Valley Machiavellian TechManager way to deal with this situation is to say "Yes, we will do this, but only if I get an up-front bonus and a team of twenty." The CEO instead gives you 6 headcount and a bonus schedule with performance milestones. You put the team together. Drag things out as long as you can, managing upwards with bullshit and a charismatic smile, faking the goals when you can, while the tea…

> Yes, we will do this, but only if

Caution though, the CEO may recognize this as a classic CEO subterfuge.

If they are impressed, or believe they can draft off of your hubris, you may still be able to pull this off.

Post reply on HN