You take proactive approach, listen to people, work on reducing complexity.
Then you wake up one day being steamrolled by business change where other senior dev with some business analyst hijacks process does some awful crap "because business needs this ASAP" and leaves you maintaining/fixing up pile of crap.
Guess who is blamed later on for the system is not up to standard like having security hole or totally not logical flow in places where "business need" was implemented. Keep in mind after 6 months no one will remember they did that business change everyone will remember that you are maintaining the system because you try to keep it decent so it is your fault ;)
They might not blame you for it, but you're definitely in every meeting with eyes on you to fix it. Blaming the predecessor at this point is not only futile, but makes you look bad as well.
P is what most people would consider 10x engineer (but not this article). Can get anything done few times quicker than anyone else. It's like 10 junior engineers stacked in one person. But it often would be unmaintainable mess.
M is a lot like article describes. Understands what needs to be done and creates good technical designs. Often unf*s mess created by P. Delivers business value. Do not write a lot of code.
It's funny that depending on whom you ask, M or P would be the 10x engineer and other would be the bad engineer. Real 10x engineer can wear the M or P hat depending on circumstances.
"A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again."
Not again. The real world does not work like that. The author has the luxury to have team meetings, onboarding, agile and all of that nonsense because the hard parts of open source have already been written by 10x engineers.
What the author is working on is presumably some kind of devops that uses other people's software.
Perhaps OSS was a mistake. It enables all sorts of pundits and is now repackaged by "AI".
> Good engineers know how to influence others and the organization to deliver a solution as a team.
This is a Problem, assuming someone is good at talking is also a good engineer.
> Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality.
Complexity for the manager? Who is deciding how complex a system is. This could also be a skill issue with the „team“ by taking skilled engineers and mix them with not so skilled ones.
Overall the article is written for managers which try to add a image of an engineer which is like a manager. Influence people and give up on complex stuff.
I know a lot of engineers follow various principles like SOLID, DRY, Clean Architecture and so on, but as far as complexity goes it’s really rather straight forward. You never add abstractions until you can’t avoid them. We’ve had 20 years of these principles (and what other nonsense OOP had brought with it) now, and despite the fact that many of them were written by people who haven’t worked in software engineering since a decade before Python was made they still remain popular and largely unaltered. Which is silly considering our industry has never been more of a mess, with so many teams building complexity to “future proof” things that they will never need, to the point where some teams actively hinder the business.
Complexity is fairly straight forward in my opinion. You build after the YAGNI principles and you include things from SOLID, DRY, CLEAN, whatever when it makes sense to do so. If you happen to enter a team that has dug themselves into a pit of unnecessary complexity you need to work on reducing it.
This is takes a good engineer, because the fundamental reason to do this or that comes down to engineering. People who follow dogmas are not good engineers. You will even see the authors of some of these principles like Uncle Bob tell you that people who over complicate their code bases misunderstand his principles. Convenient when your career is selling consultant, but also very true.
> Complexity is fairly straight forward in my opinion.
That's a bold take.
The difficult thing with complexity is that it's an abstract and, sometimes, subjective concept. (Not speaking of measurable complexity like cyclomatic or algorithmic.)
It may involve abstractions, yes, but those are usually introduced with the argument that they—ironically enough—_simplify_ some interface or process. It's difficult to argue against that since we deal with abstractions on a daily basis which _do_ make our lives easier, from the hardware layer and up. So then the task of removing abstractions becomes an uphill battle to convince the rest of the team that this is indeed a good idea. This is a sociocultural and political problem, not strictly related to engineering.
So I don't see the task of resolving complexity as being this straightforward. The best approach I've found of dealing with this is to focus on things we can measure instead. Use linters to warn you about cyclomatic complexity, function length, dead code, single interface implementations, and any other quantifiable metric that contributes to increasing complexity. Even this is often difficult to align on within teams, but with it in place at least there's an objective metric that can guide the team in the right direction.
This is fine if you see programmer as a sort of large factory blue collar worker, but not all programmers see themselves in such position of a perfect cog in your "org".
Disturbing fact: sometimes you get best ideas out of boredom:)
I like the post, but it's a bit idealistic. It's like a laundry list of all the perfect attributes of almost any profession. It's like reading a religious text.
I don't agree that it's idealistic because it's only directional - it tells you what to move towards, it doesn't give you any idealistic target or criteria for any of the things it lists. Which seems like a good thing.
All posts on this topic should start with a brief description of the problem domain, because all sensible conclusions depend on it. There are problem domains where you just have to be insanely smart to be able to contribute, and there are others (as I get the feeling is the case here) where you just need to be reasonably socially competent and dependable. A “good engineer” in one domain can be terrible in another.
The article is good, but I think it communicates with a narrower audience than it intended to in terms of demographics, especially the ones who do not work in nice tech companies.
For instance that passage:
> I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code.
I used to work in a tech company (bytes), and now I am working in an old money/traditional company (atoms) that uses technology marginally to stay ahead. My team's (a couple of dozens) median age is 53, and I do not see how this relates to them or even to myself.
I definitely would like to hear more from "Working Bee Engineer", "Dark Matter Engineer", "How I survived 25 layoffs Engineer", "How I kept my sanity working with internal clients Engineer", "I managed to raise kids being in Tech as Engineer", "The bodybuilder/triathlete/sports(wo)man Engineer" and so on.
I'm not being cynical, but I miss the old days of actionable and down-to-earth blogposts that anyone could relate to.
It’s useful to have a vision like this. Not because everyone will hit all these criteria. (If you do, I’d love to steal your hiring process.)
I find it useful because coaching people to be better is easier with an ideal like this to point to, that is complete. Lots of managers struggle to put into words why they don’t see an employee as they see themselves. If you have a genuine difference of opinion, you can relate back to something like this. Say your employee does a lot of tickets, and sees themselves as a hyper productive engine on a team. You as a manager see them picking up low-impact tickets and not finishing any features the business asked for end-to-end. The employee wants their productivity to be recognized. You want your employee to be more focused on a single business outcome rather than seeing a high number of tickets in the done column.
Some people (especially neurodivergent people) really “get it” when they have a pre-read they can think on and apply to their situation. A blog post like this is nice because you can have the employee read a bullet and then talk about how it applies to their situation in a 1:1.
This post is sooo symptomatic of people who have too much time and don't seem to be educated beyond their field. Overthinking something that maybe not that complicated after all. The egos of software people is just bigger than it should be. Also mythical thinking like "10x bla bla" is symptomatic.
Your comment is basically a personal attack of the character of the author. Totally unnecessary. Additionally, I completely disagree with your assessment. It's clear the author has spent a lot of time thinking about this and you framing it as "over thinking" and "not educated beyond their field" and "big ego" is downright mean spirited, wrong, and reductivism.
Of course it is a personal attack on the character of the person. That is the only thing guard-railing spreading nonsense. Software people need to work on their character.
Very inspiring! I'm off to "embed quality elements into my deliverables to increase consistency and velocity."
Apart from the tone, I agree that it's awesome when an engineer understands your fucked up process and manages to be productive despite it ("goes beyond the processes to independently drive work"), but as a manager you can't count on most people being like that and so you should work very hard to make your process work for people who do not think very much about what could go wrong when acting fairly naively according to this process.
It says in the end that these are basic expectations from any engineer or even any employee. Well, maybe, but most people don't meet these expectations, and it's a basic expectation from a manager to be able to work with actually available people and not only imaginary ones.
Good engineers want to create the best product possible, and are demanding from the product team. They want clarity and visibility on user insight in order to be able to do the right tradeoffs to maximize customer satisfaction.
-> I think that as engineers, we also have the responsibility to create the best product (interested to have your feedback, I want to create a meetup talk on this subject)
I don't think good engineering is a soup of confusion like the one in this article. simple is beautiful. And I think good engineering is associated with simplicity.
A developer that ticks all these boxes is certainly a Good Software Engineer, but the reverse relation doesn't necessarily hold. There are many that have made very valuable contributions while not even working on a team, or perhaps even being an asshole to everyone around them, ignoring stakeholders, everything. Or just something less extreme, such as maybe they didn't at all times know their organization that well. That is fine, if it works at their time and place. To call those "Bad Software Engineers" is unhelpful.
What differentiates a good programmer from a bad one? The good programmer will navigate the unknown on his own while the bad programmer will struggle. That's about it. It does not matter what level of proficiency the programmer is at right now. It is a state of mind. The core of a personality. This translates to the whole career. Can you figure things out on your own or do you need someone to guide you, is what makes the ultimate difference.
I think you're on to something but I wouldn't call it a personality trait. It's something that can be learned, but it takes a ridiculous amount of time. I've been teaching programming to complete beginners now for a few years and there is always a point in time during their education where this clicks: they go from asking about everything to realizing that there are often no easy answers and start doing their own research and problem solving.
This is spot on—a simple and precise explanation. As a programmer myself, I’ve seen developers dive into a 15-year-old codebase, independently work through it, and only ask questions once they’ve exhausted all other options.
I think it also matters what happened during the intervening 15 years. If you built an app in 2004 and haven't touched it really since, then it should hopefully still be reasonably easy to follow along, even if the conventions might seem outdated.
15 years of active feature development on the other hand will likely be a major slog for any developer, regardless of experience. There's a lot that can happen in 15 years even if there were only 1-3 developers if they everyone takes the easy path since they know where all the gotchas are. It's only when new devs are added that the curtain comes down and the lazy abstractions (or lack thereof) are exposed.
I have read many of this types of blog posts about 10x, good engineers and such.
The only thing I have learned during my close to 30 years of professional experience is how incredible rare they are. The really good engineers in IT.
They are so rare so MOST people will never work with even one. That is how rare they are.
And a "Blogger, Writer, Philospher" - have probably never worked with one, and never will. Because they are in a whole different sphere of engineering.
The number of systems is increasing explonentially - the number of truely good engineer is pretty much a constant number.
Maybe it's hard to accept that often, code quality or technical prowess are not that important.
What is really important is understanding the actual process that is being supported by the thing you're building.
It's so obvious but building something technically sound that doesn't address the actual organisational need is a 100% waste of time and has a huge opportunity cost.
And the reality seems to be that the business and IT don't know the right answer upfront, so it's - cliché alert - a journey between professionals helping each other understand how a proces should operate.
This has NOTHING to do with technology or technical implementations. At this level, tech is just an abstraction, a black box that does magic.
Another day, another listicle about senior/staff/principal developer labelling disguised as a blog. Only insecure devs care about this crap. Devs who know their shit aren't coming up with definitions distinguishing themselves from devs who don't. They have better things to do (e.g. actual work).
Meanwhile there's not that much posted/discussed about good (so not 10x, just 1x instead of 0.5x or negative) engineering/product managers.
In my experience where I've worn both IC and TL/manager hats -even just going from "adequate" to "OK" team/engineering/product manager leads to impact/output that's bigger than having the best (so that mythical 10x) engineer.
At least some of these lists will be created to define the scope of the good engineer so it applies to them, or habits they like, but there's nothing that actually clarifies the benefit here. Is there a measurable increase in revenue, feature releases, uptime?
I've worked as a contractor for a decade. I'm brought in to deliver specific outcomes by specific timelines. There are polarizing views on what I do. Some will view me as the 10x engineer; others a bit of a cowboy.
However, there's no lack of "good engineers" that aren't able to deliver working software in a timely manner, which is why I'm even at those orgs in the first place.
You can disagree with any of this list, of course, but that's not what the previous poster was doing: it's just a shallow dismissal, and a claim that it was written for what are essentially bad faith reasons. That's quite a different thing than "I disagree with this because X" (which is what you're doing).
Then look at articles that are a bit better than this one, which manages to come up with the blandest of ... definitions?
> A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again.
What a vacuous statement. The phrase "as a manager or peer" is so 2014 "user story". And it doesn't get more linkedin than "to progress a project." The whole sentence just says "A good engineer is someone who will do his/her job." It's meaningless drivel.
The more a company attempts to define what a "good software engineer" is, the worse their hiring practices will become as they come to believe they can identify and select for "good software engineers".
As the author says after articulating a long list of traits of a first class developer; "I strongly believe all that I’ve mentioned is a basic expectation from any engineer."
Folks, apply for jobs where the employer is pragmatic about hiring and gets people employed and gets on with the job.
Process people can't resist trying to optimize things they superficially comprehend.
When business ops tries to define how engineers with decades of experience should solve problems, it is usually a conversation with a firm heading for failure.
Smart people usually just quickly leave a doomed project... =3
I don't like this re-framing of "the 10x engineer" to be someone who writes 10 times as much low-quality code.
It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
I don't think there are any myths involved, we can name people. Fabrice Bellard leaps to mind. A bunch of the OSS maintainers. These people are just observably (much more than) 10x more productive than the standard developer. People cast from the same mold turn up from time to time in the corporate world too.
Part of it is problem selection, part of it is hard work, some fraction appears to be genius. But it is obvious and observable, I've seen average developers at work and they just won't achieve the results the top performers get even if given 10x as much time.
The same reason shows why the bimodal and 'branded' name is such a strange thing to focus on.
Why only 10x? And why not try to make your 1x into 2x?
It's like if sports fans spent all their time talking about a potential player who could deliver exactly 10 times more goals than everyone else. Why is this a topic that needs to be brought up so often? Why have we 'software engineer'-ised the idea that some people are much more important for productivity?
I should clarify that by referring to it as a myth, I'm not denying in my post that there are people who are 10x as productive as most people.
The "myth" is that there was a formal study done and these performers were identified. The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
This has since evolved to a further myth that 10x programmers exist, but are somehow always harmful and should be avoided. There are plenty of articles examining "The 10x programmer myth" which, with no more evidence than the original assertion, put forward that 10x programmers should be avoided.
And here in this article, it gets re-written again, that they aren't even 10x as productive, and just produce ten times as much in terms of LOC but it's all terrible code!
> The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
That is an important, often misunderstood, clarification, but I think it’s also subtly incorrect.
It’s 10x higher than some minimally competent level, not 10x higher than the worst in the field.
I think the original studies (certainly later follow-up studies did this) excluded results from participants who did not complete the assignment at all. That makes some sense from a data analysis convenience standpoint, but truncating the left tail and then saying some are 10x better than the absolute worst (that you truncated in the previous step) isn’t fully representative of what we see in the field.
In any case, people on here tend to be extremely sceptical of social science results, and demand much better standards and reproducibility.
Except that particular 1968 paper, which is held up and treated as gospel, because it helps to confirm rather than challenges their personal experience.
If we are going to demand better, we should do so consistently. Reproducing that result with more rigour would be a useful start.
When I first heard "10x" I assumed it meant someone who had "10x" the effect with the same amount of effort. Someone experienced who can judo-chop problems away (if they're allowed to). Someone who force-multiplies everyone around them rather than being just another grinding cog.
But nowadays "10x" just goes into the same pile I throw "agile" and other meaningless terms.
A myth based on another myth... OTOH, it's definitely easier to be more productive if you cut corners (or "incur technical debt" if you want to say it in a more sophisticated way). Generally, a more productive developer will know where to focus their effort, e.g. understand the business logic so they don't spend time handling cases that won't happen in practice, know where tests are most needed and leave other areas for later, automate repetitive tasks or find tools that make a task easier, etc.
Sometimes it’s not even about cutting corners. Just pushing back against poor meeting culture and declining pointless meetings can easily give you a 2x boost.
That almost always ends with an architecture that only the original author can change, so hard disagree ^ _ _ _ _ ^
It's really pointless to quantify the productivity of a developer via numbers. It's a conjunction of knowledge, intelligence and ability to express this as code.
And also communication. I find it weird how everyone is talking about the code, but a huge part of the job is communicating properly with others so that you don't produce useless code, and that others know how to properly integrate with it.
> It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
There were several studies, and it’s about being 10× as productive as the worst not the average.
Yeah I'm also sick of seeing articles cite this mythical trade-off, where any increase in programming output must be correlated with being a bad team member, churning out bad code, and generally being a pain to work with.
Anyone that's worked with engineers can tell you that there are simply some people getting more done than others, in the same amount of time. Are there people producing bad code? Yes. But I don't think output is inversely correlated with code quality. In fact the people I've worked with that have the most output, also had some of the highest quality code. I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers. He probably exists somewhere, but not with the sort of prevalence that justifies every programming productivity article ripping on his archetype.
In our team's current project, the engineers who can be described as "10x engineers" are the slowest when it comes to delivery of features. They have been transferred to a legacy project with lacking tests, messy spaghetti code full of bugs. They spend a lot of time adding tests, refactoring the code to be more modular, removing various cruft. It looks like they are much slower than the previous mediocre engineers, and they produce a lot of code, but it pays off: while the userbase is increasing, our bug reports rate per month has decreased by 2x in a matter of 1.5 years. So I think the amount of code output is only part of the equation.
If a system is impossible to maintain, that system is nothing of value, and therefore doesn't fit to any sensible definition of 10x.
I have always assumed that the 10x means value creation, not some kind of "lines of code" output or other nonsense. And for sure there are 10x programmers, maybe even 100x. I have been mostly working at startups and you see these early stage decisions and designs that create huge costs when the company starts to scale, similarly you have some decisions that might save huge amount of costs during the company life time, or allow better revenue generation etc.
> I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers.
I've seen this plenty of times.
Recently I was trying to explain the pros and cons of micro-services, and more importantly, microrepos, with regards to automated testing. The lead engineer that said he'd quit if I colocated the tests with the app.
Same place, they replaced all deploy system with argo, but every environment is pinned against main, which means you can no longer test a change without it going to all environments at the same time.
In both cases, the engineers are actually much higher skilled than average and churn out / lead change, but they'd rather be chasing a fad and just don't care if their changes shit on other parts of the SDLC.
That case sounds more like you being 0.1x developer about obsessing over test automation, where the 1x guy just didn't seem them to be worthwile.
Personally I have had clashes during my career with people who obsess about unit testing way too much in places where it just doesn't add any value (in fact destroys it by requiring lots of work and additional mainteinance). Value in the end is quite a subjective thing so it doesn't make sense to argue that much about it.
So have I, and I'm pretty impressed you could decipher that from a single comment, and it doesn't reflect poorly on you at all that you immediately drew such a conclusion from someone refusing to discuss pros and cons of solutions.
This. My understanding of 10x engineers was, even if a bit tongue-in-cheek, always positive. They are the smart guys and girls that know what they are talking and think ahead a few miles. It sure can be overwhelming when you hear them talk, but if you let it sink it in, it makes sense.
But we as a society should not pretend that this is what you have to be. There are just some smart people in the world, but they are rare. You don't need to be one to be a good person.
For me the 10x engineers don't write the same code as others faster, they come up with approaches and ideas that others simply don't think of, resulting in huge gains in terms of development speed and/or product features.
I too thought that immediately but I’d encourage you to read on (if you haven’t already) as the rest of the article — a list of bolded statements about good engineers with further explanation in each paragraph — is pretty solid in my opinion.
If you’ve played the game RuneScape, you know well that some players accomplish feats that are hard to comprehend.
You have people gaining billions of experience points or tens of thousands of boss kills in the same amount of calendar days the average player accomplishes tens of millions or hundreds of boss kills.
I don’t see why this couldn’t be the case for software engineering. I have a wife and kids and spend 10 to 15 hours doing sports a week. I’m maybe more efficient than average since my career has gone well, but there are people who are way more efficient and way smarter than me. Couple that with them being able to spend twice or more the number of hours, and you might arrive at similar 10-100x productivity numbers that you see on the game RuneScape.
You take proactive approach, listen to people, work on reducing complexity.
Then you wake up one day being steamrolled by business change where other senior dev with some business analyst hijacks process does some awful crap "because business needs this ASAP" and leaves you maintaining/fixing up pile of crap.
Guess who is blamed later on for the system is not up to standard like having security hole or totally not logical flow in places where "business need" was implemented. Keep in mind after 6 months no one will remember they did that business change everyone will remember that you are maintaining the system because you try to keep it decent so it is your fault ;)
I have seen this so many times. You almost made me weep.
It's tragedy of commons. To stop this we need software engineers to own their own code legally.
They might not blame you for it, but you're definitely in every meeting with eyes on you to fix it. Blaming the predecessor at this point is not only futile, but makes you look bad as well.
Ah yes, nothing quite like trashing half the codebase because "a customer needs this next week" and then having to maintain that shit for years.
Story of two engineers in a team I worked with.
P is what most people would consider 10x engineer (but not this article). Can get anything done few times quicker than anyone else. It's like 10 junior engineers stacked in one person. But it often would be unmaintainable mess.
M is a lot like article describes. Understands what needs to be done and creates good technical designs. Often unf*s mess created by P. Delivers business value. Do not write a lot of code.
It's funny that depending on whom you ask, M or P would be the 10x engineer and other would be the bad engineer. Real 10x engineer can wear the M or P hat depending on circumstances.
I wonder if it woudl be better to think of it as the the 10X team, rather than a single 10x developer.
Im still studying CS so I'm probably way off base,but it seems far more realistic, and usefull.
"A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again."
Not again. The real world does not work like that. The author has the luxury to have team meetings, onboarding, agile and all of that nonsense because the hard parts of open source have already been written by 10x engineers.
What the author is working on is presumably some kind of devops that uses other people's software.
Perhaps OSS was a mistake. It enables all sorts of pundits and is now repackaged by "AI".
> Good engineers know how to influence others and the organization to deliver a solution as a team.
This is a Problem, assuming someone is good at talking is also a good engineer.
> Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality.
Complexity for the manager? Who is deciding how complex a system is. This could also be a skill issue with the „team“ by taking skilled engineers and mix them with not so skilled ones.
Overall the article is written for managers which try to add a image of an engineer which is like a manager. Influence people and give up on complex stuff.
I know a lot of engineers follow various principles like SOLID, DRY, Clean Architecture and so on, but as far as complexity goes it’s really rather straight forward. You never add abstractions until you can’t avoid them. We’ve had 20 years of these principles (and what other nonsense OOP had brought with it) now, and despite the fact that many of them were written by people who haven’t worked in software engineering since a decade before Python was made they still remain popular and largely unaltered. Which is silly considering our industry has never been more of a mess, with so many teams building complexity to “future proof” things that they will never need, to the point where some teams actively hinder the business.
Complexity is fairly straight forward in my opinion. You build after the YAGNI principles and you include things from SOLID, DRY, CLEAN, whatever when it makes sense to do so. If you happen to enter a team that has dug themselves into a pit of unnecessary complexity you need to work on reducing it.
This is takes a good engineer, because the fundamental reason to do this or that comes down to engineering. People who follow dogmas are not good engineers. You will even see the authors of some of these principles like Uncle Bob tell you that people who over complicate their code bases misunderstand his principles. Convenient when your career is selling consultant, but also very true.
> Complexity is fairly straight forward in my opinion.
That's a bold take.
The difficult thing with complexity is that it's an abstract and, sometimes, subjective concept. (Not speaking of measurable complexity like cyclomatic or algorithmic.)
It may involve abstractions, yes, but those are usually introduced with the argument that they—ironically enough—_simplify_ some interface or process. It's difficult to argue against that since we deal with abstractions on a daily basis which _do_ make our lives easier, from the hardware layer and up. So then the task of removing abstractions becomes an uphill battle to convince the rest of the team that this is indeed a good idea. This is a sociocultural and political problem, not strictly related to engineering.
So I don't see the task of resolving complexity as being this straightforward. The best approach I've found of dealing with this is to focus on things we can measure instead. Use linters to warn you about cyclomatic complexity, function length, dead code, single interface implementations, and any other quantifiable metric that contributes to increasing complexity. Even this is often difficult to align on within teams, but with it in place at least there's an objective metric that can guide the team in the right direction.
This is fine if you see programmer as a sort of large factory blue collar worker, but not all programmers see themselves in such position of a perfect cog in your "org".
Disturbing fact: sometimes you get best ideas out of boredom:)
> Good engineers understand the stakeholders’ needs…
In my experience, this can take two very different forms:
1. Being observant of a stakeholder’s stated needs.
2. Being confident enough to tell a stakeholder what their needs should be.
On a pedantic note, I would prefer the term ‘effective’ engineer to ‘good’ engineer. The later sounds like a judgment on their moral character.
i often state 1/2 as
> what they want isn’t necessarily what they need
and i agree with effective. it’s less of a loaded term but i feel it’s also a more accurate description of what we try to strive for as engineers.
Heh Heh Heh. Queue the post about highly effective evil engineers then?
Star Wars Death Star stuff maybe, or a perhaps a global system to direct people's attention to ads? ;)
Edit: oops read too quickly. Disregard:
I don't think of morals when I read "effective engineer" personally
“The latter” means “the second of the two options I just mentioned”, so in this case he is saying that ‘good’ engineer feels like a moral judgment.
I read too quickly. Thanks
Good engineers are pedantic about terminology such as effective versus good.
I like the post, but it's a bit idealistic. It's like a laundry list of all the perfect attributes of almost any profession. It's like reading a religious text.
I don't agree that it's idealistic because it's only directional - it tells you what to move towards, it doesn't give you any idealistic target or criteria for any of the things it lists. Which seems like a good thing.
All posts on this topic should start with a brief description of the problem domain, because all sensible conclusions depend on it. There are problem domains where you just have to be insanely smart to be able to contribute, and there are others (as I get the feeling is the case here) where you just need to be reasonably socially competent and dependable. A “good engineer” in one domain can be terrible in another.
The article is good, but I think it communicates with a narrower audience than it intended to in terms of demographics, especially the ones who do not work in nice tech companies.
For instance that passage:
> I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code.
I used to work in a tech company (bytes), and now I am working in an old money/traditional company (atoms) that uses technology marginally to stay ahead. My team's (a couple of dozens) median age is 53, and I do not see how this relates to them or even to myself.
I definitely would like to hear more from "Working Bee Engineer", "Dark Matter Engineer", "How I survived 25 layoffs Engineer", "How I kept my sanity working with internal clients Engineer", "I managed to raise kids being in Tech as Engineer", "The bodybuilder/triathlete/sports(wo)man Engineer" and so on.
I'm not being cynical, but I miss the old days of actionable and down-to-earth blogposts that anyone could relate to.
It’s useful to have a vision like this. Not because everyone will hit all these criteria. (If you do, I’d love to steal your hiring process.)
I find it useful because coaching people to be better is easier with an ideal like this to point to, that is complete. Lots of managers struggle to put into words why they don’t see an employee as they see themselves. If you have a genuine difference of opinion, you can relate back to something like this. Say your employee does a lot of tickets, and sees themselves as a hyper productive engine on a team. You as a manager see them picking up low-impact tickets and not finishing any features the business asked for end-to-end. The employee wants their productivity to be recognized. You want your employee to be more focused on a single business outcome rather than seeing a high number of tickets in the done column.
Some people (especially neurodivergent people) really “get it” when they have a pre-read they can think on and apply to their situation. A blog post like this is nice because you can have the employee read a bullet and then talk about how it applies to their situation in a 1:1.
This post is sooo symptomatic of people who have too much time and don't seem to be educated beyond their field. Overthinking something that maybe not that complicated after all. The egos of software people is just bigger than it should be. Also mythical thinking like "10x bla bla" is symptomatic.
Your comment is basically a personal attack of the character of the author. Totally unnecessary. Additionally, I completely disagree with your assessment. It's clear the author has spent a lot of time thinking about this and you framing it as "over thinking" and "not educated beyond their field" and "big ego" is downright mean spirited, wrong, and reductivism.
Of course it is a personal attack on the character of the person. That is the only thing guard-railing spreading nonsense. Software people need to work on their character.
> That is the only thing guard-railing spreading nonsense.
I am honestly disappointed to see this level of discourse on HN.
Very inspiring! I'm off to "embed quality elements into my deliverables to increase consistency and velocity."
Apart from the tone, I agree that it's awesome when an engineer understands your fucked up process and manages to be productive despite it ("goes beyond the processes to independently drive work"), but as a manager you can't count on most people being like that and so you should work very hard to make your process work for people who do not think very much about what could go wrong when acting fairly naively according to this process.
It says in the end that these are basic expectations from any engineer or even any employee. Well, maybe, but most people don't meet these expectations, and it's a basic expectation from a manager to be able to work with actually available people and not only imaginary ones.
Good engineers want to create the best product possible, and are demanding from the product team. They want clarity and visibility on user insight in order to be able to do the right tradeoffs to maximize customer satisfaction.
-> I think that as engineers, we also have the responsibility to create the best product (interested to have your feedback, I want to create a meetup talk on this subject)
I don't think good engineering is a soup of confusion like the one in this article. simple is beautiful. And I think good engineering is associated with simplicity.
FTA: "Setting expectations for software engineers is tricky for all managers."
What about: "Setting expectations for managers is tricky for all software engineers." ?
A developer that ticks all these boxes is certainly a Good Software Engineer, but the reverse relation doesn't necessarily hold. There are many that have made very valuable contributions while not even working on a team, or perhaps even being an asshole to everyone around them, ignoring stakeholders, everything. Or just something less extreme, such as maybe they didn't at all times know their organization that well. That is fine, if it works at their time and place. To call those "Bad Software Engineers" is unhelpful.
What differentiates a good programmer from a bad one? The good programmer will navigate the unknown on his own while the bad programmer will struggle. That's about it. It does not matter what level of proficiency the programmer is at right now. It is a state of mind. The core of a personality. This translates to the whole career. Can you figure things out on your own or do you need someone to guide you, is what makes the ultimate difference.
I think you're on to something but I wouldn't call it a personality trait. It's something that can be learned, but it takes a ridiculous amount of time. I've been teaching programming to complete beginners now for a few years and there is always a point in time during their education where this clicks: they go from asking about everything to realizing that there are often no easy answers and start doing their own research and problem solving.
This is spot on—a simple and precise explanation. As a programmer myself, I’ve seen developers dive into a 15-year-old codebase, independently work through it, and only ask questions once they’ve exhausted all other options.
>15 year old codebase
Is this what people think of when they think of an old codebase? Must be nice :')
I think it also matters what happened during the intervening 15 years. If you built an app in 2004 and haven't touched it really since, then it should hopefully still be reasonably easy to follow along, even if the conventions might seem outdated.
15 years of active feature development on the other hand will likely be a major slog for any developer, regardless of experience. There's a lot that can happen in 15 years even if there were only 1-3 developers if they everyone takes the easy path since they know where all the gotchas are. It's only when new devs are added that the curtain comes down and the lazy abstractions (or lack thereof) are exposed.
Good leetcoder is good engineerer
I have read many of this types of blog posts about 10x, good engineers and such.
The only thing I have learned during my close to 30 years of professional experience is how incredible rare they are. The really good engineers in IT.
They are so rare so MOST people will never work with even one. That is how rare they are.
And a "Blogger, Writer, Philospher" - have probably never worked with one, and never will. Because they are in a whole different sphere of engineering.
The number of systems is increasing explonentially - the number of truely good engineer is pretty much a constant number.
Maybe it's hard to accept that often, code quality or technical prowess are not that important.
What is really important is understanding the actual process that is being supported by the thing you're building.
It's so obvious but building something technically sound that doesn't address the actual organisational need is a 100% waste of time and has a huge opportunity cost.
And the reality seems to be that the business and IT don't know the right answer upfront, so it's - cliché alert - a journey between professionals helping each other understand how a proces should operate.
This has NOTHING to do with technology or technical implementations. At this level, tech is just an abstraction, a black box that does magic.
Another day, another listicle about senior/staff/principal developer labelling disguised as a blog. Only insecure devs care about this crap. Devs who know their shit aren't coming up with definitions distinguishing themselves from devs who don't. They have better things to do (e.g. actual work).
Meanwhile there's not that much posted/discussed about good (so not 10x, just 1x instead of 0.5x or negative) engineering/product managers.
In my experience where I've worn both IC and TL/manager hats -even just going from "adequate" to "OK" team/engineering/product manager leads to impact/output that's bigger than having the best (so that mythical 10x) engineer.
Or, you know, people interested in building a team of Good Software Engineers are interested in thinking about this sort of thing.
Also: Please don't post shallow dismissals, especially of other people's work.
https://news.ycombinator.com/newsguidelines.html
Depends.
At least some of these lists will be created to define the scope of the good engineer so it applies to them, or habits they like, but there's nothing that actually clarifies the benefit here. Is there a measurable increase in revenue, feature releases, uptime?
I've worked as a contractor for a decade. I'm brought in to deliver specific outcomes by specific timelines. There are polarizing views on what I do. Some will view me as the 10x engineer; others a bit of a cowboy.
However, there's no lack of "good engineers" that aren't able to deliver working software in a timely manner, which is why I'm even at those orgs in the first place.
You can disagree with any of this list, of course, but that's not what the previous poster was doing: it's just a shallow dismissal, and a claim that it was written for what are essentially bad faith reasons. That's quite a different thing than "I disagree with this because X" (which is what you're doing).
Then look at articles that are a bit better than this one, which manages to come up with the blandest of ... definitions?
> A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again.
What a vacuous statement. The phrase "as a manager or peer" is so 2014 "user story". And it doesn't get more linkedin than "to progress a project." The whole sentence just says "A good engineer is someone who will do his/her job." It's meaningless drivel.
The more a company attempts to define what a "good software engineer" is, the worse their hiring practices will become as they come to believe they can identify and select for "good software engineers".
As the author says after articulating a long list of traits of a first class developer; "I strongly believe all that I’ve mentioned is a basic expectation from any engineer."
Folks, apply for jobs where the employer is pragmatic about hiring and gets people employed and gets on with the job.
You don't see blogs about all the desirable properties of a software company with 10/10 in every direction.
Process people can't resist trying to optimize things they superficially comprehend.
When business ops tries to define how engineers with decades of experience should solve problems, it is usually a conversation with a firm heading for failure.
Smart people usually just quickly leave a doomed project... =3
> Process people can't resist trying to optimize things they superficially comprehend.
Wow, I don't think I ever heard it summarised so well. I cannot agree more with this statement.
This is so profound, I need a t-shirt
"Process people can't resist trying to optimize things they superficially comprehend."
I don't like this re-framing of "the 10x engineer" to be someone who writes 10 times as much low-quality code.
It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
I don't think there are any myths involved, we can name people. Fabrice Bellard leaps to mind. A bunch of the OSS maintainers. These people are just observably (much more than) 10x more productive than the standard developer. People cast from the same mold turn up from time to time in the corporate world too.
Part of it is problem selection, part of it is hard work, some fraction appears to be genius. But it is obvious and observable, I've seen average developers at work and they just won't achieve the results the top performers get even if given 10x as much time.
It seems utterly obvious that there are 2x and 3x devs; we see them all around us. And there are outliers well above that level of common performance.
The denial by some of the existence of 10x engineers is one of the ongoing baffling mysteries to me.
The same reason shows why the bimodal and 'branded' name is such a strange thing to focus on.
Why only 10x? And why not try to make your 1x into 2x?
It's like if sports fans spent all their time talking about a potential player who could deliver exactly 10 times more goals than everyone else. Why is this a topic that needs to be brought up so often? Why have we 'software engineer'-ised the idea that some people are much more important for productivity?
I should clarify that by referring to it as a myth, I'm not denying in my post that there are people who are 10x as productive as most people.
The "myth" is that there was a formal study done and these performers were identified. The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
This has since evolved to a further myth that 10x programmers exist, but are somehow always harmful and should be avoided. There are plenty of articles examining "The 10x programmer myth" which, with no more evidence than the original assertion, put forward that 10x programmers should be avoided.
And here in this article, it gets re-written again, that they aren't even 10x as productive, and just produce ten times as much in terms of LOC but it's all terrible code!
> The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
That is an important, often misunderstood, clarification, but I think it’s also subtly incorrect.
It’s 10x higher than some minimally competent level, not 10x higher than the worst in the field.
I think the original studies (certainly later follow-up studies did this) excluded results from participants who did not complete the assignment at all. That makes some sense from a data analysis convenience standpoint, but truncating the left tail and then saying some are 10x better than the absolute worst (that you truncated in the previous step) isn’t fully representative of what we see in the field.
In any case, people on here tend to be extremely sceptical of social science results, and demand much better standards and reproducibility.
Except that particular 1968 paper, which is held up and treated as gospel, because it helps to confirm rather than challenges their personal experience.
If we are going to demand better, we should do so consistently. Reproducing that result with more rigour would be a useful start.
It's completely opposite to the idea that a person's success in today's capitalism is only luck.
When I first heard "10x" I assumed it meant someone who had "10x" the effect with the same amount of effort. Someone experienced who can judo-chop problems away (if they're allowed to). Someone who force-multiplies everyone around them rather than being just another grinding cog.
But nowadays "10x" just goes into the same pile I throw "agile" and other meaningless terms.
A myth based on another myth... OTOH, it's definitely easier to be more productive if you cut corners (or "incur technical debt" if you want to say it in a more sophisticated way). Generally, a more productive developer will know where to focus their effort, e.g. understand the business logic so they don't spend time handling cases that won't happen in practice, know where tests are most needed and leave other areas for later, automate repetitive tasks or find tools that make a task easier, etc.
Sometimes it’s not even about cutting corners. Just pushing back against poor meeting culture and declining pointless meetings can easily give you a 2x boost.
"10x" very often means you produced 10x less, while keeping the same value.
That almost always ends with an architecture that only the original author can change, so hard disagree ^ _ _ _ _ ^
It's really pointless to quantify the productivity of a developer via numbers. It's a conjunction of knowledge, intelligence and ability to express this as code.
And also communication. I find it weird how everyone is talking about the code, but a huge part of the job is communicating properly with others so that you don't produce useless code, and that others know how to properly integrate with it.
> It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
There were several studies, and it’s about being 10× as productive as the worst not the average.
https://www.construx.com/blog/the-origins-of-10x-how-valid-i...
Then there are infinity-x engineers, because some problems just aren't solvable by the worst engineers. Or even typical engineers.
It wouldn't take them 10 times as long as Linus to make Linux or git, social context and all. It just wouldn't happen.
So what's the useful takeaway from this topic we spend so much energy on? 'Hire people who are good'?
Yeah I'm also sick of seeing articles cite this mythical trade-off, where any increase in programming output must be correlated with being a bad team member, churning out bad code, and generally being a pain to work with.
Anyone that's worked with engineers can tell you that there are simply some people getting more done than others, in the same amount of time. Are there people producing bad code? Yes. But I don't think output is inversely correlated with code quality. In fact the people I've worked with that have the most output, also had some of the highest quality code. I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers. He probably exists somewhere, but not with the sort of prevalence that justifies every programming productivity article ripping on his archetype.
In our team's current project, the engineers who can be described as "10x engineers" are the slowest when it comes to delivery of features. They have been transferred to a legacy project with lacking tests, messy spaghetti code full of bugs. They spend a lot of time adding tests, refactoring the code to be more modular, removing various cruft. It looks like they are much slower than the previous mediocre engineers, and they produce a lot of code, but it pays off: while the userbase is increasing, our bug reports rate per month has decreased by 2x in a matter of 1.5 years. So I think the amount of code output is only part of the equation.
If a system is impossible to maintain, that system is nothing of value, and therefore doesn't fit to any sensible definition of 10x.
I have always assumed that the 10x means value creation, not some kind of "lines of code" output or other nonsense. And for sure there are 10x programmers, maybe even 100x. I have been mostly working at startups and you see these early stage decisions and designs that create huge costs when the company starts to scale, similarly you have some decisions that might save huge amount of costs during the company life time, or allow better revenue generation etc.
> I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers.
I've seen this plenty of times.
Recently I was trying to explain the pros and cons of micro-services, and more importantly, microrepos, with regards to automated testing. The lead engineer that said he'd quit if I colocated the tests with the app.
Same place, they replaced all deploy system with argo, but every environment is pinned against main, which means you can no longer test a change without it going to all environments at the same time.
In both cases, the engineers are actually much higher skilled than average and churn out / lead change, but they'd rather be chasing a fad and just don't care if their changes shit on other parts of the SDLC.
That case sounds more like you being 0.1x developer about obsessing over test automation, where the 1x guy just didn't seem them to be worthwile.
Personally I have had clashes during my career with people who obsess about unit testing way too much in places where it just doesn't add any value (in fact destroys it by requiring lots of work and additional mainteinance). Value in the end is quite a subjective thing so it doesn't make sense to argue that much about it.
So have I, and I'm pretty impressed you could decipher that from a single comment, and it doesn't reflect poorly on you at all that you immediately drew such a conclusion from someone refusing to discuss pros and cons of solutions.
This. My understanding of 10x engineers was, even if a bit tongue-in-cheek, always positive. They are the smart guys and girls that know what they are talking and think ahead a few miles. It sure can be overwhelming when you hear them talk, but if you let it sink it in, it makes sense.
But we as a society should not pretend that this is what you have to be. There are just some smart people in the world, but they are rare. You don't need to be one to be a good person.
For me the 10x engineers don't write the same code as others faster, they come up with approaches and ideas that others simply don't think of, resulting in huge gains in terms of development speed and/or product features.
It's also environment dependent. Put a 10x engineer in a megacorp bureaucratized setting and they'll be slowed to the same crawl as everyone else.
In many cases I've observed 10x engineers are those that can simplify and automate the processes and programs to need minimal human input.
In some cases it's more about deleting code than producing it.
I too thought that immediately but I’d encourage you to read on (if you haven’t already) as the rest of the article — a list of bolded statements about good engineers with further explanation in each paragraph — is pretty solid in my opinion.
If you’ve played the game RuneScape, you know well that some players accomplish feats that are hard to comprehend.
You have people gaining billions of experience points or tens of thousands of boss kills in the same amount of calendar days the average player accomplishes tens of millions or hundreds of boss kills.
I don’t see why this couldn’t be the case for software engineering. I have a wife and kids and spend 10 to 15 hours doing sports a week. I’m maybe more efficient than average since my career has gone well, but there are people who are way more efficient and way smarter than me. Couple that with them being able to spend twice or more the number of hours, and you might arrive at similar 10-100x productivity numbers that you see on the game RuneScape.