How learned helplessness happens in engineering teams • Hacker News Board

Re: How learned helplessness happens in engineering teams

#11

Post by rectang » Tue, Nov 02, 2021, 8:54 PM 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…

> it's nothing that has been world-stopping

Well then you're talking about a completely different scenario than I am.

Re: How learned helplessness happens in engineering teams

#12

Post by morelisp » Tue, Nov 02, 2021, 8:56 PM 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…

The fun should come from solving fundamentally difficult problems, not from someone fucking up a CRUD response because they didn't properly test their filter parsing.

Re: How learned helplessness happens in engineering teams

#13

Post by commandlinefan » Tue, Nov 02, 2021, 8:57 PM UTC

rectang wrote: post #7

commandlinefan wrote: post #3

> Complexity-related Learned Helplessness I've gotten used to just accepting that every job I have will involve a code base that uses up way too much memory to run in a debugger and doesn't have (or allow for) unit tests.

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…

> I quit

I did that early on. Then again, because the next place was the same. Then again, because the next place was the same. 10 places later, I finally realized they're all the same.

Re: How learned helplessness happens in engineering teams

#14

Post by commandlinefan » Tue, Nov 02, 2021, 9:00 PM UTC

b9a2cab5 wrote: post #6

Yhippa wrote: post #2

I have found that the biggest thing that can be done is to ask your people over and over again. And then also genuinely care about the situation and make it your goal to communicate to others that the problem exists.

Unfortunately people are very conflict averse and will avoid giving that sort of feedback if it means an uncomfortable conversation (particularly if whoever came up with the process is still employed). Even anonymous surveys are not really that useful because the most useful criticism stays exclusively inside peoples' heads. As a manager you have to have really good EQ to be able to read this sort of stuff implicitly…

> people are very conflict averse and will avoid giving that sort of feedback

I'm not (that) conflict averse - I'm perfectly happy to suggest, when asked, that we could deliver better results faster if we could spend some time fixing some non-customer facing problems, had better tools, and had a testing environment that was closer to the production environment. I have no trouble saying those things, but I've never seen any action taken on any of them.

Re: How learned helplessness happens in engineering teams

#15

Post by hinkley » Tue, Nov 02, 2021, 9:01 PM UTC

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…

Technical debt is all of the forms of self-sabotage that don't have clear metrics associated with them.

If they had clear, unimpeachable metrics, then you could increase your status by fixing them. Since they don't, few people engage with them. Worse, engaging with some of these problems can lose you status, and so tackling them becomes a form of self-sacrifice.

Re: How learned helplessness happens in engineering teams

#16

Post by ikiris » Tue, Nov 02, 2021, 9:04 PM UTC

teeray wrote: post #10

Has anyone actually overcome any of these bad situations? Or has there been a situation where “So and so quit because X, we need to change X.” You can’t change an org from the outside, but it’s also difficult to change it from the inside.

You can change to an outside org though. Rational self interest.

Re: How learned helplessness happens in engineering teams

#17

Post by rectang » Tue, Nov 02, 2021, 9:05 PM UTC

commandlinefan wrote: post #13

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…

> I quit I did that early on. Then again, because the next place was the same. Then again, because the next place was the same. 10 places later, I finally realized they're all the same.

That's regrettable. Investing in reliability and redundancy is an optimization problem, resources are always limited, it's natural for there to be tension and I've grown accustomed to that. My experience has been varied, with some organizations investing more than others.

Re: How learned helplessness happens in engineering teams

#18

Post by sz4kerto » Tue, Nov 02, 2021, 9:06 PM UTC

teeray wrote: post #10

Has anyone actually overcome any of these bad situations? Or has there been a situation where “So and so quit because X, we need to change X.” You can’t change an org from the outside, but it’s also difficult to change it from the inside.

Yes. It's really painful.

Imagine a 5 year old code base that doesn't even have technical debt: it's a manifestation of the technical debt itself. It's hundreds of thousands of lines of code, mostly with "emergent behavior". You can't release without spending days on clicking through the RC system manually to check what's broken. Also, your product is extremely complex because apparently the barrier to entry in your field of business is very high.

And you have no users.

Then suddenly users arrive.

What it takes is 1) management buy-in (they should be desperate enough) 2) engineers who are not willing to make compromises.

Also, as usual in crisis management, people who successfully manage crises are generally ousted after the crisis is over because the personality needed to solve crises is not compatible with peacetime modus operandi.

Re: How learned helplessness happens in engineering teams

#19

Post by NAHWheatCracker » Tue, Nov 02, 2021, 9:07 PM UTC

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

Both of us have been working at this company for about 3 years and we both have over a decade of experience in software development.

When he finished complaining, I started asking questions and making suggestions about how we can improve things. - Push back on the team that needs these urgent changes. Let them learn to do the release. - Deny the release since they didn't communicate earlier. - Improve the release process.

Everything I suggested was just flatly denied as impossible. - The other team doesn't know how to do the release. - He wants to be a "team player" so he can't deny the release. - Project managers will never allocate time to improve the release process.

I feel strange because I've seen this same thing for my whole career and I still try fight for what's right when others appear to moan and carry on.

However, my experience tells me that bringing this stuff to my manager is even worse. My manager doesn't know anything about the code, my project, or the release project. He may assume it's complaining for the sake of complaining. It has been used as ammunition in reviews against me.

Learned helplessness sucks and I wish I could do more. I don't think either of the suggestions in the article are feasible for many ICs. Teams are ambivalent to making improvements, and retrospectives carry very little weight. Managers are above the fray and won't be held responsible for by people below them.

Re: How learned helplessness happens in engineering teams

#20

Post by the_arun » Tue, Nov 02, 2021, 9:10 PM UTC

We need to add Team Politics as well. We often spend more time in right articulation to keep it diplomatically correct and communicate a risk/problem/concern - if it involves multiple teams. People often do not accept this communication and it goes for several iterations before they all arrive at work breakdown. Not sure there is a way to measure these churns.