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.
Mental health in software engineering
311–320 of 440 posts
Re: Mental health in software engineering
#312One 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.
Re: Mental health in software engineering
#313Earlier 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.
Re: Mental health in software engineering
#314I'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…
Re: Mental health in software engineering
#315What 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…
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.
Re: Mental health in software engineering
#317In 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%.
Re: Mental health in software engineering
#318Earlier 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.
Re: Mental health in software engineering
#319In 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…
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
#320I'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…
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.