> The stress comes from people who are bad at what they do and are trying to make it someone else's problem. They don't have vision for how they will accomplish what is asked of them. In their imagination, there is not a clear set of steps that can be burned down over the coming days and weeks to arrive at something of value. In their minds it is all chaos and uncertainty and they are desperate for the assurance of someone who knows what's going on.
Lots of assumptions here, obviously the reality is much more nuanced than this.
Well of course it's more complicated. But these 2 broad strokes do resonate with me as a meaningful bucketing. There are some people I see DMs from and go "ooh" and some people I see DMs from and go "well there goes my morning hand-holding them through something they should already both know and have internalized".
> some people I see DMs from and go "well there goes my morning hand-holding them through something they should already both know and have internalized".
Pre-emptively, I'm not saying anything below applies in your case :-).
A mismatch in the threshold of "they should already both know and have internalized" is where much of the friction in high-stress organisations comes from.
I see a lot of people expecting, as the parent post put it, "a clear set of steps that can be burned down [to get to a good result]", but entirely oblivious to the fact that the people they expect it from:
1. Don't have the organisational authority to organise it -- they can do "their part" but they can't tell people on whose work they depend what to do.
2. Don't have access to the same task-specific information as the person who expects it of them, and don't know who to ask because teams are heavily compartmentalised and/or hierarchical.
3. Don't have access to the same kind of organisational information as the person who expects it of them.
Much like responsibility, deflecting blame comes from above. In my experience, what the parent poster says is true: people who are bad at what they do and try to make it someone else's problem is probably the most common source of stress. But it is also my experience that the middle leadership layers of companies where this is a chronic problem is almost entirely populated by managers who try to make everything other people's problem, and whose teams end up having to deflect everything by proxy whether they want it or not.
I think this is part of the nuance that's lacking in the parent post. It's very hard for someone to work significantly above their organisation's level.
Agree - initiative is not innate, it is trained and built with experience (of rewards for taking initiative), just as waiting for direction is trained and built with experience (of micromanagement and threats to safety).
The worst of the worst in my experience is the person who ignores the existance of 1, 2, and 3, assumes their coworkers who have been conditioned to not stick their neck out are incompetent and are trying to "get one over" on everyone else, and uses that as moral justification to backstab people who would be happy to work with them. The sad part is that the result will only reinforce their belief system.
You will always be surrounded by people, and how you regard them will inform your experience of them. If you allow yourself to force a false dichotomy on others, it will eventually be forced back on you.
Very reasonable counterpoint. It's unfortunate you're addressing a bland dismissal that shouldn't carry weight on it's own. Everything is always more nuanced. Doesn't mean grantparent poster didn't have a good reductive shorthand. The dismissal didn't even bother trying to reframe.
But it's always an uphill climb because there is an internally-consistent manager-brain line of thinking for the workspace they've created, and it's really good at Uno-reversing any criticism of workplace norms as a problem with criticizer.
"Oh, you don't like working with people that are bad at their jobs? Sounds like someone's just not senior-ing hard enough."
>It is _also_ your job to make them less bad - this is good because your incentives are aligned.
This depends on the number of shits given. I can make anyone better who gives a shit, but there are a whole lot of people who don't and are irredeemable. If this seems to be the case, it's best to cut bait and find someone else quickly. In the 90s, it was "hire fast, fire fast," and somehow this was discarded. It was a tough but highly effective model for making really good teams.
To add to this, it seems people are either unwilling or unable to figure things out for themselves. There are some proprietary things that are really tough to figure out, but it seems a lot of devs these days spend about 5 minutes, then ask for help. "Back in the day," devs would spend a day or two banging their heads agains the before asking for help, and they were better for it.
This no shits given isn't limited to developers, but BAs, PMs, Biz and QA people. It seems a lot worse today than 10 years ago. I ended up spending a good chunk of my day doing people's jobs for them. The people that were hired to take stuff off my plate end up putting stuff on my plate.
Personally I'm with you on "many people no longer able to figure stuff out". However, we may differ on the time frames we're willing to "take" from them.
Back in the day, you figured stuff out on your own, because you had no other resources. I remember breaking my computer's ability to boot into a working DOS prompt (too long ago to remember what exactly went wrong and how I fixed it). I had a few hours until I would have to tell my dad that I "broke the computer" I had just gotten. That was motivation to try a lot of things and figure it out. My dad never knew in the end coz I fixed it. I also had no internet or other people around to ask for help even if I had wanted to.
But today, if I see someone struggling for a day or two on something that in the end I'll be able to solve for them in less than 5 minutes once they do ask, then I do think that's too long given they have the whole wide internet, AI tooling as well as coworkers to help them out available to them. The worst for me is when they struggle with the same type of stuff over and over or when they are unable to pick up the strategies I used when solving it for/with them. I try to solve things with them as much as I can but with some people it's just too frustrating. Like you want to just throw lots of things at the wall quickly and see if they stick but they're too slow / don't even seem to understand the concept or don't have enough ideas of what to try and throw at the wall.
You're not protecting your time correctly if helping a colleague out wipes out your morning. Schedule a meeting and time-box the assistance. If it's not enough, schedule something else in a day or two. Teach the man how to fish and all that.
> “well there goes my morning hand-holding them through something they should already both know and have internalized".
So where you work everyone works on the same things every day and the same patterns?
Sounds pretty circular if everyone just lives by the subset of understanding you prefer.
This is what smacks truest from my experience; companies stagnant because of workers like you focus on memorized maintenance routines. Internal evolution comes to a stand still as attention is put on memorization of existing process not evolution.
Again just anecdotally coworkers like you describe could be put to evolving process they seem to not connect well to. But patronizing seniors who just know codified routine, hold orgs backs.
This is almost delusionally disconnected from the types of dysfunction I've seen among juniors after years of working at the same company where they should have learned some basic shit like being able to e.g. properly read a stack trace, diagnose an issue by reading/searching logs, not storing secrets in git, etc.
I'm always willing to work with people on code/system design - in fact it's my favorite part of my job when someone says "how can I do this beter?" - but it is excruciating to have to handhold someone through a basic diagnosis routine for or provide the same basic feedback about logging or security the nth time.
You don’t have to. You chose the work, the employer.
In my experience your special literacy is everywhere these days. Lots of unemployed with your skills.
Excruciating dealing with colleagues like you that think we come hear to read your intrusive thoughts about others effort. Whole lot of contexts you fall short in.
More sad little man needing validation for his prior effort to get where he is. Eh, tough. Like I said your skills are everywhere; good job you’re a VHS copy of a VHS copy?
Great work following the social trend!
…Aside from configuration of machines others make, with software others make, what have you done that obliges us to bow and courtesy and earn your validation?
This website is a toxic mess. Am psyched the world has seen enough of software dev now to understand it’s real economic value, and the end of ZIRP pruning tech of empty economic effort.
I actually do a lot of mentoring and pairing. I actively move to get people that consistently fall short out of organizations. I'm sure there's plenty of work for people that consistently fuck up but can kind of stumble through making computers do stuff, I just don't want to work with them.
Being/staying motivated is like half the battle. Once more than half of the team has stopped caring the project is essentially dead. You should get away as soon as possible. In my experience as long as you care about the stuff are doing you are better than the bottom half of developers.
The coastline paradox, also known as "How long is the English coastline?", is the counterintuitive observation that the coastline of a landmass does not have a well-defined length. This results from the fractal curve-like properties of coastlines.
> The prevailing method of estimating the length of a border (or coastline) was to lay out n equal straight-line segments of length l with dividers on a map or aerial photograph.
> the sum of the segments monotonically increases when the common length of the segments decreases. In effect, the shorter the ruler, the longer the measured border
> The result most astounding to Richardson is that, under certain circumstances, as l approaches zero, the length of the coastline approaches infinity.
Lots of assumptions here, obviously the reality is much more nuanced than this.