Live data from Hacker News

Mental health in software engineering

vadimkravcenko.com

321–330 of 440 posts

Re: Mental health in software engineering

#321

Earlier quoted context omitted.

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?

Does an empathetic doctor not smile when they see their patients in good health?

Does a lawyer not take pride in a well-written contract that shielded their company when the client turned adversarial?

Does a former mayor not visit the parks they opened, the civil works projects that they helped organize or brokered deals for?

Does a salesman not remember their biggest sale? Their wildest outing? Their most critical conversation where they saved (or lost) a deal?

Does a restaurant manager not eventually sit down in a quiet corner of the restaurant, eat a meal in peace, and enjoy the background murmur of their patrons?

Does an electrical engineer not smile when they drive by a substation they helped design?

Does a teacher not remember their most successful students? Does a parent not remember their children?

Why would a software developer not want to know how long their projects lasted? Why would they not measure their impact in terms of messages sent, or mean-time-between-failure, or ROI / cost-to-benefit ratio, or smiles-per-hour? I'm not saying every line of code I write was one I was proud of, but I have dug into thorny problems, crafted solutions that were good enough, and been happy to see the code stay in service with only a very light touch needed to keep it on track. Of that, I am proud.

Re: Mental health in software engineering

#322

"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."…

At one point many years ago I was Director of Engineering for a company that was planning a major new version of their product. After I'd been there a few weeks I said to the CEO that I thought I had a pretty good understanding of the scope and challenges for the new release. The CEO said "no you don't" - which led me to ask why he thought this and he said he had thought up a new "must have" feature over the weekend…

Reminds me of my Director of Engineering gig where I was asked how quickly we could deliver a new feature that the CTO had thought of. After giving three different estimates on the spot and being told each was “unrealistic” and told to “try again” in a meeting with senior leadership present, I finally said “Just tell me what date you want to hear so we can pretend I said that.”

I was chastised for being unprofessional and embarrassing the department. Didn’t care then; no regrets now.

Re: Mental health in software engineering

#323

Earlier quoted context omitted.

Kindof, but a lot of time has been wasted figuring out something that someone else already has done.

Better to figure things out on your own than learn that you can always interrupt someone else when you get a little stuck.

Days are often wasted because you do that. That is at best, I'm now up to 4 different implementations of a complex protocol (at months each to build and debug) because nobody asked a question.

sure you shouldn't just ask for every problem, but don't struggle too long when someone knows the answer.

Re: Mental health in software engineering

#324

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.

> Most doctors are not spending solid 4hr blocks in flow focusing on a highly complex problem

I'm sorry but this is exactly what I meant by my original post. You don't realize that 4hr blocks in flow is an enviable luxury.

Granted my time was in a high acuity setting but let me cast it in more relatable terms.

Software 1 is brought to you with a complaint of the billing system dropping occasional transactions over the last 4 months. Now it is dropping 1 in 100 transactions. They use the Stripe API. It's your job in the next 15 minutes to debug and determine if there will be a complete service outage occurring within the next couple hours. If there will be an outage, you are expected to push a temporary fix to prod immediately and refer for continued review. If not, you must determine which parts of the billing system require referral for revision. Mind you that every decision you make can be reviewed years after the fact and can be litigated as they please.

Your assistsnt comes over with softwares 2 through 5 that were just submitted for your review. Software 2 has issues with a simple deadlock that could have been handled by someone other than you, but now it's your problem to deal with. Software 5 has been inexplicably ported from Delphi to Angular, and they've seen 2 others before you about why some of their native functionality broke, but now it's a big problem and they need you to look at it. There were some patches made by other devs but the stakeholders don't have access to them right now.

As you are looking into software 4,the assistant tells you "Dr zenzero, devops is on line 1 for you". They tell you that software 1 has more problems than described and it looks like it needs to be refactored in multiple areas. Software 3 keeps complaining to your assistant that you're ignoring them.

So no, "Most doctors are not spending solid 4hr blocks in flow focusing on a highly complex problem" because they don't get that luxury.

I get to do that now and it's bliss.

Re: Mental health in software engineering

#325

My wife is a dentist in the bay area - she can tell which patients work in tech based on how ground down their teeth are.

Same thing doesn't happen to say lawyers? Or any of the other white collar jobs?

It might, she just sees a lot of tech workers given the area and she's the "get to know you" kind of dentist so she's not just guessing who has what career.

Re: Mental health in software engineering

#326
post #288
post #215

Earlier quoted context omitted.

> Doctor, lawyer, and athlete are "jock" professions, while software engineering is very much a "nerd" profession. These words represent status and general level of attractiveness and therefore access to attention and sex. This is just your perspective and, IMO, it's pretty warped. Software engineering is not a low-status position, even compared to doctors and lawyers. You aren't lacking in status or not having sex b…

> Software engineering is not a low-status position Pay is not status. Software currently pays quite well, but in most companies today a developer is at the very bottom of the status curve. Developers are no longer allowed any say in what to build or how to build it, they are micromanaged by product managers and program managers and team managers and required to give daily status reports ("agile"). (I say "used to" b…

>Developers are no longer allowed any say in what to build or how to build it, they are micromanaged by product managers and program managers and team managers and required to give daily status reports ("agile").

I don't see how this is a bad thing, for a large and complicated product. For a small company where a team of 5 people can do the whole thing, sure, you don't need all this management, though I think some parts of the Agile methodology can be useful just for keeping people in sync. I worked in a small-ish team a while ago using an Agile methodology and it was fine: the program manager basically told us the feedback from the customer, and then it was up to us to decide what features to make to keep the customer happy and how to do it and how to schedule it. The Agile methodology just forced us to have regular meetings, and made it easy for the outside stakeholders to keep tabs on us and attend our meetings when necessary. Having daily habits in your life isn't a bad thing for many people, and that's basically what Agile was, in my experience: a way of having habits.

>Pay was much lower but respect was much higher.

No, it really wasn't. Maybe within the profession, but not to society at-large. Developers back then had little respect, until they started making lots of money in the dot-com boom, then people starting respecting the profession a bit more. Software development has never gotten the respect that doctors and lawyers get.

>Nobody wants the rookie heart surgeon, everyone wants the 60 year old who has done it thousands of times.

This might have some truth, but it's a bad view: generally, older surgeons prefer to use older surgical techniques that they learned decades ago, since they weren't trained on the newest techniques. The newer techniques generally are much less invasive and have faster recovery times. It's better to go with younger surgeons who have more modern training, but still some experience (i.e., not fresh out).

Re: Mental health in software engineering

#327
post #224

Earlier quoted context omitted.

The phenomenon of showing up at Stanford and telling some 21-year-old that he's Jesus Christ and that you're going to give him millions of dollars is a wen on the American business culture matched only by corporate raiding. It's the nerd version of college football/basketball recruiting.

That and Welchism are two big reasons why the business culture in the valley sucks.

I see Welchism (I assume we're talking about Jack of GE) as the opposite of lots of SV culture. They both suck, but for completely different reasons.

GE actually had real business units. Energy, aerospace, consumer, industrial, healthcare, you name it, they had a presence. Welch couldn't squeeze enough money to meet Wall Street's expectations out of these units, and didn't innovate when microcomputers were coming onto the scene in the 90s, so he cannibalized the company to boost share price at the expense of the business being able to continue long-term. Of course, he would be dead by then.

The guys in the valley are the opposite because many of them don't actually have a product, or even business, to sell - or they do, and the product itself is realizing it doesn't want to be sold. We've had social media and ad-based online services for 20+ years now and it's generally seen as a net negative for society. The subscription-based business model wouldn't work for most social media companies as it would limit the network effect and thus the TAM of the company's business. They're having to find more and more creative ways to monetize eyeballs when the eyeballs don't want to be monetized anymore.

Then you have the people who are swapping out their FLOSS licenses for proprietary ones on software offerings (looking at you Redis) because they realize if you just give stuff away for free, there is no monetization route, and dammit, they want - nay, deserve - their massive payday like the Steves and Bill and Larry got.

TL;DR Jack had a lot to sell at the expense of GE as a long-term going concern; SV has nothing to sell but wants to be a long-term going concern.

Re: Mental health in software engineering

#328
post #179

Earlier quoted context omitted.

Are you serious? That culture is why America still has high innovation while other Western and "culturally Western" countries that do not are largely stagnant. I'm amazed at how often I see people (largely Americans I'm guessing) criticize the very things that make their country a world superpower.

I'm still waiting for the USA to "innovate" on a way for everyone to get health care, although sometimes I suspect the lack of a solution there and general lack of regulation at large is part of why American has such "high innovation".

America is basically a cut-throat place where unchecked capitalism runs amok and you can make a fortune if you're smart and/or lucky in business. Getting everyone healthcare isn't going to improve things for people who like things the way they are. It would be a boon for many small businesses, yes (imagine if independent restaurants didn't have to worry about employee health insurance because they had government insurance), but tech giant companies don't care about that because they can afford to basically be their own insurance company, which helps them prevent competition from small upstarts.

So yes, I agree the general lack of regulation is part of why America has "high innovation", but it comes at a great cost to society, and yields a highly stratified society with a lot of losers, and this causes society to be rather dangerous, with a lot of crime, homelessness, drug abuse, etc.

Re: Mental health in software engineering

#329

Earlier quoted context omitted.

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

https://grugbrain.dev/#grug-on-saying-no > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of…

It site is an amazing and hilarious encapsulation of pretty much every conclusion I've come to after programming professionally for 20+ years (except maybe generics)

Re: Mental health in software engineering

#330

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…

> 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.

Who claimed it was?

Why does that even matter?

Whether you stepped in shit or are knee deep in shit, you're still in shit. Instead of having competitions about who is covered in more shit, why don't we help clean each other off? Stop comparing, we're not in a situation we need to triage. You are allowed to be sympathetic or empathetic to others, even if on average they have it better off than you. We're all humans. We benefit by coming together.

Post reply on HN