Earlier quoted context omitted.
I agree with this and would add Slack to the equation. It's just faster to ping a senior engineer on Slack than to spend 5 minutes looking into an issue. I've also seen new hires burn an entire week because they were afraid to ask a question. But I think the balance has definitely shifted towards asking too much help...
When I started at BigCo, the recommended policy was to spend two hours trying to solve it yourself, including searching the wiki, debugging code, etc. If you hadn't made any progress in that time period, then ask someone from your own team or make a post in a related internal support group. Only after exhausting that route, and getting no help, should you escalate to the team/oncall that owns the tool/service you are…
How learned helplessness happens in engineering teams
191–200 of 220 posts
Re: How learned helplessness happens in engineering teams
#192Earlier quoted context omitted.
Find the/a leader, make sure they can secure your interests, empower them?
Unless you're being paid to coach the leader, this is just work their boss should be doing and which you're doing for free.
They asked what can you do besides leaving.
Should just leave.
Re: How learned helplessness happens in engineering teams
#193Earlier quoted context omitted.
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 co…
Did you make your situation clear to your team? I find that is the biggest source of frustration.
Re: How learned helplessness happens in engineering teams
#194Earlier quoted context omitted.
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…
The drain I am talking about is a complete lack of due diligence on behalf of those asking for my help (and my limited time/attention). When the error message contains a clear message and a URL with step-by-step instructions, and the person in question just pastes the full error message including the URL, and asks "what do I do?" When a problem can be solved by responding with "please follow the instructions in the e…
devops sets up something convoluted that they for some reason like.
Developers are confused by the thing. It causes them endless problems.
Documentation is sparse, or out of date, or just plain wrong. The instructions to fix problems omit key requirements because the person who wrote them just assumed the reader knows about X and Y when the reader often has no clue. You follow the instructions and the problem is not solved, and maybe to make matters worse, you run into new problems.
The way I see it is: if developers enjoyed dealing with infrastructure, devops jobs would not exist, it would just be something that developers do as part of their job.
As a devops engineer, you should think of your fellow software engineers as your users, not as your "project members".
Your job is to make it as painless and problem-free for them as possible. If problems arise constantly, that's not the user's fault; that's your fault.
Re: How learned helplessness happens in engineering teams
#195Earlier quoted context omitted.
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…
> My intuition is that this complexity is not actually needed if you remove all the cruft and think from first principles about what the actual problem is you are trying to solve. Have you ever worked on infrastructure? This comment is wrong on soo many levels.
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 sense that I have setup the infrastructure for websites that can handle thousands of concurrent requests, and the infrasturcure I setup is stupidly simple, everyone who sees thinks there must be something missing. But there isn't anything missing. It handles the job much better than the complicated mess that I see in all other companies.
Now, the thing I haven't done is actually setup the infrastructure for a truely distributed system that is horizontally scaled. I do all my scaling vertically because computers are so fast and storage capacity is so large that one server can handle thousands of concurrent users without nearly sweating.
Part of the reason everyone else has a super complicated infrastructure is because they chose bad software technologies to develop their applications, such as, python.
Yea, if your application backend is in python or ruby, you have no choice but to create a complicated infrastructure. Because those languages are so slow, you just cannot scale vertically. That's not an option. You get an explosion of complexity because you also need additional servers to handle stuff that would normally just be part of the application code.
For example, when I program in Go, and I need to cache some data, I just create a map, or something, to cache data in memory. But if you have Ruby, you can't just do that! Since you have 200 application instances running on aws, you want to use something like redis to act like a shared distributed cache. So now your infrastructure has to include information about how the application servers need to communicate with the caching servers.
All of this is unnecessary complication that can go away if you stop what you are doing and just analyze the problem from first principles.
Your massive convoluted infrastrucutre is only there to compensate for the bad decision you made early in the process, which was to use a slow interpreted language to write the backend of your system.
Most of the time the real solution to scaling problem is just writing better (and simpler) code.
I've seen at more than one company, how this complciated infrastructure does nothing to make the application robust because it grinds to a halt when there are about 1000 concurrent users.
Re: How learned helplessness happens in engineering teams
#196Earlier quoted context omitted.
Please don't invalidate other people's experiences.
that's a two-way street
If you however, do something about it, that counts for something. Not just asking others to do your job for you, without even asking them.
Re: How learned helplessness happens in engineering teams
#197Just 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…
The tech lead started out by complaining about...When he finished complaining... My manager doesn't know anything about the code, my project, or the release project. IOW, your team has no leadership and no management. Your team lead may be called that, but sounds like he doesn't lead at all. Your manager may be called that, but he doesn't manage either. This happens a lot when people are given responsibility without…
Re: How learned helplessness happens in engineering teams
#198Earlier quoted context omitted.
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…
This is the truth, as far I'm concerned. We say "technical debt" instead of "bad code" because the former sounds more acceptable in the business environment. But it's still the same meaning, code we don't like, and code we don't.
Re: How learned helplessness happens in engineering teams
#199Earlier quoted context omitted.
Plenty of openings out there. Not worth suffering to get a 2% raise rather than 1%. If they won't let you fix something once a month it's time to get moving. Learned helplessness, indeed.
It isn't learned helplessness if you are actually helpless.
Yes, there is 1% who can't follow that advice for various reasons of desperation. Not enough to continue arguing this thread.
Re: How learned helplessness happens in engineering teams
#200Earlier quoted context omitted.
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.
Lots of companies have no "fundamentally difficult problems" when it comes to their software. Lots of software developers don't have any of these problems to solve. (I'm also against this "YOLO because it's fun" attitude, though.)