9 ms·
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 cam
by alphazard 1y ago
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?
- PaulRobinson 1y agoNot 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 1y ago>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.
- j45 1y agoSoftware 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.
- mnky9800n 1y agoI 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.
- bravetraveler 1y agoFolks might be surprised at how many of us would like to leave well enough alone. Crabs, bucket
- videogreg93 1y agoNot 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.
- fads_go 1y ago> 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.
- deleted 1y ago[deleted]
- alphazard 1y agoThis 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 1y agoYou 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.
- barbazoo 1y ago> 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 1y agoWell 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.
- bubbleRefuge 1y agoa 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.
- motorest 1y ago> 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 1y agoyou 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.
- seivan 1y ago[dead]
- __loam 1y agoThis 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 1y ago> 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.
- StopDisinfo910 1y ago> 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.
- toast0 1y agoIn 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
- disambiguation 1y agoThis seems like a very specific perspective, I take it you're the "Live to Work" kind of person?
- tacitusarc 1y agoI 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”?
- mushroomba 1y agoI 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.
- disambiguation 1y agoThe 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.
- jbverschoor 1y ago100% 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 1y agoOh 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!
- 90s_dev 1y agoThomas More would be proud.
- throw4847285 1y agoI'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.
- lionkor 1y agoIt'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.
- jollyllama 1y agoIndeed. 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.
- alphazard 1y agoThe 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.
- deleted 1y ago[deleted]
- vladgur 1y agoAm 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.
- lazystar 1y agothats a management problem. if management treats someone like a rock star, the team takes notice and reacts accordingly.
- reillyse 1y agoYou 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 1y agoVery 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.
- geijoenr 1y agoI 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.
- pugworthy 1y ago> 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.
- BLKNSLVR 1y agoSometimes "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.
- deleted 1y ago[deleted]
- jajko 1y agoWell, 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.
- sh34r 1y agoI 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.