How learned helplessness happens in engineering teams • Hacker News Board

Re: How learned helplessness happens in engineering teams

#21

Post by vjust » Tue, Nov 02, 2021, 9:14 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…

YOLO-level development is a slippery slope... We had a case where 2 backends from 2 teams needed to interoperate.. to support a much talked-up UI/functional feature that was supposed to make our product standout from rivals. What was implemented was a rube-goldberg like contraption on the backend, where I dreaded being on-call as the talked-up UI feature was rolled out to more and more customers.

Oh yeah, we had unit tests all right, fragility didn't prevent that since you couldn't commit otherwise.

So there was no safety net. Just a constant dread of customers actually using the feature. So "fast-and-fragile development" resulted in a worst-case scenario as far as engineers were concerned.

The author says : "Their reports won’t tell the manager that they are having a terrible on-call experience". This was exactly what happened to me. And I quit one day, this was a big factor, two weeks out of a month (in my rotation) I'd be on the hook for supporting this morass of problems.

Re: How learned helplessness happens in engineering teams

#22

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

> Another employee or their manager teaches them it's a normal situation at this company

I have one particularly memorable situation where I tried to coach someone out of this. Sometimes the New Guy is the only one who can change something at BigCo, and the moment you convince them that fighting the bureaucracy is too hard, you've lost one of the few assets that person has.

As the processes get more complex, the time between onboarding and being able to tackle projects as an IC grows and grows. That outsider perspective may be one of the few things they're good for. That outsider perspective may be the only thing that ever reduces that gap.

I can't help but feel like people caught in that uncanny valley are damaged by being there, and one of the only ways I often have to improve morale is to point out how they're doing things - important things - that the Curse of Knowledge keeps me or my peers from doing well.

Re: How learned helplessness happens in engineering teams

#23

Post by firebaze » Tue, Nov 02, 2021, 9:19 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…

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 (edit) lead to refactoring/rewrite approaches which ultimately fail. As everyone knows, not a rare occurrence.

Re: How learned helplessness happens in engineering teams

#24

Post by WalterSear » Tue, Nov 02, 2021, 9:25 PM UTC

hinkley wrote: post #15

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.

Hinkleys's law: A measure that becomes a target might cease to be a good measure, but a target that isn't measured ceases to be a target at all.

Re: How learned helplessness happens in engineering teams

#25

Post by firebaze » Tue, Nov 02, 2021, 9:27 PM 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…

Most of the time managers are trying to be helpful, and most of the time they do in fact understand quite a lot of the background of a project.

I'd suggest to try to see the situation from their perspective, which you maybe already did, but sometimes this helps understanding a perceived lack of action.

Re: How learned helplessness happens in engineering teams

#26

Post by JTbane » Tue, Nov 02, 2021, 9:27 PM 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…

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

Re: How learned helplessness happens in engineering teams

#27

Post by lumost » Tue, Nov 02, 2021, 9:27 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…

A thousand times this. Good, steady software ownership is generally not what leadership wants.

Big new features are, it’s infinitely easier to build process improvements into new projects vs fighting for improvements in existing areas.

Re: How learned helplessness happens in engineering teams

#28

Post by cntainer » Tue, Nov 02, 2021, 9:28 PM UTC

This reminds me of a story I've read some time ago, about some monkeys and bananas.

A group of monkeys in a room. In the center of the room is a tall pole with a bunch of bananas suspended from the top.

Every time a monkey tries to reach the bananas it is hit with a torrent of cold water from an overhead shower. Eventually, the monkeys learn that something bad will happen if they climb up the pole so they just sit and don’t even try again.

If a new monkey is added to replace an old monkey, it will of course try to go for the bananas. But the original monkeys will grab and drag it down before the punishment is even triggered. After a while, the monkey gets the message and it stops trying.

Repeat the action of adding a new monkey in place of an old one enough times and you will reach a point where none of the monkeys know why they shouldn't get the bananas but they still won't try.

The story concludes by stating that even if we remove the shower at this point it won't really make a difference. The learned behavior is already deeply ingrained in the culture of the group.

Funny enough, I've seen this type of issue in many human teams/projects. And usually the inertia is far too strong for just a couple of engineering "monkeys" to radically change things if they don't get support from a few management "monkeys".

Re: How learned helplessness happens in engineering teams

#29

Post by thaumasiotes » Tue, Nov 02, 2021, 9:29 PM 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…

What is the difference between your team lead's bad reasons not to push internally for a better system:

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

and your good reasons not to push internally for a better system?

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

Re: How learned helplessness happens in engineering teams

#30

Post by nine_zeros » Tue, Nov 02, 2021, 9:29 PM UTC

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 gatekeeper engineer wanted to change the entire design to his own, even if his own design had major flaws. Wasted a whole quarter just because the gatekeeper didn't seem to want to "concede". He would much rather have engineers make bad designs than accepting his own missteps. The author of the design fought vehemently at the expense of their own time and energy. To what end?

Other engineers on the team have forever stopped producing design docs. Learned helplessness.