Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How learned helplessness happens in engineering teams

okayhq.com

Post reply on HN
Print view View original

131–140 of 220 posts

Re: How learned helplessness happens in engineering teams

#131

Post by aunty_helen »

This article is bashing BigCo while letting move-fast-and-break-things Startup inc. off the hook.

Just because the fires are different every day at Startup Inc. doesn't mean we're not being conditioned to endure suffering.

Case in point, a previous BigCo on call roster that I was required to partake in, sucks, makes you lose will to live, keeps you up at night, nothing documented, on-call phone ringing 5-7 of the nights in the week.

I tried to improve this process and was mildly sucessful even if that was just to get these incidents recorded.

Fast forward to my next job at Startup Inc. and their on call roster, sucks, makes you lose will to live, keeps you up at night, nothing documented, on-call phone ringing less but still often enough and with higher urgency.

The source of the two problems was different most of the time, one being a lack of training and effectively giving children knives.

The other being moving fast and breaking things resulting in things breaking after it was declared that version x.x went out without any issues just like the CEO wanted.

Re: How learned helplessness happens in engineering teams

#132

Post by cntainer »

erehweb wrote: post #56
cntainer wrote: post #28

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 an…

That might be just a story, rather than something that actually happened. https://www.throwcase.com/2014/12/21/that-five-monkeys-and-a...

yep, that's why I called it a story, not a scientific experiment. It could even be read as a kind of anecdote of parable.

While oversimplified, it can serve as a good example on how an initially rational practice could easily became dogma even when the initial stimulus is no longer present.

Part of my day job in the past 2 years has been to consult a client in refactoring/rewriting an old platform. The client's old team is still in place and even if we've added some new people just to try and change the mindset, the inertia of the spaghetti codebase coupled with the client's short and mid term financial goals as well as the "traditions" of the old team has stopped us from enacting any groundbreaking changes.

I guess the moral is that there are many forces at play in this kind of setup and stories like these can help in framing some of them in a fun way.

Re: How learned helplessness happens in engineering teams

#133

Post by int0x2e »

jcims wrote: post #81
firebaze wrote: post #23

Earlier quoted context omitted.

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.

There are a couple of amazing talks by Dan North, where one of the ideas he shares is that the entire idea of technical debt is wrong - it implies that "good" code a team produced is an asset and "bad" code is debt, and applies a set of moral judgements where teams that produce this debt are bad. Instead - code is neither an asset or debt - it's just cost. It merely is a direct result of whatever effort the team has spent in the past, but at any moment it could be greatly simplified or even replaced by a new open source library or commercial tool. If good code was an asset, replacing it with something would be rare, but history shows us we keep replacing libraries and entire products despite some of them being made up of really great code.

Re: How learned helplessness happens in engineering teams

#134

Post by agumonkey »

secondaryacct wrote: post #82
agumonkey wrote: post #39

Earlier quoted context omitted.

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

Well first of all I don't consider work groups as solids, it's more like a non newtonian fluid.

And reputation, enemies.. all of these are absurd notions to me. It mostly shows immaturity in our notion of work and society. And I'm not asking for people to find solution to state finance, but even for changing the simplest thing, people will resort to primitive behavior. It's child like behavior mostly.. and the bad side of childhood, not the "let's make something fun for everybody" more like "boss doesnt like me so i wont move a finger". In those structures everybody becomes everybody's enemy, and it's a super sad sight.

Re: How learned helplessness happens in engineering teams

#135

Post by trabant00 »

I have a completely different perspective: processes in a company reflect the people and the relationships between them. It is on these levels you must operate in order to bring change. As an engineer you have very little power to do so. So leaving and finding a different team is often the right choice when you are unhappy. From my experience staying and fighting an uphill battle is an exercise in futility which will bring more unhappiness to you and the people you are trying to change.

Re: How learned helplessness happens in engineering teams

#136

Post by therealdrag0 »

hsn915 wrote: post #96
jreese wrote: post #40

As a member of a core infra/"foundation" team, the biggest drain on my soul is the number of other engineers that are helpless, or never learned how to find solutions on their own. They never search wikis, look for similar posts on internal groups, or even read the error message from the tool that tells them exactly how to fix the problem they're asking about. When the culture has become "google everything", but you…

Think about it from the other side: Dealing with the infrastructure is your job. You know the ins and outs. It doesn't seem complicated to you. For someone who is dealing with the application logic, having to context switch to infrastructure is painful. I have no idea how you have set things up. When I read your documentation I'm just baffled at the sheer amount of complexity. I don't want to deal with it. It's not m…

Think about it from the other side:

Infrastructure is like application dev in that it’s a bundle of histories of feature work over time and with many contributors, and many customers with competing wants and not enough time to satisfy everyone.

Granted a primary goal should be to have simple APIs/workflows for app devs to use, but complicated insides is as natural as any advanced system.

Re: How learned helplessness happens in engineering teams

#137

Post by therealdrag0 »

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.

Huh? Like what specifically? All 4 cloud software places I’ve worked have had unit testing standards, cloud backups, even disaster recovery environments, etc. and none of these were mega corps. 50-1000 employees.

Re: How learned helplessness happens in engineering teams

#138

Post by vimwizard »

JohnBooty wrote: post #108
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 hit so close to home for me. At my last two jobs, I've simply burnt out from hitting this sort of wall over and over. Everything I suggested was just flatly denied as impossible [...] 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. For anybody (100% rightfully!) wondering if it's my fault: (1) I've been consisten…

>The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.

I came to this conclusion after watching the place I work at for 2 and a half years fail to implement any of the grand ambitions management had in their heads. We wanted code review, pull requests, build pipelines, automated releases, updated OS's, logging, disaster recovery, you name it. No one had the experience, time, or energy to implement it, so it falls on one or two juniors (me) to quickly learn and implement while learning. No one is hired with experience in any of these topics, only fresh-grads that will replicate the garbage you're trying to get away from are hired, because they will on paper be producing more features for less financial cost.

Re: How learned helplessness happens in engineering teams

#139

Post by oceanghost »

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.

This strikes a chord with me.

Ironically, the only way to minimize the "game playing" is by mastering them. There will always be people out there whose only real skill is manipulating the people around them, and who will deploy that skill at full force.

I'm not saying you should manipulate the people around you... but the twin powers of, "understanding whats going on around you" and "documenting everything", go a long way.

Re: How learned helplessness happens in engineering teams

#140

Post by adminscoffee »

hsn915 wrote: post #96
jreese wrote: post #40

As a member of a core infra/"foundation" team, the biggest drain on my soul is the number of other engineers that are helpless, or never learned how to find solutions on their own. They never search wikis, look for similar posts on internal groups, or even read the error message from the tool that tells them exactly how to fix the problem they're asking about. When the culture has become "google everything", but you…

Think about it from the other side: Dealing with the infrastructure is your job. You know the ins and outs. It doesn't seem complicated to you. For someone who is dealing with the application logic, having to context switch to infrastructure is painful. I have no idea how you have set things up. When I read your documentation I'm just baffled at the sheer amount of complexity. I don't want to deal with it. It's not m…

there is a saying, you may think you are intelligent but you are only as intelligent as what your student is able to learn from you.

it's basically "beautiful mind" syndrome, and it's steeped deeply in ego.

now if on the other hand that teacher is coming from a place where it was hard for him, he probably has a sense of empathy and is willing to teach.

Post reply on HN