5 ms·
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"
by mrsilencedogood 1y ago
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".
- alxlaz 1y ago> 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.
- taurath 1y agoAgree - 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.
- dogleash 1y agoVery 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."
- Qworg 1y agoThe issue with your last statement is that it _is_ part of your job and an increasingly important one at that. It is _also_ your job to make them less bad - this is good because your incentives are aligned. If they both can't be of use and can't be made better, then you need management to step in.
- deleted 1y ago[deleted]
- Clubber 1y ago>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. Maybe I'm just old and salty. Get off my lawn!
- bugh 1y ago> “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.
- rjbwork 1y agoThis 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.
- buuuutb 1y agoYou 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.
- sh34r 1y agoYou'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.