15 ms·
A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc
by d--b 4y ago
A lot of toxic negativity in that post.
Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk.
https://www.inc.com/jessica-stillman/studies-being-a-jerk-is-contagious.html https://www.inc.com/jessica-stillman/studies-being-a-jerk-is...
Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.
- infamouscow 4y agoStupidity is a moral failure. Derision of the stupid is morally justified: https://www.youtube.com/watch?v=ww47bR86wSc https://www.youtube.com/watch?v=ww47bR86wSc The study you linked assumes the actors are not stupid.
- surprisetalk 4y agoAuthor here. I don't want to empower jerks. Anything particular I should change? Or is the structure of the essay too cynical overall?
- s-j 4y agoThe article is good at making a point of what is bad and for the fun of it. However, it is not successful at compassionately explaining what one should strive to instead as there is no simple negation of the points being made.
- jerf 4y agoIt is not the responsibility of a person pointing out problems to also solve them. Granted, pointing out problems is generally much easier than solving them, and correspondingly less valuable. As I like to say, stand up, spin around, and point at something randomly. You're pointing at a problem of some sort. But that still does not incur a responsibility to someone pointing out a problem to also solve it. It's a popular idea for some reason but not one that can stand up to scrutiny of any kind.
- camjohnson26 4y agoNo but it is their job to understand it, otherwise you’re not contributing anything valuable, you’re stirring up drama. If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in the first place. The problem with the article is even though it’s right it makes no attempt to explain why, and blames bad people for the problems instead of understanding why they might be acting like they are.
- jerf 4y ago"No but it is their job to understand it," No, it isn't their job to understand the problem before pointing it out either. That also does not stand up to scrutiny in the slightest. If I call my township to report a big pothole, I am not required to submit an explanation of how the pothole came to be. This is a ludicrous standard only deployed when situationally convenient for someone, not an actual principle. Again, the value of a problem report without an understanding may be less than one that has it, but there is no obligation to have an understanding or present one in order to talk about a problem at all.
- watwut 4y ago>No but it is their job to understand it, otherwise you’re not contributing anything valuable, you’re stirring up drama Frankly, this sounds exactly like toxic management where people are not allowed to raise issues which then blames everybody but themselves for consequential infectivity. > If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in the first place. I I point to a light switch and say that it does not work, I do not need to be able to fix it by myself. For that matter, it is good example, because we are not even allowed to fix electric devices by ourself (workplace safety).
- camjohnson26 4y agoTaking the bare minimum of time to understand a problem before complaining about it isn’t toxic, it’s human decency that respects other people’s time. If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs. I don’t think you’re saying that you couldn’t explain why the light not working is a problem. No one said you have to know how to fix it.
- censor_me 4y ago[dead]
- EGreg 4y agoNothing. Your essay exists solely to be criticized, and honestly you’re on a bad / useless path and should get out now and completely rethink your life. We are HN. We are legion. Expect us. When I got on the site, btw, I immediately saw your choice of font and I didn’t actually read your essay. PS: This is satire (https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law)
- luxuryballs 4y agodon’t let the -10Xers get you down it’s a delightfully funny and insightful piece
- efitz 4y agoSoftware needs to be used by users. It’s unlikely your developers are so innately talented that everything a user wants to do is obvious and intuitive. So docs, etc matter. Other teams like marketing need to make schedules because they spend huge amounts of money doing things to make your product successful, that have nothing to do with code. For example, launch events, advertising, conferences, executive briefings for key customers, etc. Planning, dates, progress reports, etc are all needed because unless you are a lone open source developer, you have to work with others. Users will use your software in unexpected ways. Hackers will try to break it. And users will expect it to work flawlessly when they need to use it to generate their report for their VP meeting in 5 minutes. Testing is critical to ensuring that your software doesn’t suck for your users and make them hate you. The business you work for probably doesn’t exist with the mission to leave you alone and let you code. They want to solve a customer problem by creating, marketing, selling and/or supporting a software product. Your management wants to know that all the money they are spending on your salaries is getting them a positive ROI. Letting them know what you’re doing and providing them with content about capabilities and features that can be used in marketing, makes them want to keep paying you. Missing deadlines, failing to deliver non-code deliverables, failing to provide status, and being jerks in general make management want to cut your project (and maybe your job) and do something else with cooperative people. Yes, there are pathological extremes to all of these things and to the points you raised in your post, but I see too many developers who think that developing software is just about coding and that everything else is extraneous. In reality, the vast majority of your time is probably best spent NOT coding. [ed] spelling, paragraph break
- secfirstmd 4y agoWell said. I work on engineering stuff but I spend a huge amount of time encouraging people to understand the other parts of the business and their needs.
- photochemsyn 4y ago> "They want to solve a customer problem by creating, marketing, selling and/or supporting a software product. Your management wants to know that all the money they are spending on your salaries is getting them a positive ROI." This is all true for the somewhat narrow field of commercial software development for the consumer end-user where profit margins determine success or failure in terms of paying off the capital investors, but many organized engineering efforts have other goals, e.g. replacing some organization's decrepit internal data storage, archiving and retrieval system where robustness matters more than anything else, or designing a research program aimed at solving a complex technological problem, writing software that controls an electrical grid, and so on. Applying the maximize-short-term-profit mentality to such problems generally doesn't end well.
- CropCircleSys 4y agoNo. I enjoyed the article and your sense of humor. Kudos
- Clubber 4y agoI've been writing software for 20+ years. I think that article is pretty funny and on the nose. I'm currently in the midst of fixing an issue we just discovered added by a -1x engineer 17 months ago. He's the gift that keeps on giving. If you're offended, this article is probably for you.
- robertlagrant 4y agoHuh, that's cool. I would say: - if you can't define "jerk" well, you're playing into office politics. Who decides who the jerk is? - there's a typo: "A blog post by the studies authors" should be "A blog post by the study's authors" - the "studies" linked to seem fairly dubious. Most people who are rude are not so because their boss is. Only 25% said they were. Also, it's qualitative survey data, which it's rarely a good idea to draw anything but first order conclusions from (e.g. yes Donald Trump won the 2016 election, so we can conclude that he got the most votes, but we can't infer from that that voters like candidates with orange skin). And as self-reported data, it's hard to base much on it at all. - the implication is that removing all this would be the best thing, and that's probably true: having some wonderfully polite geniuses is no doubt the best option. However that doesn't mean we should necessarily prioritise politeness over raw ability, as at least for some tasks, a solitary person who's very smart can do things that even teams of others can do.
- d--b 4y agoIt's brutal. You want to sound like an Office Space character. But in Office Space, there is no mission, there is no good engineering to do. So all the douche-y people who get in the way of work are more pityful than enemies. But here, you believe in good engineering yourself, and the -10x engineer you encounter get under your skin. So you're venting online about why you hate their guts (in a funny way, for sure, but still the aggressivity transpires) It's understandable. I met many bad engineers. They're a nightmare to work with. And yes, many will have a net negative impact on overall productivity. Still, coining the term -10x engineer and making an aggressive piece about all the ways they can screw your work life is not exactly healthy. Yes, I think your post is going to be empowering jerks. What did you think? That this was just a "funny, haha" post? There are many people who are angered by bad engineers in their daily lives. This is just adding fuel to their anger. This is the Jerk effect taking place. This article reads like a jerk venting, and that language will spread to frustrated people. You can already see it in the comments here.
- d23 4y agoThere's a lot of projection going on here, as far as I can tell. The author is about as neutral as possible in describing these traits / behaviors. None of these traits are mutually exclusive with being a jerk, and in my experience, more often than not the people that exhibit these traits tend to also be jerks to compensate for their inability to get high quality work done!
- d--b 4y agoIf you can't see the negative bias in calling anyone a "-10x engineer", I just can't discuss the matter with you...
- d23 4y agoIf it were directed at a particular person, sure. Otherwise, the author is describing negative traits and behaviors. Have you ever taken any management training? This is the quintessential way of discussing these sorts of things neutrally. Yes, you'd never want to call an individual a -10x engineer, but this is a random article on the internet. It's okay to be a bit headline-attention-grabby and stylistic so the article isn't dry and corporate.
- goodpoint 4y agoI'm surprised you don't stress more on the habit of always picking the popular google-scale tools even for in smaller companies. Or the language or framework of the month lol.
- d23 4y agoIt's fine. It's clear the purpose is to list a bunch of traits and observations you've made over the years. It's concise. Trying to fluff it up would only make it less readable.
- celdon25 4y agoNo changes needed, it grabbed my attention and stood out. You clearly know what you are talking about. But assuming your goal is to make a positive impact in the industry, managers need to be able to read this and get actionable takeaways. You’ve got my attention as an engineer, but a follow up post for each of these examples would be the place to close the deal. They of course would have to be written with a different (and dare I say more constructive) slant. It needs to be something someone can take to a manager and get a chance of some good conversations. It can still be persuasive, but in order to be actionable I would expect specific examples, clear definitions of the issue, and recommendations that tend to be familiar or standard. I would do plenty of research too. Because for one thing you need to ensure you are giving correct advice. But it will provide a massive boost to your credibility to include that research in the posts. It will also save your reader the trouble of doing independent research (which they likely would not have done in the first place but still require it for actionable change, or the idea gets shelved). -10x engineers can leave managers no time to do that kind of diligence, but the managers still know better than to blindly trust what someone says on the Internet. Back up your arguments with evidence where possible. I know it’s a tall order but if you have the time to put that much quality into a series from this, it could be great. I only say this because from what I can see, you do know what you are talking about, and clearly have passion about this. I look forward to reading anything you do come up with, whatever the approach :)
- justin_oaks 4y agoThe only thing you should change is your expectations. No matter what is written, someone will find something wrong with it. Expect those people to show up and sometimes be very loud. I appreciate your efforts to receive feedback. In this case, you'll find the majority of people aren't complaining, just a few are. So be happy that you wrote something that so many engage with! The only thing worse than writing something that people are critical of is writing something that's completely ignored.
- nyob 4y agoI think it's great and on point. No need to change anything.
- __MatrixMan__ 4y agoI don't think it's too cynical overall. I can't recall the quote verbatim, but somewhere in "The Glass Bead Game" a great teacher says that it's difficult to work with intelligence--you have to be lucky to identify it and then the best you can do is get out of its way. Stupidity, on the other hand is easy to identify and easy to correct on a case-by-case basis. There's value in inverting a problem like you've done in the article. It might not be symmetrical. Things that might not have been obvious in the original become obvious in the inversion.
- itronitron 4y agoYou could have really shortened your list by just starting off with 'Use JIRA' Also, the thing about wasting 10 weeks of wages on cloud computing was confusing because it mentioned buying exotic hardware and in my experience the options via cloud computing are never exotic, and never have a decent amount of RAM.
- deleted 4y ago[deleted]
- BoneZone 4y agoI disagree. For me this outlines the caveats and pitfalls of software development and management. There is real truth to some of the authors points showing real paths that emerge naturally. If you're going to gaslight him by inferring anyone who is critical is an asshole, maybe you should ask yourself why you're taking the article so personally...
- lifeisstillgood 4y agoWell put.
- camjohnson26 4y agoI agree with most of the author’s points, but the post is overly negative in my opinion. It’s blaming other people for the problems instead of digging into why these problems come up in the first place. Why do managers waste time with busywork? They need insight into the process. If you look to criticize without understanding you’ll always find plenty of material to blog about, but you’ll just create new problems and never fix anything. The author probably thinks these issues are caused by bad people instead of bad processes, which is why he doesn’t suggest realistic fixes.
- surprisetalk 4y ago> The author probably thinks these issues are caused by bad people instead of bad processes Author here. This is an excellent way to phrase a subtle point that I couldn't figure out how to fit in the piece. I think that -10x engineering is not someone you are, but something you do. And even more commonly, it's something that organizations do for periods of time.
- shultays 4y agoThe contagious jerks are often results of working with -10x engineers. At some point you become as such, if you don't quit the company before that. There are "bad engineers" and then there are -10x engineers, it is a real problem if the company keeps such engineers You should try working with -10x engineers and see how your feedback is being ignored as tech debts are piling up, products are continue to under deliver and missing deadlines.
- celdon25 4y agoThis hits close to home, but unfortunately Occam’s Razor will get applied. It’s an unfortunate reality that engineers (not their managers) are responsible for knowing how to handle themselves in the worst of situations so they don’t become the scapegoat at the cost of their health and security. Trust me, I’ve been through this situation and have been burned out by the [apparent] low standards and [apparent] double standards. The prodigal charismatic leader can save the day but become a crutch too much relied on. And I get it, with all the shit we deal with in life, things ought to work out that way. But eventually that leader won’t be there for you (or even in the picture at all) and you’ll be in big trouble, especially if you spent many years relying on them for help. Working remote for a high pressure early stage startup is a good recipe for this kind disaster if you aren’t great at managing stress or conflicts at work.
- throwawaythekey 4y agoI'm going through this at the moment at a startup... I thought I could count on the charismatic leader to save my bacon by only calling on them for help when when things are visibly on fire and my own minor charisma hasn't been enough. In the end the leader didn't show up and now I've got a HR complaint against me for following up consistently when the fire didn't get put out. The whole thing has been fairly stressful because I'm struggling to understand the particular social dynamics, my best guess is it's just power protecting power, but I am naive/delusional enough to want to believe there is more to it. Now I'm taking a month off from work to try and unwind a bit. All of that was just a long way of saying that you never know when you'll need to call on your stress/conflict managing skills, so best to keep them sharp at all times. I thought my skills were already good, but that was quickly revealed as false when challenged by tougher opponents :).
- naillo 4y agoStep 11: Call out any attempt to make engineering more productive as toxic negativity.
- ilyt 4y agoStep 12: have a meeting about it Step 13: have a blogpost about how inclusive and equitable your company is.
- vxNsr 4y agoStep 14: Hire an entire team who’s only job is increase office drama and reduce colleagues trust
- ilyt 4y agoStep 15: Make absolutely sure your team and any prospective hire knows you will hire to fill quota vs get them the most competent co-workers, ensuring mediocrity.
- psychoslave 4y agoStep 16 skip step 16. step 17 Recognize that questioning the status quo is a critical part of progress and growth, and that "toxic negativity" is often a label applied to dissenting voices to silence them. step 18 Acknowledge that engineering, like any other field, can benefit from improvements in productivity and efficiency. step 19 However, also acknowledge that a singular focus on productivity can lead to shortcuts, neglect of quality, and burnout among engineers. step 20 Question any proposal that seeks to boost productivity without considering its potential drawbacks or unintended consequences. step 21 Encourage open and honest discussions about the tradeoffs involved in increasing productivity, and welcome feedback and criticism. step 22 Remember that criticism is not the same as negativity, and that constructive criticism can help identify problems and find solutions. step 23 Avoid dismissing criticism as "toxic negativity" or labeling critics as "problematic" without engaging with their ideas. step 24 Recognize that diverse perspectives and voices are essential to a healthy engineering culture, and that dissenting opinions can lead to innovation and progress. step 25 Cultivate a culture of respect and openness, where all voices are heard and valued, and where criticism is welcomed as an opportunity to improve. step 26 Challenge assumptions about what constitutes "productivity" and explore alternative approaches that prioritize quality, sustainability, and employee well-being. step 27 Remember that engineering is a human endeavor, and that the well-being of engineers and the communities they serve should be a top priority. step 28 Take a shortcut and jump directly to step 42 for your surprise. step 29 Recognize that productivity gains should not come at the expense of ethical considerations or compromises in safety standards. step 30 Encourage ongoing learning and professional development among engineers, so that they can remain up-to-date with the latest technologies and practices. step 31 Ensure that engineers have access to the resources and tools they need to be productive, without sacrificing their mental or physical health. step 32 Celebrate successes and learn from failures, without casting blame or assigning fault. step 33 Remember that productivity is just one aspect of a successful engineering organization, and that teamwork, collaboration, and communication are equally important. step 34 Foster a culture of trust, where engineers feel empowered to speak up and share their concerns without fear of retribution. step 35 Recognize that engineering productivity can be influenced by external factors, such as economic conditions or resource constraints, and that some challenges may be beyond an individual's control. step 36 Encourage interdisciplinary collaboration and cross-functional teams, to break down silos and encourage a diversity of ideas and approaches. step 37 Always be open to feedback and criticism, and recognize that even the most successful organizations can benefit from continuous improvement. step 38 Emphasize the importance of work-life balance, and support policies that allow engineers to take breaks, recharge, and avoid burnout. step 39 Encourage knowledge sharing and collaboration across teams and departments, to foster a culture of continuous learning and improvement. step 40 Seek to understand the root causes of any resistance to productivity improvement, and engage in constructive dialogue to address those concerns. step 41 Consider the long-term consequences of any productivity-enhancing measures, and make decisions that promote sustainable growth and development. step 42 Realize that in this message only steps 16, 28 and this one where not generated by ChatGPT.
- goodpoint 4y agoPeople here are irked because HN is the home of CV-driven development. EDIT: ...as proven by the rain of downvotes...
- coldtea 4y ago>A lot of toxic negativity in that post. Yeah, or as it's scientifically called: "realism"
- ilyt 4y agoIt's not 0/1 problem. Obviously being asshole for no reason is bad. But bending over backwards for bad solutions just coz you "don't want to rock the boat" or "don't want to argue" leads to mediocre product driven by whoever happens to be least polite in the team. Tiny bit off stubborness and assholery on stuff you know is right (as in when nobody can provide actual sensible arguments for other way) can be very helpful. Also I did worked with "toxic but brilliant" ones and honestly I vastly prefer it over nice useless people. Toxicity can be managed, uselessness can not.
- tasubotadas 4y agoDid you find yourself on that list? Because besides this explanation, there is 0 toxicity.
- rvba 4y agoLet me guess, everyone who criticizes you is a jerk?
- d23 4y agoWhy do you believe the traits and behaviors outlined in the article are mutually exclusive with being a jerk? In my experience, most of the toxic people I've worked with were toxic because they exhibited a number of these traits and were thus ineffective and using toxicity to compensate.
- peoplefromibiza 4y agothe "contagious jerk" is simply the result of a bad environment the first one to denounce it encourages other colleagues to speak up, like it happened with the metoo movement. http://www.quickmeme.com/img/13/13d4f6f146baa91dbc0946651ca063107bf5c72d66d58b33ea6bc1496d44868e.jpg http://www.quickmeme.com/img/13/13d4f6f146baa91dbc0946651ca0...
- technofiend 4y agoI worked with one person who weaponized pedantry. He thought he was educating everyone by being a complete stickler for his specialized vocabulary and would never just answer a bloody question, wasting everyone's time. He thought he was Socrates but he was the hemlock. Similar to a good project manager he was like a chain-saw: very effective, but you always want the tool pointed away from you. It also meant you really thought about whether you could get what you needed done with any other tool rather than pull out the chainsaw. Ultimately this kind of behavior is a productivity sink; forcing everyone into your rules because it'll be so much better when everyone just complies with how you need the world to be means getting worked around and giving the pedant's work to someone more pleasant to work with. Please note: I'm not dinging people who sincerely need structure to help them function. This was a conscious choice just to be a jerk because in that person's opinion everything would be great as soon as we all thought exactly like he did.
- time0ut 4y agoI read the post, saw this comment, then re-read it again. I did not get the impression that author was trying to be negative. I think they were just trying to write in an "edgy" style. I've seen most of the things on the list happen (at least to a degree). On the topic of contagious jerks, my experience has been that these people often suck at engineering. For example, a few years ago, one of the product managers was super excited to recruit an engineer they had worked with before. The engineer was talked up. A real genius. Someone who would come in and do things right. He would lead a new sibling team working on a new product. I was excited. We could use the help as we were going through hyper-growth. The engineer seemed smart, but had a very sarcastic and negative attitude. The existing architecture was garbage. Everyone's code was terrible. Even the choice of language was wrong. While he was respectful towards me and the work I had done, I saw him put down most of the people around him. I kept my distance and let him do his thing. It wasn't my place in the organization to interfere anyway. The end result was he drove half his team to quit, delivered an absolute disaster of a system, and then left. I've seen versions of this play out a few times. My experience has been that the smartest people are often the nicest because they are smart enough to recognize the value in lifting everyone. I know its not always the case and I have worked with difficult people who genuinely were incredible engineers as well, but they tend not to actively put everyone around them down.
- CM30 4y agoWhat's more, the contagiousness aspect isn't the only issue here. Jerks tend to cause problems for organisations for other reasons too. Such as: 1. They scare away a lot of competent workers, since many smart and talented employees won't want to be stuck working alongside an asshole, regardless of how 'talented' they might be. And given that the best employees tend to have a plethora of options for where to work, and well... you can guess how that affects the talent remaining. 2. They discourage newer and less experienced employees from learning/improving, and instead encourage them to leave. But folks who aren't necessarily the most talented developers now can very much turn into such with the right environment and incentives, which these types of people don't provide. There really aren't any benefits to keeping around jerks, and a whole lot more downsides than people think.
- SilverBirch 4y agoI find it's context dependent. Sometimes everyone is working hard and doing their best and someone's being a toxic jerk. Sometimes things are going badly wrong and you need someone to actually stand up and say "Hey, how come these requirements keep changing we've wasted months doing something that was totally useless" or "Hey, how come our AWS bill is $100,000, and hang on a second, why isn't anyone monitoring our AWS bill?" or "Hey, the core premise of this project turns out not to be true, maybe we should really re-evalaute rather than ploughing on". Sometimes requirements are unclear and you just have to learn as you go. Sometimes the AWS bill is the last of your porblems. Sometimes you find out something you had assumed at the outset is wrong, but you still believe in the project. It's context dependent. Also, it's often more difficult to be the person asking the hard questions than the person who just goes along with things.
- brodouevencode 4y agoI get the sense that this is an investor/bankroller that fancies themselves as an engineer, or a manager that has done a terrible job of hiring so far.