Live data from Hacker News

Mental health in software engineering

vadimkravcenko.com

121–130 of 440 posts

Re: Mental health in software engineering

#121
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…

People are promoted to their level of incompetence

Ergo all CEOs are incompetent. Explains quite a bit.

Re: Mental health in software engineering

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

maybe? the worst managers I've had are expressing real substantive emotional or general dysfunction. I don't know that training is really going to help with that. its also a big culture question. I personally view the model where the manager is 'in charge' as being fundamentally unhelpful, and alot of organizations as a whole promote this model. that alternative being 'the supporting adult in the room that trying to…

No doubt there are some managers like that.

My take from the linked article is that this person had the will and ability to grow but they lacked an internalised reassurance that it's okay when things don't go to plan and aren't perfect. Importantly, they were open to learning about emotional reasoning.

In my mind a good training course can provide that reassurance in the form of a statement like

> It is absolutely normal for managers to be constantly juggling a large number of nebulous demands, to finish most days without wrapping anything up, and to feel like there are a large number of unknown and uncontrolled variables. Do not work excessive overtime or refuse to delegate tasks in order to avoid this.

Re: Mental health in software engineering

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

Re: Mental health in software engineering

#124

Earlier quoted context omitted.

And this is an organizational failure, because the organisation has just promoted, without training someone to be a leader. You wouldn't expect a manager (from a non-technical background) to just start coding, so why would you expect a coder to just start managing.

This happens all the time because management is viewed as a promotion so you reward your best developers by giving them a job where they might suck and/or hate it. I think there are 2 big levers you need to address it: 1. Dual career ladders. You should recognize/reward some level of technical role (i.e. staff or similar) the same as management. Every senior person is a leader; I argue ICs have a tougher job because…

Management of course thinks that management is promotion from non-management and they manage the promotions. They are managers because they are better. How would they otherwise rationalize their higher salaries and power over other people?

Re: Mental health in software engineering

#125
post #112

Earlier quoted context omitted.

And this is an organizational failure, because the organisation has just promoted, without training someone to be a leader. You wouldn't expect a manager (from a non-technical background) to just start coding, so why would you expect a coder to just start managing.

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…

> Say, "the CEO". The same CEO who is trying to manage through deadline pressure,

I think this is a very broad principle that applies all over. For a very different example: I have seen police depts make dramatic turns - from pretty okay to dangerously awful to hugely better, entirely due to changes in sheriffs/chiefs.

Usual caveats apply. Bigger orgs take more time+effort to turn. Down is easier than up.

Re: Mental health in software engineering

#126
post #55

Earlier quoted context omitted.

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 do someting like this quite a bit. If I deem it's easier to do it myself than to instruct or supervise someone else doing it, I do it myself. This is quite often the case. I don't see how doing it the harder way would somehow help with not burning out. Do you think it's easier for your manager that you do the things than that he does them themselves? Have you tought of ways that you would make it easier for them fo…

>I do someting like this quite a bit. If I deem it's easier to do it myself than to instruct or supervise someone else doing it, I do it myself. This is quite often the case. I don't see how doing it the harder way would somehow help with not burning out.

You will most likely always be more efficient than the people who are less senior/just starting out. So then: when do you decide it's worth it to help those less senior team members become more efficient? Will you ever want to delegate? My experience was probably unique, but this kind of management style 1) undermines my work/communicates a lack of trust, and 2) communicates that you're not willing to invest in other people. But maybe the difference is that I was being explicitly delegated work, having my boss complete it unbeknownst to me, and then just getting silence.

Re: Mental health in software engineering

#127

Earlier quoted context omitted.

I'm glad you came to the realization that we need unions. We're also overmanaged because the actual managers e.g. the C suite thinks we need to be watched over. Historically the rate of workers to managers was way lower.

You think unions would solve this problem? Adding unions would just insert a whole other parallel management team that'll tell you what you can and can't do. They're not going to simplify anything.

Unions insert a potential for improvement because they come with critically different motivation.

Workplaces suffer from compulsions by MBAs, who prioritize shareholders and exec bonuses above the welfare of employees/consumers/company. A union has an ability to raise the priority of employees in this equation - and ease MBA pressures to exploit consumers and degrade the company.

But because unions are groups of people, they are subject to the same corrupting principle that afflicts every group of people.

Nobody, anywhere wants to clean their own house.

A union can be a force for good, as long as it's leaders+members continue to fix the internals that need fixing.

Re: Mental health in software engineering

#128
post #30

Earlier quoted context omitted.

I'd be curious what the algorithm was. Were/are there any approximate algorithms that could have approached the problem?

It was proximal routing optimisation in this case to decrease operating costs. They already had good approximation algorithms but they sold better than possible for a higher price than competitors and couldn't deliver.

Sounds like the sort of thing that if you had invented it, it would be silly to part with it for a simple wage.

Re: Mental health in software engineering

#129

Earlier quoted context omitted.

I do someting like this quite a bit. If I deem it's easier to do it myself than to instruct or supervise someone else doing it, I do it myself. This is quite often the case. I don't see how doing it the harder way would somehow help with not burning out. Do you think it's easier for your manager that you do the things than that he does them themselves? Have you tought of ways that you would make it easier for them fo…

>I do someting like this quite a bit. If I deem it's easier to do it myself than to instruct or supervise someone else doing it, I do it myself. This is quite often the case. I don't see how doing it the harder way would somehow help with not burning out. You will most likely always be more efficient than the people who are less senior/just starting out. So then: when do you decide it's worth it to help those less se…

If it's not something urgent or someting that will not blow up on my face, I try to delegate. And delegation does work fine for many cases. I also do like to help, especially in form of pair programming or similar hands-on. There are some that don't seem to like this kind of help though.

A major problem I encounter is that people I delegate to don't say when they don't understand something or don't reach out early enough when they get stuck. I always say that come to ask if you get stuck on something for more than a half a day or so. Unfortunately most people don't even when I ask them to.

I do understand that they may think that they don't want to bother by asking. But in reality when they ask soon, it's usually very easy for me to answer but when they don't, they either don't progress at all, so I may have to do it anyway to stay in schedule, or they get into a mess that's a lot harder to fix.

And it's not really to blame them. I notice myself acting similarly when I do stuff I'm not experienced with. What I do try to consciously do is to tell when I don't understand something, although I probably fail at this too quite regularly.

Re: Mental health in software engineering

#130

“Your lack of planning is not my emergency”

"It was. Now you are fired." how it typically goes at startups.

I was worried about getting fired at these sort of places until I saw how they behaved when I quit a few of them.
Post reply on HN