How learned helplessness happens in engineering teams • Hacker News Board

Re: How learned helplessness happens in engineering teams

#81

Post by jcims » Wed, Nov 03, 2021, 12:12 AM UTC

firebaze wrote: post #23

bxparks wrote: post #9

I don't think it's "learned helplessness". It is a rational, calculated tradeoff decision. In many situations, it is more painful to fix the underlying layers of technical debt, and more time consuming to fight the push back from the various teams that own different parts of the technical stack. It's far easier to just silence the pagers while on pager duty for that week. It's also caused by misaligned incentives. At…

Quite often "technical debt" from an engineer perspective is an asset from the leadership perspective. Make of it what you want, but code which is bad from a customer perspective usually doesn't live until it's legacy. And sometimes the technical debt cloud disappears after fully understanding the business rules and special cases which were the root cause for the code in question. This often gets overlooked and may (…

We need a different word. ‘Technical debt’ implies some kind of objectively quantitative zero sum game, when it is anything but.

Re: How learned helplessness happens in engineering teams

#82

Post by secondaryacct » Wed, Nov 03, 2021, 12:19 AM UTC

agumonkey wrote: post #39

NAHWheatCracker wrote: post #19

Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…

This is why I .. struggle to function in society. There are tribal forces at play that are beyond me. Or require me to play games I don't want to play. Social tissue is a strange medium and most of the time it's a friction generating engine. People complain, time passes on, nothing happens, repeat.

None of these are games: they're really just an expression of the energy you need to spend to change a rigid structure. And the more rigid, the more energy, just like a metal bar you'd be trying to fold.

You can change things but you must do it. You must put your reputation at risk, expense time that you wont be compensated for, go through conflicts you'd rather avoid, make lifelong enemies wether you succeed or not. Then, you changed the rigid structure once more and the next guy will either try to put it back where it was and face less resistance or fold it one more time and face even more.

You cannot teach a rigid structure agility just like you cannot teach iron to be silk, and the structure is rigid for a reason: size, cost, regulation, cultural beliefs, rot due to time, past mistakes (in my experience the largest factor: a mistake 10 years ago can justify 3 days a week of useless processes today) etc. You can change the structure but it's CEO-level work to change its rigidity.

Re: How learned helplessness happens in engineering teams

#83

Post by kodah » Wed, Nov 03, 2021, 12:53 AM UTC

NAHWheatCracker wrote: post #19

Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…

I've worked on a good number of teams just like yours. I always told myself things would be different when I was in charge. Then I was in charge.

I learned pretty early on that I have political capital, and very little of it. Instead, I have to have a manager that's pretty buck wild when I tell them I need them to be, and I have to deliver them some wins that will grease their wheels too. Good managers are hard to come by though, and if they get noticed they're promoted and gone in a couple of years.

Personally, I think the transactional nature of software positions is what largely holds us back. If I get promoted, then there'll be a new lead, and this cycle will start all over again.

Re: How learned helplessness happens in engineering teams

#84

Post by Kaze404 » Wed, Nov 03, 2021, 12:59 AM UTC

mek6800d2 wrote: post #73

JTbane wrote: post #26

Earlier quoted context omitted.

> We've done two other releases in the past month and both required a day of troubleshooting to fix issues. I feel you, it's especially frustrating when your product has such fragile and bespoke testing that things break on a regular basis. Then, us devs have to spend valuable time just troubleshooting.

Maybe I misunderstand, but if a product breaks regularly under "fragile and bespoke" testing, won't it break just as often, and probably more often, under robust and comprehensive testing? And if the product fails tests, who better to "just" troubleshoot the problems than the developers? (Perhaps you mean things break after nominal testing and subsequent release, but that's just shifting the time when the issues are…

I think the difference here is that with robust and comprehensive testing, it's immediately obvious when and where things break. Compared to a codebase with no testing, or fragile testing, where things break and you not only have to spend time fixing something, you also have to spend time finding what is even broken in the first place. That's where the frustration is, at least for me.

Re: How learned helplessness happens in engineering teams

#85

Post by Kaze404 » Wed, Nov 03, 2021, 1:13 AM UTC

halfmatthalfcat wrote: post #8

rectang wrote: post #7

Earlier quoted context omitted.

There's a certain amount of "YOLO" fast-and-fragile development I'm willing to tolerate or negotiate. It's not like I have all the answers, and everything is a team effort. But when I'm called upon to work entirely without tests, or with inadequate backups, or otherwise in ways that create a scenario where every keystroke I make holds imminent potential for disaster, I quit. I can do trapeze acrobatics if you let me…

Maybe it's just me, but not having the net provides some level of "fun". Most of the projects/companies/teams I've worked on didn't have tests, adequate backups or had scenarios where errant keystrokes blow up production but it's nothing that has been world-stopping and these jobs rarely involved anything were downtime equated to real harm (outside of the economics of the companies themselves, but usually nobody nece…

I will never understand this position. My life are already chaotic enough without factoring in the work-related part of it, it makes no sense to me why someone would actively invite chaos like the one you're describing. I'm much more excited by solving interesting problems or creating useful things than by having my work day interrupted by a production error that needs to be fixed immediately.

Re: How learned helplessness happens in engineering teams

#86

Post by tharkun__ » Wed, Nov 03, 2021, 1:18 AM UTC

halfmatthalfcat wrote: post #33

rectang wrote: post #11

Earlier quoted context omitted.

> it's nothing that has been world-stopping Well then you're talking about a completely different scenario than I am.

I would hope that world-stopping software (banks, critical infrastructure, healthcare, etc) have tests and all the things to prevent catastrophic error. For the rest of us, breaking things here and there in the name of moving faster is (anecdotally) more fun.

I think there exists something in between world-stopping as in healthcare (I want way more than just 'tests' there) and Facebook level (i.e. nobody really cares even though a lot of people will probably scream in "agony" when things don't work).

To maybe put it into examples:

    World stopping: Traffic collision avoidance system (TCAS) has a bug that lets planes crash into each other.
    Don't care: Not enough vegetarian meals made it onto the plane because of a bug in the meal reservation software.
    In between: Thousands upon thousands of people get stranded in some airport for 3 days because of a bug in the route planning software.

This was an example within the airline industry but I'd say there are many more examples of where enough people depend on something for things that do objectively matter enough to warrant "good enough" software and software development practices that don't result in large-ish outages that then need to be fixed. Inconveniences I'll take because we all aren't perfect, even with testing.

Re: How learned helplessness happens in engineering teams

#87

Post by nine_zeros » Wed, Nov 03, 2021, 1:23 AM UTC

sethammons wrote: post #57

nine_zeros wrote: post #30

My learned helplessness story - Another engineer fancies himself as the gatekeeper of our codebase. Nitpicks on PRs all the time. Always tries to change something. This time around, an engineer produced a fantastic design. But this gatekeeper engineer had something else on his mind. The gatekeeper did not even communicate his thought process but continued asking ridiculous questions. Later we found that the gatekeepe…

did you let their manager know? Especially valid with data that shows "look, before, ppl tried to follow process X, and now, as you can see, nobody even tries." Data, data, data. Management likes data.

No. I am also in learned helplessness mode. The manager doesn't appear to get that the gatekeeper engineer is stubborn.

I have nothing to gain by getting caught in the crossfire.

I would just quit after biding my time.

Re: How learned helplessness happens in engineering teams

#88

Post by afarrell » Wed, Nov 03, 2021, 1:23 AM UTC

zelon88 wrote: post #62

From the article; > Hold managers accountable: one of the key responsibilities of leaders is to create positive change for their teams. Once you notice a situation where you think everyone is in learned helplessness mode, make sure to notify your manager and follow-up until the problem is addressed. "Hey boss, I noticed that Bob and Joe are really helpless at their jobs and that you just kinda watch it happen." Yeah…

Whom do you talk to if you notice it in the CTOs?

Re: How learned helplessness happens in engineering teams

#89

Post by bmeski » Wed, Nov 03, 2021, 1:27 AM UTC

NAHWheatCracker wrote: post #49

Thrymr wrote: post #31

Earlier quoted context omitted.

> My manager doesn't know anything about the code, my project, or the release project. What... does he know? Fine, he doesn't get into the code itself. But the project and its dependencies? Yikes.

He's the scrum master for other projects and he deals with things like hiring.

This is the current norm.

Most Tech Directors or Tech Managers at my massive media company were previously front end or full stack devs who were good at coordinating (asking questions and never internalizing the answers).

Since they talk to so many people and have great rapports, they can easily manage people and conversations but they cannot manage a technical system because they think they can negotiate with it.

Usually the shit they need to know is 2 bash scripts and what build is in what env. Simple enough if you are so well educated with a degree and half a brain.

Re: How learned helplessness happens in engineering teams

#90

Post by Jensson » Wed, Nov 03, 2021, 1:30 AM UTC

NAHWheatCracker wrote: post #49

Thrymr wrote: post #31

Earlier quoted context omitted.

> My manager doesn't know anything about the code, my project, or the release project. What... does he know? Fine, he doesn't get into the code itself. But the project and its dependencies? Yikes.

He's the scrum master for other projects and he deals with things like hiring.

So he is HR and not a manager? A manager can evaluate your performance, if he doesn't know what you are working on then he isn't a manager. Whoever is evaluating what you do is your manager. If nobody is doing that then congratulations, you don't have a manager, you work in a so called self organizing team!