Software 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.
> "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.
Well 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.
No 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 :)
I'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.
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.
There'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!
If 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.
You know what. I do agree with most points in the article. And I do find them funny.
Yet, I also met an awful lot of terrific engineers who were brutally aggressive towards anything they felt was stupid. And in my opinion, those people cause at least just as many problems as people who perform really poorly.
I think the tone of the article (cynical, exagerating bad traits, etc.) promotes that kind of toxic culture, while not bringing much to the table in terms of fighting mediocrity. That is all.
Fair enough, thanks for clarifying. I haven't run into too many of those people (brutally aggressive and terrific engineers). The toxic people I've run into spent all their time trying to look smart to cover their incompetence.
It'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.
The 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.
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.
- 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.
You 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.
I'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.
The 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.
It 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.
If anyone actually had the solution to this problem, they'd probably be a billionaire with the most productive software company in the world, by a large margin. Solving this problem is basically the holy grail of software development. Personally, I'm not sure this problem can be solved, since it's a product of flaws in human psychology: fixing it would mean changing humans into something non-human, or just eliminating humans altogether and having AIs do these jobs.
No 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.
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.
>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).
Taking 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.
Except that, demanding that people have solution, which is what parent did and "taking the bare minimum of time to understand a problem" are two massively different standards. The original article definitely clears the "taking bare minimum time to understand a problem" standard. Neither parent nor you are content.
> If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs.
Obvious difference is that article did not complained about trivial issues. It complained about very real issues that waste massive amount of time.
> I don’t think you’re saying that you couldn’t explain why the light not working is a problem.
Adding "I do not see without light" is completely unnecessary when complaining about broken switch. There is zero need for it. Similarly, it is no mystery why issues in article are problems.
If you are unclear about why any of listed issues is a problem or disagree, you could have made that claim. But, neither parent nor you claimed not understanding that. All you want is to prevent people from talking about these issues.
I never said the article should have solutions, or that the issues in the article are not problems, or that they shouldn’t be talked about. If you want to assign a point of view to me that I don’t believe then this is a pointless discussion.
Nothing. 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.
I don't want to empower jerks.
Anything particular I should change? Or is the structure of the essay too cynical overall?