Live data from Hacker News

Mental health in software engineering

vadimkravcenko.com

141–150 of 440 posts

Re: Mental health in software engineering

#141

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

If both have high priority, it's the same as both have low priority.

Re: Mental health in software engineering

#142

Earlier quoted context omitted.

I like using Out of Office for everything not work related. It shows up when anyone tries to schedule a random meeting on me. This is also a rare circumstance where having a disability is an advantage. Companies are legally required to allow me to prioritize my health over my job without discriminating against me. They aren't allowed to ask. I wish it didn't require having a disability to be treated like a human bein…

I just say "Taking PTO today." > Companies are legally required to allow me to prioritize my health over my job without discriminating against me. They aren't allowed to ask. Assuming you're not in the US? In the US, companies are required to provide reasonable accommodations for disabilities as part of ADA but can and (often) do ask for documentation of the disability and the specific accommodation requested.

Sorry, I didn't clarify, they can't ask why I'm taking leave for a disability. I definitely had to provide HR with documentation. That was a pain in the ass.

Re: Mental health in software engineering

#143
post #55

Earlier quoted context omitted.

>No trust in the team. Always doing shit themselves. No discussion. Yup, I've had a boss like this. Maybe my company was particularly dysfunctional, but I didn't have much experience with the projects and tasks I was being assigned. I definitely was not hiding it either. Then when I spent time trying to figure things out on my own, my boss would simply do the work himself and provide no feedback.

Currently have a manager like this and trying to determine how to deal with it. I’m basically just waiting for him to burn himself out from his own constant dysfunction and leave. He’s so engrained in this behavior I don’t even know how I could provide him constructive feedback to help him.

I’ve seen shitty engineering leaders go for decades in their chaotic ways. Don’t hold your breath

Re: Mental health in software engineering

#144
post #84
post #11

This is a person that should have never been in a leadership position. I have worked under these types of people that were great engineers themselves but couldn’t lead worth shit. No trust in the team. Always doing shit themselves. No discussion. Backdoor discussions. Always bending to the will of management. Everything is “important”/“critical”. It’s micromanaging to the worst degree. At the same time, I would likel…

> No trust in the team. Always doing shit themselves. This was one of the hardest lessons for me to learn. And when coaching other would-be leaders it often is a roadblock for them as well. As one moves into a leadership role it becomes critical that you learn to be ok with people doing things not the way you'd do them. You need to learn to accept close/good enough from your underlings. And the "enough" in close/good…

It is psychologically tricky to go from an engineer to a manager or lead. I also used to just feel guilty like I was offloading my work on other people who already had plenty to do. I did then later improve by managing their workloads and the long term roadmap to make sure everyone is working reasonable hours

Re: Mental health in software engineering

#145

I used to be in (moderate) awe of young college drop-out CEOs. Then I worked for a couple of them. Now I refuse to work for startups that have 20-somethings at the top, because they really do not know how to manage or lead. They are motivated by fear of failure and having accomplished nothing so far they treat others like garbage. Avoid.

Yeah, even some of the young middle managers really grinded my gears. Not even that young.

Late 20s early 30s anxiety ridden workaholics that make life miserable for everyone. They work their ass off to move up, then figure they'll get a team full of "thems".

Yeah no. You were promoted because the "thems" were wise enough, or otherwise unwilling to damage their health.

You're better and get more money power, congrats. Now lie in your bed that everyone else pulled the sheets off of and spilled crumbs.

Re: Mental health in software engineering

#146
post #57

Earlier quoted context omitted.

It's an oversimplification to say they "should have never been" a leader. In truth, they could have used specific training in prioritisation, delegation, and emotional intelligence. I find it's rare that this sort of training is provided. Instead, good performers are thrown into the deep end to see if they can hack it.

I have no idea where he's getting it from either. Dude seemed to just stress himself out too much. Organizations encourage it, and promote people that do it. It's also incredibly exclusionary. If you have the slightest neuroses, never be a leader! You'll find this is often a race to the bottom too. While presumably not applicable to him, you'd be surprised how many people and organizations have opinions about how imp…

It also makes everyone’s life harder. Engineering leaders who agree to insane and constant deadlines doom the company to be in constant fire fighting mode (at best). One of the most important things they do is expectations management and explaining tradeoffs to senior management

Re: Mental health in software engineering

#147

Earlier quoted context omitted.

the scalability characteristics approached "all the energy in the universe" levels of compute pretty quickly Something someone was doing in excel scaled up to taking all the energy in the universe? That does not sound right.

His point was they'd only done a small set in Excel as a POC. It's plausible that with an O(2ⁿ) algorithm you'd be looking at this kind of thing.

I just can't imagine what results someone would need that would mean a mandatory unscalable algorithm.

Re: Mental health in software engineering

#148

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.

You can develop a product and also do Ops for it, getting the best of two worlds.

Re: Mental health in software engineering

#149
post #112

Earlier quoted context omitted.

Don't say "the organization has just promoted". That's taking the face off of where the blame belongs. Say, "the CEO". The same CEO who is trying to manage through deadline pressure, placed into leadership someone who could be managed through deadline pressure. And who would transmit that pressure down the chain. Why? Because the CEO believed that this is how people should be managed. Which means that a leader who re…

Sure, the buck stops with the CEO. That said, if things are so dysfunctional that your only goal is to ascribe blame—which, incidentally, is a common behavior of bad managers—then you are already fucked. High performing teams require trust. Workers need to trust that management has a sense of what's reasonable, not take estimates out of context and generally listen to the pain points/challenges on the ground. Upper m…

I did not see the post itself as ascribing blame. The Head of IT here was very clear that he was hearing the messaging from the CEO, but the CEO was passing along pressure coming from the client. And clients learn to do this because the squeaky wheel gets the grease.

So lets not criticize for what did not actually happen.

Turning to management, your view on management reflects what works for tech. People who need to engage in complex thought will do their best work in an environment that reduces unnecessary pressure.

But not everyone does that kind of work. People in sales do better when they are pushed to meet a big audacious goal which is probably not realistic. Micromanagement is appropriate for people in a level 1 call center. And so on.

This means that a healthy organization should have multiple styles of management in play. And that means that it is important to have leaders in tech who can push back on the rest of the organization to enable the right style for software developers.

And now that we've talked about management a bit, mind talking about mental health? Because sure, bad management can cause mental health problems. But so can being a parent of children who are part of the current teen mental health crisis. So this issue is important, even if you fix management.

Re: Mental health in software engineering

#150
post #113
post #84

Earlier quoted context omitted.

> No trust in the team. Always doing shit themselves. This was one of the hardest lessons for me to learn. And when coaching other would-be leaders it often is a roadblock for them as well. As one moves into a leadership role it becomes critical that you learn to be ok with people doing things not the way you'd do them. You need to learn to accept close/good enough from your underlings. And the "enough" in close/good…

It is not just "not the way you'd do them". You were promoted for doing your work better than others. Those others did not improve because you got promoted. So you have to figure out how to get useful work out of people who are doing things in a worse way. And let them do things that way even though you already know what's wrong with it.

Yes that's also a challenge, and while in similar it's not quite the same.
Post reply on HN