[alphazard]

In software, often the people are the source of stress. Building the software is easy to many in this industry, and the vast majority of the value produced came from someone who thought creating it was easy. Being surrounded by rock stars all doing something they find easy is sublime, and I encourage everyone to seek out those environments. They exist and are fleeting.

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.

The relationships that one develops with each category of person are fundamentally opposite. One is about enticing repeated interactions: You really get it, how do we work together in the future? And the other is about keeping a polite distance to prevent repeated interactions. How do I avoid meetings, projects, shared responsibilities, and future employment opportunities that involve this person?

[barbazoo]

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

[mrsilencedogood]

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]

> 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]

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.

[dogleash]

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

[Qworg]

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

[Clubber]

>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!

[tharkun__]

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.

[sh34r]

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.

[bugh]

> “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]

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.

[buuuutb]

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.

[rjbwork]

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.

[gopher2000]

Everyone: "Other people are so bad at what they do. Not me though"

[o_m]

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.

[ngangaga]

Reality is always more nuanced. That's kind of reality's deal.

[lioeters]

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.

[vladgur]

Am I the only one that finds nothing positive about the term “rock star” in when applied to people you work with?

I want to work with smart and accommodating individuals who are team players.

None of these qualities are what we expect of rock stars. When I hear “rock star” - I fear a cult of one.

[reillyse]

You are 100% correct, nobody wants to work with a "rock star" on a team. When I hear "rock star" I think diva. The best teams are made up of a group of competent people who get on with each other and do great work together - not a team where one or more people are god's gift and the others are subordinates. That kind of scenario doesn't last too long.

[hermitShell]

Very much agree, I first encountered the idea of an engineering team ‘diva’ or ‘prima donna’ on the zipcpu blog. The archetype immediately resonated with me because I could see it in myself and in others, especially the high potential, high talent people. Fortunately I work for a team full of high performers and I can learn a lot from them and get along just fine, because above all we are kind to one another. We also happen to kick ass and ship systems but it’s a lot more fun to do it with a team you can genuinely like working for. I am the team lead but all the important results come from ICs so I work for them, really.

[lazystar]

thats a management problem. if management treats someone like a rock star, the team takes notice and reacts accordingly.

[jbverschoor]

100% agree and is exhausting.

The stress is just not that apparent in environments where projects tend to fail anyway, or environments that provide lots of job stability.

You basically get paid for being present instead of actually produce something useful.

I don’t understand why one would want to work in such an environment, except when you’re soft-retiring / soft-quitting

[EGreg]

Oh man I wish I knew I was being paid to be present and available

In my last full time job I worked for a tech consulting company that rented us out to teams at financial instutions that managed insane amounts of money. This was in 2021 before AI was common. I worked remotely, and the first month didn’t do anything — just waited for the corporate laptop to arrive etc. Then I worked 2 hours a day.

But I had to put 8 hours in the timesheets, and select what projects I was working on. And I always had a feeling of guilt about that, like I was helping my consulting company charge hours that I wasn’t really working. I just kept finishing the tasks I was assigned in the sprints, and then there was nothing more to do. I didn’t aggressively ask for more work, just took on what others did. This went on for a while, and I felt guilty. Working on my startups in the meantime, like those people who work multiple jobs. I didn’t realize this happens a lot.

On one of my calls with my immediate manager I mentioned I had some downtime — and he was like “oh you have downtime? That’s not good.” And then it became his problem. And I didnt get more work but from then on I felt this tension with him, and probably others downstream of it. Nothing concrete, but just the feeling slightly changed, for a few weeks. So I nicely resigned after 6 months, saying to HR that investors funded my startups but they want me to work on them fulltime. So I left on good terms.

I regret it, though, in retrospect. Because of my ethics I missed out on income that could have helped my family and people around me. That was a great salary for remote work 2 hours a day, and I would have invested over half of it in crypto and probably 3xed it all by now. I only left because my ethics bothered me, but I learned later how often “full time” jobs really aren’t. Like, at all!

[jbverschoor]

Yep. I totally feel you. And then you see people just fill in 8hrs every day for the same stuff.

They don’t care about reality. They care about accountability. As long as the numbers are right, everybody’s happy. And if you’re out of budget. Hooray, one difficult meeting and everybody, the consulting agency, the champion inside, a few manager, get a nice increase in their budget and team size.

Unfortunately it’s not about the product, impact, quality, etc.. it’s just a game, and everybody’s just taking from the corporation/their customers (ultimately consumers).

[90s_dev]

Thomas More would be proud.

[BLKNSLVR]

Sometimes "bad at what they do" is a manifestation of the environment in which they're doing the thing as opposed to incompetence. If the environment is healthy and is understanding of the asking of "stupid questions", that promotes a better exploration of both the problem and the potential solutions, which act to help form the vision of the path to the solution.

This is much easier when the relationships within the work environment are "good".

I work with a bunch of different personality types and geniunely like almost all of them. It just takes time to work out each individuals quirks and work with / around them.

[motorest]

> The stress comes from people who are bad at what they do and are trying to make it someone else's problem.

There's some irony in the way you try to pin the blame on a third-party, and while trying to denigrate it too. I think it warrants some soul searching. I mean, would you feel stressed if you had to endure a team member who threw blanket accusations at your competence and in the process blamed you for causing grief to other team members?

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

There's a lot to unpack there. Only a highly disfuncional team would throw a team member to the wolves and leave them out to fend for themselves on a task that is relatively complex. No wonder people would feel stressed in that environment.

[baketnk]

you have no idea how luxury this belief is.

having been the guy fixing the third party's bugs at almost every position, i side with the parent.

[__loam]

This industry has basically no standards for what a software engineer should know and chronically underinvests in training people, then people will jump on hackernews and bitch about people not knowing what they're doing like they haven't been saying university is worthless for the past 7 years.

[motorest]

> you have no idea how luxury this belief is.

I know very well what working with non-10x engineers is.

I also know ver well that performance is a management and HR issue, not an engineering issue.

Your job as a competent engineer is to make your team work. Your responsibility is to help out fellow team members whenever they need to be unblocked, and create a healthy, accepting, tolerant work environment. Your job is to be trustable, not make others hate their job, and not be the toxic asshole who makes everyone miserable and drives others away from your team. Because otherwise it is you who create high-stress work environments, and burn out people.

[tempaccount420]

Their belief just screams "DEI"

[motorest]

> Their belief just screams "DEI"

Complaining about "DEI" is a cope mechanism of incompetent individuals, who prefer to fabricate conspiracies to justify why someone else was chosen over them. It's a rehash of the old argument of complaining about low-pay immigrants for stealing jobs that would otherwise be rightfully theirs.

[tempaccount420]

Ah so I was right ;)

[pugworthy]

> They don't have vision for how they will accomplish what is asked of them.

Or they don't have the vision to know how others will accomplish what they are asking for.

This is a big struggle for me; people who want to play product owner, and make requests that are very ignorant of work required. Or think they know just what work is required and spell out development approaches despite not having any background or experience in software development.

They key really is getting to know what it is they really want to do and then deliver a solution. Which can be its own exercise in frustration.

[mnky9800n]

I think it’s also possible to build relationships with people based on potential. Not every superstar was born that way. Most of them had help along the way.

[videogreg93]

Not being a rock star but showing potential is great. But there are some people who are allegedly always busy, in over their head, etc. And these are the type of people I agree that should be avoided. I've found that more often than not these people are always wasting time in meetings, chatting it up, only to complain about lack of time 1 hour later.

I'm not saying don't socialize and just work ; you just need to balance the two.

[bravetraveler]

Folks might be surprised at how many of us would like to leave well enough alone. Crabs, bucket

[bubbleRefuge]

a tech mentor once told me what makes a developer great is not how good or talented he is but how good he makes those around him be.

[fads_go]

> And the other is about keeping a polite distance to prevent repeated interactions.

or, the other is about providing them the vision and the clear set of steps. Then checking their progress along those steps. (including revising the steps when the original plan diverges from the evolving reality).

Training and mentoring the people so they can become rock stars.

[alphazard]

This comment and a sibling both brought up the issue of less experienced people and mentorship, which is important to clarify.

Some incompetence is a known quantity, and when it is known it will not produce stress. The junior dev on the team might not know how to do something. The team leadership should already have priced that in, and have a plan to help them if need be. If the junior dev's incompetence is creating stress, the root cause is leadership incompetence.

The kind of incompetence that produces stress is incompetence that is too impolite to mention. It can't be addressed through "mentorship" or "working together" because that would call the legitimacy of the role and the person filling it into question. Engineering managers who don't understand engineering, product managers who don't understand the product, etc. The list is long, and examples are common. The organization is built around the assumption that these people can do things that they are unable to do. That mismatch is the origin of stress.

Investing time in the 1st kind of incompetence is a good investment because you will get a good return on your time invested. The junior dev with potential becomes the rock star. The 2nd kind of incompetence is often "Throwing good money after bad". These situations are not worth your time. There is unlikely to be an improvement, and you risk it backfiring especially if the problem is above you in the org chart.

[n4kana]

You nailed it. I worked in a high-expectation consultancy for 15 years, and the biggest stress didn’t come from junior people being green. It came from leadership avoiding hard decisions.

One team member had a TBI. My manager gave him a custom track so he could succeed. That sounds kind, but it meant the rest of us had to constantly check in, fix problems, and slow down for him.

Another person had lots of field experience but couldn’t handle problems without getting emotional. He built walls around every challenge and pulled people into his frustrations. He had the title of senior consultant, but he couldn’t do the work without a junior staffer helping him every step.

Then there was a junior person who had already underperformed in another team. Instead of addressing it, leadership moved her to my team, where she had even less experience. If I gave her 10 basic tasks, she would typically only complete 7. Not challenging tasks, just needed follow-through. My boss told me to keep setting clear expectations and checking in more. But she just kept pulling time and attention away from the actual work.

She was also split 50/50 between her old team and my team. I kept telling my boss and the other SVP that this made no sense. If someone is underperforming, the worst thing you can do is give them two sets of responsibilities. There’s no way to hold them accountable. Any time she didn’t deliver, we’d say, “Well, maybe it’s because of her other team.”

And here’s what really got me. My boss admitted he wanted these people off the team while enabling them. I ultimately pushed the field guy to deliver actual work until he quit. I kept pushing for the junior staffer to be placed on one team that could pin down her underperformance until the other team took her back. Leadership talked about fixing things, but they wouldn’t act. And it put me in a role that I wasn’t supposed to fill, applying pressure on my teammates rather than support.

This is an organizational deficiency with promoting engineers to manager roles as a matter of course. My boss was a fine engineer, but he was a horrible manager and no one held him accountable for his bullshit. I saw people go around him to complain to his superiors, but it wasn’t well received or productive.

Shame on the organization.

[toast0]

In my experience there's several types of work stress in software.

One is people / process stress; related to the steps needed to get work done, including approvals and negotiations to decide what to do.

Another is operational stress; related to keeping a service running; some of that can be people or process stress, but if your service is growing rapidly it might just be organic operational stress.

There's also the stress of getting the work done in a reasonable time.

Some people are better at managing the different kinds of stress.

Anyway, I think the moral of the post is when you rage quit, say "fuck this shit, I quit" rather than "fuck you all, I quit" ... keep the rage pointed at the system rather than the people :P Unless it's just like one person who is really intent on making your job hell. You might be able to get away with singling out one person, rather than doing the Oprah thing and "everybody look under your chair, you get a fuck you" :P

[geijoenr]

I think this is almost spot on.

There is also people with just toxic personalities that everybody tries to avoid. In Europe unfortunately, is not easy to get rid of such characters and they often victimize teams and jeopardize entire projects.

Septic avoidance and minimizing interactions, sticking to process and keeping the distance are absolutely necessary for mental health.

[j45]

Software that is for a customer or end user is not about the builder alone, or primarily.

Software is for people (end users/customers) to use, and is made to work for people.

Learning the people side of building, and delivering, and helping people with it is key.

Of course, some people in any office environment will play work in pursuit of achieving a daycare or high school for adults.

[jajko]

Well, while certainly true, this is max few % of stressful reality. In fact, basically none of the workstress in my past 15 years was caused by this.

I had this mindset when much, much more junior but these times... not so much. Maybe in purely startup small shop env, but thats not where most of us get work done.

[PaulRobinson]

Not all relationships are equal, so don't just prioritize relationships, but those that are valuable.

You can't ignore people who bad at what they do and are trying to make it someone else's problem, but you can find allies who are good at what they do and want to take some pride and ownership in the same things you do.

If someone doesn't have a vision for how they will accomplish what is asked of them, that's an opportunity for mentorship. They might not take it from you, but you can offer it.

I actually think the really dangerous people are the ones you encourage people to seek out: those who think everything is easy. That to me is a sign of Dunning-Kruger. I'd rather sit down with somebody who says "I don't know yet how to solve this, but we'll work it out", than somebody who says "it's easy we don't need to think too hard about this" or "it's hard and so I won't even try".

Also, meetings, shared responsibilities - they're part of getting stuff done as part of a team. Instead of trying to avoid them, try to improve them. Learn the people skills needed to help a person change their habits towards being the productive ally that adds to a team rather than takes away from it.

It's not easy, it's hard, but you will figure it out. If I was working with you, I'd say "we", not "you" but alas...

[bumby]

>If someone doesn't have a vision for how they will accomplish what is asked of them, that's an opportunity for mentorship.

I agree with your overall sentiment, but there’s another dynamic which doesn’t always lend itself well to a mentorship role: when the leader has no vision other than some vague concept. Sometimes we can politely corral them, but it’s extremely frustrating when that “vision” is predicated on some magic, black box operation that they think happens and they won’t listen to any technical advice on why their vision may not be feasible.

To the OPs point, we have limited resources in time, labor, patience, etc. It’s worth consciously deciding where those are best spent.

[disambiguation]

This seems like a very specific perspective, I take it you're the "Live to Work" kind of person?

[tacitusarc]

I think this characterization implies a dichotomy that bothers me.

Work is certainly not my top priority, but I spend a ton of my time on my job, and I would like to feel fulfilled and happy doing it. Have capable colleagues that you can trust to pull their weight is a big part of that.

In general, I’ve found that the clock-in, clock-out types seem to take their mediocrity as almost a badge of honor, with this feeling that by not working hard or accomplishing a lot, they ensure the business is not getting overmuch value out of them.

This is so sad, IMO. If at all possible, work should be fun. As programmers, we have more opportunity for that than most, and should take advantage. Is that perspective “Live to Work”?

[disambiguation]

The person I replied to claims their work based social interactions are totally utilitarian and transactional - very Patrick Bateman. Should work be fun? Of course, in fact every part of life should be good and fun for everyone all the time, yes? But realistically, I wouldn't have any fun working with this guy. If other peoples "mediocrity" is spoiling the "fun" for you, then you should consider building your own fun zone - no boring, mediocre people allowed.

[tacitusarc]

The quotations feel unnecessarily petty. Do you enjoy working with people who are incompetent? Is there anywhere you’d draw the line with regards to competence, at which point you’d rather not have to deal with them?

[disambiguation]

Apologies for coming across as heated and getting carried away - my intent was not to convey pettiness, but rather highlight how those notions are highly subjective. Everyone has their own idea of what's fun and what's competent.

In the context of the original reply, I dislike it when colleagues are so ideologically intense and rigid about work because it puts me on the defensive; I have to impress them on whatever made up criteria they have. Maybe they think they're being right and fair, but I didn't ask to be judged, and more often than not their attitude is really just an ego trip - picking on the flaws of others rather than self reflecting. It's easiest to deal with these types by flattering their egos and staying out of their way; they'll eventually "fly to close to the sun."

In terms of working with incompetent people, I don't view it as binary, or even linear. When referring to incompetence what's usually meant is someone who is unmotivated or unknowledgable, but they don't take personal responsibility for helping them and investing in the team as a whole. I have never felt at the mercy of an incompetent colleague, there is always a path forward. Any perceived hindrance or drag is just that: perspective. And as a dev, it's just not my problem. It's up to management to decide what's an acceptable level of productivity and drag. That said, while I don't think I'm seen as incompetent, I'm not a rock star either or work on a rock star team. I can see this being more pertienent to someone in that kind of environment. For myself, I subscribe to the David Graeber philosophy, that a lot of our industry is "bullshit" jobs. It's hard to care about competence when the work doesn't really matter in the first place. Regardless, the word incompetent just isn't part of my vocabulary, it only facilitates complaining and doesn't serve a productive purpose.

[mushroomba]

I would say that you are in a unique place of privilege in that regard. I believe the common experience of many people is that any task, if it be work, cannot be pleasing. The requirement to continue to complete any task in exchange for the necessities of life induces a disparity of spirit that will dull even the most hedonic of activities. The snuffing out of the freedom to choose to do the task is what induces pain into the experience.

For my part, I choose to have a good attitude about work. I am grateful for the opportunity to work. I do the best I can so that I can be proud of how I have spent my life. But I would never expect any job or any work to provide me fulfillment or happiness.

[taurath]

I think your statements belie a sense of honor in both trying to find enjoyment and in developing master with what you do. But I also don't think the underlying dichotomy is the how the GP phrased their characterization of others as "bad" and "making it someone elses problem".

That implies not only a value judgement dichotomy but also an added heap of shame of the morality on those on the wrong side of that value judgement.

Those are not the same things as being okay doing the work you're paid for and not reaching higher - people who do that may have a much better sense of the business value they are providing, and may be trying to avoid an experience of being exploited, or prioritizing their health and well being for the long term rather than the short term needs of the organization that pays them. There's often not a good way to know who is who.

Most of the time when enticed with a reward, people will work harder. When they aren't enticed enough, they tend not to, and that level is different for everyone. Companies seek those who have internal reward structures so they don't have to offer very much to entice people.

[tacitusarc]

I think there is a nuanced but discernible difference between people who are talented and time constrained, and those who are mediocre/lazy/disinterested.

I used to think the incentive structure was a dominant factor, but my opinion on that has shifted over the past ten years. I think companies need to incentivize capable employees to stay, because they will often have many other opportunities elsewhere. But in most cases I don’t think those incentives cause people to work harder or more effectively than they would otherwise.

[throw4847285]

I've worked with many people like you, and I can say from experience that they are never as competent as they think they are. Often they are quite competent, and yet somehow they still overestimate their own skills and make life harder for everybody.

The type of person in question can be understood as somebody who equates technical skill with "not needing help." It's implicit in your post. Your mythical rock stars are extremely talented individuals, while what sets the incompetent apart is apparently their need for assurance from others.

[alphazard]

The most competent software engineers (which I referred to as rock stars) don't know how to do everything. It can appear that way to someone unfamiliar with software. The best have a keen self-awareness of their abilities. They understand how much time it would take them to figure something out, and their likely success rate. When they give good estimates and have accurate confidence in their abilities, they create predictability for others around them. That makes them a net sink for stress.

Professional competence is literally the set of the things you can do without needing help. That doesn't mean you never ask for help. It just means there is an expectation that you can accomplish some things on your own. If you need help with everything forever, then you are fundamentally not useful and not coachable (which is worse). When needing help is anticipated and transient, that's a non-event. When your job is mostly things that you are expected to do yourself, but you need help with all of them, that creates stress for your peers and subordinates.

[jollyllama]

Indeed. Completely absent from the calculus are those who are glaringly ignorant as to their lack of knowledge or skill yet nevertheless supremely confident, and unchecked, will happily blaze a trail of carnage as far as they can travel.

[lionkor]

It's a fine line, between blind, numbing incompetence and blind, bulldozing skill, and it's probably best to make sure youre never too close to either.

[sh34r]

I couldn't disagree more. I try to avoid people like you like the plague. You're never as good as you think you are, and any additional skill you might provide is negated by how much you drag the rest of the team down.

I'm happy to provide leadership to help those who are less capable, but willing to learn, and are actually nice people.

[StopDisinfo910]

> The stress comes from people who are bad at what they do and are trying to make it someone else's problem.

People who are currently bad what they do have their own work struggle, go home to their issue, have their hobbies and ambitions.

I think the article strikes a very good point when it says you don't want to be remembered as that guy but I would go even further in that it's not only about your reputation. When you are that guy, you are actually making everybody life slightly worse including your own.

I think there is more value in acting and being remembered as someone who can lift up rather than as someone who is distant and self-interested. It's not that you should always be mindlessly helpful but you can be assertive, give honest feedback, help people realise when they should take responsibility and define directions without being a pushover or exploited. In my experience, that's how you make people actually want to work with you. These are obviously hard skills to develop (at least they were and still are to me) but they are how so valuable.

To go back to your conclusion, for me it's more about "How do I convince the people I want to work with to work with me?" than about cutting people. After all, you will probably be the sole constant in all the work environments you will be a part of in your life so you are the biggest factor into making them work for you.