Live data from Hacker News

How learned helplessness happens in engineering teams

okayhq.com

211–220 of 220 posts

Re: How learned helplessness happens in engineering teams

#211

Earlier quoted context omitted.

This article helped me to understand "the game" a little better. https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

I've read these articles back and forth and I honestly cannot grasp more than 30% of the ideas. The loser eludes me, the middle layer same.. I'd love to poke in people's head to be sure what are the motives behind their behavior (the main one I assume being a balance of respect/equality and money).

> I'd love to poke in people's head to be sure what are the motives behind their behavior

I suspect you're approaching things too logically. In my experience most people do something then rationalize why they've done that later, if at all. And that's without any perceptive, or memory problems or anything like that, and assumes good intent-- which a lot of people don't have.

I also suspect some people's brains work so differently from my subjective experience that there's effectively no way to understand them.

A very hard lesson for me was "don't try to use logic to understand irrational people."

I now tend to think of people in terms of, "can I predict a response or action by them?" By observation, you can kind of build a set of rules and start hypothesizing about them and update your model when you get more evidence. But you still need to be mindful that different conclusions can be reached with different or conflicting information.

It worked so well on an ex of mine that she thought I was spying on her somehow, because I often had reasoned out things I shouldn't have known. The most terrible example-- that she was cheating on me. I came to this conclusion from a few bits of evidence-- she wasn't really the curious type. Most of the film, music, etc she knew about were from me. And then one day, she started talking in detail about a film I knew she hadn't seen, and she used a word I had never heard her use before.

This lead me to think, "She's having some sort of social interactions that I'm unaware of, and they're probably watching movies together, and if its being kept secret, its probably something bad."

And I was correct.

Re: How learned helplessness happens in engineering teams

#212

Earlier quoted context omitted.

Hiring Rails devs? I'll work for you! Seriously, though: I firmly believe that most managers do think and act like you do. (I've been in lead and/or management-lite roles myself; I don't view management as some weird or evil "other") But, I think it only works if that sort of change is valued all the way up the org chart and folks at each level are empowered, incentivized, and motivated to address the pain points of…

I‘m working in a strongly hierarchical org, whit very high N number. What shocking me and blocked good ideas or solutions is that: The persons in charge, empowered to make decisions are so far from reality. And the outcome of their decisions has no effect on their lives… And not because they are evil, just unable to understand the problem. (Once some guy asked, why we put bugs in the code…) Now I fight to change this…

    I‘m working in a strongly hierarchical org, 
    whit very high N number

    The persons in charge, empowered to make 
    decisions are so far from reality
Yeah. I've seen it happen when managers are literally just a level or two up and don't come from an engineering background.

I think it's inevitable, honestly. I think it's fundamentally impossible for management to really understand or respond to in-the-trenches stuff. That's like tasking the mayor of a large city with sweeping the streets or physically fighting crime themselves, in person. They literally cannot spend enough hours in the shoes of the folks under them to understand that stuff.

And, that's fine. Management just needs to have the humility to understand that, and has to empower people/groups that do have their boots on the ground to fix those problems.

It's not unique to this industry, although I do think the newness and explosive growth of our industry may make it particularly prone to this kind of thing.

Re: How learned helplessness happens in engineering teams

#213
post #178

Earlier quoted context omitted.

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.

You can have those things in theory, but they need to adhere to certain quality standards to count on them in practice.

Parent said they visited 10 jobs that had no quality, I have 4 places that in practice try to have quality. So either they were hyperbolic, or has unrealistic standards, or bad luck, or bad job selection heuristics.

Re: How learned helplessness happens in engineering teams

#214
post #195

Earlier quoted context omitted.

This comment is not wrong on any level. I have worked in many aspects of web development. I know for sure that everything in the process is way too complicated for what it does. Unnecessarily so. There's no reason to think that infrastructure is the one place where all the complexity is there for good reason. Have I worked on infrastructure? Yes and no. Depends on what you mean. I have worked on infrastructure in the…

I guess there is a disconnect between what you mean by the term infrastructure and what I mean. Let's take an example, say Reddit. You want to support iOS, android and web. All platforms have the same core data but maybe have different APIs for optimizing queries, e.g. you may want to use server side rendering for web. So here's some of the microservices that you will use server side. I will label which I consider to…

If by infrastructure you mean microservices, then it's even worse.

I wholly reject "microservices", the philosophy and ideas behind it, the tooling and the culture surrounding it.

It's not only too complicated. It's worse than useless. It's extra work that produces negative value.

Re: How learned helplessness happens in engineering teams

#215

Earlier quoted context omitted.

I've read these articles back and forth and I honestly cannot grasp more than 30% of the ideas. The loser eludes me, the middle layer same.. I'd love to poke in people's head to be sure what are the motives behind their behavior (the main one I assume being a balance of respect/equality and money).

> I'd love to poke in people's head to be sure what are the motives behind their behavior I suspect you're approaching things too logically. In my experience most people do something then rationalize why they've done that later, if at all. And that's without any perceptive, or memory problems or anything like that, and assumes good intent-- which a lot of people don't have. I also suspect some people's brains work so…

That's too cold an approach for me

I'd rather try to connect emotionally and see who's responding. I grew up the way you think and I'm tired of it. If someone doesn't like me (or doesn't like me anymore), no problem, then I'll find other people, all I want is honesty.

That said, I've encountered the post rationalizing lying kind just too many times.. :)

Re: How learned helplessness happens in engineering teams

#216

Earlier quoted context omitted.

I‘m working in a strongly hierarchical org, whit very high N number. What shocking me and blocked good ideas or solutions is that: The persons in charge, empowered to make decisions are so far from reality. And the outcome of their decisions has no effect on their lives… And not because they are evil, just unable to understand the problem. (Once some guy asked, why we put bugs in the code…) Now I fight to change this…

I‘m working in a strongly hierarchical org, whit very high N number The persons in charge, empowered to make decisions are so far from reality Yeah. I've seen it happen when managers are literally just a level or two up and don't come from an engineering background. I think it's inevitable, honestly. I think it's fundamentally impossible for management to really understand or respond to in-the-trenches stuff. That's…

I see your point. In my BigCo I don’t see real empowering. I agree with you this is a key factor.

My dilemma should I leave or not? Is it better or worse in other place? My helplessness is, I reached limits where I know I can‘t improve the situation anymore. But I see a general pattern and so I am pessimistic to find a better place…

Re: How learned helplessness happens in engineering teams

#217

Earlier quoted context omitted.

> because they will on paper be producing more features for less financial cost. And from a business perspective, that is the correct choice. So make a better business case. Inform them that after investing Y hours on refactoring X, future development is expected to happen M% faster with N% less bugs. New features can be expected to be developed, tested, and shipped to production in S% less time. But be realistic. Do…

You're making this sound simpler than it is, I think. For the following discussion assume we're talking about management that is smart and wants the dev team(s) to succeed but is racing hard to hit various external deadlines and does not have a technical background. Inform them that after investing Y hours on refactoring X, future development is expected to happen M% faster with N% less bugs. I've tried variations of…

  > Do you have any articles, case studies, etc of how to express this to management that is
  > generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?
It is the "generally oblivious" that is the problem. Log holdups whenever a ticket takes significantly longer than the estimate. And be specific as to what the holdup was.

  > What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?
The same way that I come up with halfway realistic numbers for any other dev work. I pull it out of my donkey. Then double it.

  > The best thing I could think to do is have the team minutely log all lost minutes productivity
  > caused by delays and inefficiencies that the proposed fixes could address.
Yes, log it! It does not have to be by the minute. Honestly, if the holdups are only causing minutes of delays, then they're not so bad unless your ticket take only minutes to complete anyway. My general rule is to log any holdup of more than half an hour, or more than 10% of the time estimated to develop a feature/bugfix. Very loosely, of course.

Re: How learned helplessness happens in engineering teams

#218
post #96
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…

Totally agree.. As a rails dev I'm asked to dig into ops.. Not once is the JS team asked to build out the rails code, or fix things in it when it glitches. The api business logic falls down, and thats on me.

But when ops is glitchy, I have to blow half my day faking interest in docker? I mean best case, I learn how ops works, and then what. I become the one they tap when ops is swamped, then before I know it, I'm doing ops.

And I quit, because as much as I love the ops team, I hate the gig. I'd hate to be a designer, or a BA. It's not where I find joy.

So when I hear people say.. Just follow these steps to trouble shoot, I wonder if it would be cool to tell that to our users..

Re: How learned helplessness happens in engineering teams

#219

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…

It may be, based on my experience as that tech lead who declines everything, that the tech lead has already thought of all this many times over many years, has tried to implement the required changes, yet gets blocked by higher ups. And it may even be that those higher ups sometimes know it too, and deny him based on their higher ups.

A lot of times learned helplessness is true helplessness with learned resignation.

Re: How learned helplessness happens in engineering teams

#220

Earlier quoted context omitted.

> I'd love to poke in people's head to be sure what are the motives behind their behavior I suspect you're approaching things too logically. In my experience most people do something then rationalize why they've done that later, if at all. And that's without any perceptive, or memory problems or anything like that, and assumes good intent-- which a lot of people don't have. I also suspect some people's brains work so…

That's too cold an approach for me I'd rather try to connect emotionally and see who's responding. I grew up the way you think and I'm tired of it. If someone doesn't like me (or doesn't like me anymore), no problem, then I'll find other people, all I want is honesty. That said, I've encountered the post rationalizing lying kind just too many times.. :)

I understand your feelings but I'm not saying you should do this with everyone-- just problematic or difficult people.
Post reply on HN