On Good Software Engineers(candost.blog)
candost.blog
On Good Software Engineers
https://candost.blog/on-good-software-engineers/
104 comments
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.
It's tragedy of commons. To stop this we need software engineers to own their own code legally.
Like journalists who retain the copyright on their articles.
This is also a reason lots of decent open source code comes out of the media industry. As much as we despise the media for its effect on society, journalists are much better than software developers in enforcing their worldview on others.
This is also a reason lots of decent open source code comes out of the media industry. As much as we despise the media for its effect on society, journalists are much better than software developers in enforcing their worldview on others.
[deleted]
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.
Amazon’s “away team” method is supposed to account for this. The sponsoring business unit is (supposed to be) accountable for upkeep.
What happens if the entire team gets churned in 4 years? Or is 4 years the lifespan of a single BU nowadays?
I don't see a way to mitigate this unless you care about these things from the onset, but I suppose if you're a monopoly you can just do anything you want because you have no competition.
I don't see a way to mitigate this unless you care about these things from the onset, but I suppose if you're a monopoly you can just do anything you want because you have no competition.
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.
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 much rather have no 10x engineer on my team, but instead engineers who do just a bit more than the bare minimum.
For example, who don't just test their single use case, but check if it breaks anything around it. Or who invest just a tiny bit more time to actually write down what their bug analysis has yielded. Or who update the documentation after an interface change. Or who write solution designs to think about the approach, before hacking some ugly mess. Or who check with the PO or user if the chosen approach/design is what they expected. Or who ...
In my experience having devs who do more than the bare minimum is way more productive for most day-to-day business. Maybe there's room for a powerhouse in cases, where you have to drastically restructure a code base and quickly create some PoC.
For example, who don't just test their single use case, but check if it breaks anything around it. Or who invest just a tiny bit more time to actually write down what their bug analysis has yielded. Or who update the documentation after an interface change. Or who write solution designs to think about the approach, before hacking some ugly mess. Or who check with the PO or user if the chosen approach/design is what they expected. Or who ...
In my experience having devs who do more than the bare minimum is way more productive for most day-to-day business. Maybe there's room for a powerhouse in cases, where you have to drastically restructure a code base and quickly create some PoC.
Every business I've ever been at had a "strike team" of the 2x+ engineers (in the M sense) that didn't typically do maintenance work, they unfucked messes or rescued projects. It seemed pretty effective from my standpoint.
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.
Im still studying CS so I'm probably way off base,but it seems far more realistic, and usefull.
There are definitely 10X teams in that sense. Two problems:
(1) Very few corporate compensation programs are team-oriented; managers are structurally forced to reward/punish individuals, not teams. In many cases there is even some sort of forced distribution that requires the manager to punish someone on the team regardless of performance. This makes it counterproductive to attempt to construct a uniformly high-quality team in the first place.
(2) The organizational friction encountered by a 10X team is the same as for a 10X developer, only much larger in scope, thus more expensive and visible. A 10X developer might want to write a bunch of unit tests; a 10X team might want to swap out the entire CI/CD system and reorganize their relationship with product management.
(1) Very few corporate compensation programs are team-oriented; managers are structurally forced to reward/punish individuals, not teams. In many cases there is even some sort of forced distribution that requires the manager to punish someone on the team regardless of performance. This makes it counterproductive to attempt to construct a uniformly high-quality team in the first place.
(2) The organizational friction encountered by a 10X team is the same as for a 10X developer, only much larger in scope, thus more expensive and visible. A 10X developer might want to write a bunch of unit tests; a 10X team might want to swap out the entire CI/CD system and reorganize their relationship with product management.
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.
> there is always a point in time during their education where this clicks
Always?
Or are you showing a selection bias?
I call it "hitting your head against a brick wall". The tenacity to keep fighting until you win. Doesn't always work (can end up wasting time) but it is surprisingly effective against seemingly intratible problems. "Grit" is the marketing word. Workarounds is another form.
I'm interested in how it can be taught. I force myself because I admire a certain level of "OCD" behaviours and try to emulate those I admire.
Always?
Or are you showing a selection bias?
I call it "hitting your head against a brick wall". The tenacity to keep fighting until you win. Doesn't always work (can end up wasting time) but it is surprisingly effective against seemingly intratible problems. "Grit" is the marketing word. Workarounds is another form.
I'm interested in how it can be taught. I force myself because I admire a certain level of "OCD" behaviours and try to emulate those I admire.
No, unfortunately not always. Some people drop out before they learn it.
I think it's best learnt through encouragement and support. If I have one takeaway for the last 5+ years of teaching, it's that most barriers to learning are emotional, not intellectual.
I think it's best learnt through encouragement and support. If I have one takeaway for the last 5+ years of teaching, it's that most barriers to learning are emotional, not intellectual.
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 :')
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.
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.
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.
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.
> 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.
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. 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.
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.
> You never add abstractions until you can’t avoid them.
Whilst I accept that bad abstractions can really hold a codebase back, good abstractions and layering are what make code clean, understandable, and maintainable. I don't think we should throw the baby out with the bathwater.
What's important is having good designers who understand the domain and are able to judiciously select the "right abstractions" to apply at the "right time". Often this will mean people who have worked in a domain and made or experienced the consequences of mistakes previously.
Bad or inexperienced developers will write bad code. Good, experienced devs will do a little better. Don't let inexperienced devs design abstractions that you'll be stuck with for a while.
Whilst I accept that bad abstractions can really hold a codebase back, good abstractions and layering are what make code clean, understandable, and maintainable. I don't think we should throw the baby out with the bathwater.
What's important is having good designers who understand the domain and are able to judiciously select the "right abstractions" to apply at the "right time". Often this will mean people who have worked in a domain and made or experienced the consequences of mistakes previously.
Bad or inexperienced developers will write bad code. Good, experienced devs will do a little better. Don't let inexperienced devs design abstractions that you'll be stuck with for a while.
> You never add abstractions until you can’t avoid them.
What would be a case where you would _have_ to add an abstraction? I'd say you probably never have to, but things will get start getting complex.
What would be a case where you would _have_ to add an abstraction? I'd say you probably never have to, but things will get start getting complex.
I would abstract a holiday calculator service. I’d abstract a base class with “created_at” and similar for your data models in a traditional OOP sort of thing along with the audit table. I’d probably abstract something like an e-mail validation mixin.
Basically things which will never change, and when they do, you really don’t want them to change in a million things.
Otherwise I’d probably never add abstractions. Sometimes it makes sense to build a service which owns a domain on a business which is then consumed by others, but you have to make sure the consumption can be stopped when that domain is no longer relevant without it causing issues.
I’m not sure what my personal stance is on frontend components. Probably as low reuse as possible.
Basically things which will never change, and when they do, you really don’t want them to change in a million things.
Otherwise I’d probably never add abstractions. Sometimes it makes sense to build a service which owns a domain on a business which is then consumed by others, but you have to make sure the consumption can be stopped when that domain is no longer relevant without it causing issues.
I’m not sure what my personal stance is on frontend components. Probably as low reuse as possible.
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:)
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.
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.
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? ;)
Star Wars Death Star stuff maybe, or a perhaps a global system to direct people's attention to ads? ;)
Good engineers are pedantic about terminology such as effective versus good.
I'm hoping this is sarcasm. The people I've worked with who are highly pedantic wreck team dynamics and rarely deliver anything of value.
Edit: oops read too quickly. Disregard:
I don't think of morals when I read "effective engineer" personally
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
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.
> 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.
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.
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.
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.
Yeah like current sibling reply here, it's OK to be idealistic: "here's what I think perfect looks like", and accept that sure not everybody meets that definition. Doesn't mean it's a bad aspiration though.
I mostly agree with the article, FWIW. Including having worked with various "talented but difficult" people before.
One of the more under-appreciated aspects of management is having direct reports you can delegate stuff to and (a) they just deal with it, and (b) you need little or no supervision and there's no drama.
Managers are humans: making their lives a little better by being Mr/Mrs/Ms Reliably Gets Things Done will in any sane org yield dividends. Of course not all orgs are sane, and not all managers are Good Managers, but that's a different conversation.
I mostly agree with the article, FWIW. Including having worked with various "talented but difficult" people before.
One of the more under-appreciated aspects of management is having direct reports you can delegate stuff to and (a) they just deal with it, and (b) you need little or no supervision and there's no drama.
Managers are humans: making their lives a little better by being Mr/Mrs/Ms Reliably Gets Things Done will in any sane org yield dividends. Of course not all orgs are sane, and not all managers are Good Managers, but that's a different conversation.
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.
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.
"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".
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".
Would you be so kind as to elaborate? I definitely see you’re onto something.
How does the real world works? What are the hard parts? What’s wrong with using other people’s software?
How does the real world works? What are the hard parts? What’s wrong with using other people’s software?
I took their comment to mean that these people are standing on the massive mountains of progress that have been made, but not acknowledging that a lot of wasted effort was lost learning these things.
It's easy to only talk about what should be done with perfection in mind, it's another to talk about what can realistically be done.
It's no different in regards for anything else the humane race has done, we know the solutions to be done in regards to climate change, inequality; it's another to convince society to then go and try to solve these things with the solutions we thought of.
It's easy to only talk about what should be done with perfection in mind, it's another to talk about what can realistically be done.
It's no different in regards for anything else the humane race has done, we know the solutions to be done in regards to climate change, inequality; it's another to convince society to then go and try to solve these things with the solutions we thought of.
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.
I am honestly disappointed to see this level of discourse on HN.
Seems like the sort of thing dang et al. would normally remove.
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.
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.
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.
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.
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.
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.
I have a hot take about this: neurotypicals can't achieve this level of proficiency because the type of mind required is just too exquisite.
It requires a large bandwidth between parts of the brain that aren't usually that well connected. And it also requires some parts of the brain to not function very well, like ones that break/filter/censor out ideas and impulsiveness. Looking at you prefrontal cortex. That would explain why they are so rare.
I might have worked with one. They are just beyond human in terms of hyperfocus, pattern matching and technical memory. It's a humbling experience.
It requires a large bandwidth between parts of the brain that aren't usually that well connected. And it also requires some parts of the brain to not function very well, like ones that break/filter/censor out ideas and impulsiveness. Looking at you prefrontal cortex. That would explain why they are so rare.
I might have worked with one. They are just beyond human in terms of hyperfocus, pattern matching and technical memory. It's a humbling experience.
FTA: "Setting expectations for software engineers is tricky for all managers."
What about: "Setting expectations for managers is tricky for all software engineers." ?
What about: "Setting expectations for managers is tricky for all software engineers." ?
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 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)
This post makes me a bit angry. In a nutshell it’s promoting engineers doing more project management.
I think an engineer at any level should not be managing (“driving”) projects, and you should not expect that, unless you are able to pay “the engineer” both a manager’s and an engineer’s compensation.
I like the idealistic view on proactivity, but I think idealising this soup of responsibilities should not be promoted.
I want a good engineer and I want a good manager as well in a team.
I think an engineer at any level should not be managing (“driving”) projects, and you should not expect that, unless you are able to pay “the engineer” both a manager’s and an engineer’s compensation.
I like the idealistic view on proactivity, but I think idealising this soup of responsibilities should not be promoted.
I want a good engineer and I want a good manager as well in a team.
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 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.
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
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
This is so profound, I need a t-shirt
"Process people can't resist trying to optimize things they superficially comprehend."
"Process people can't resist trying to optimize things they superficially comprehend."
> 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.
Wow, I don't think I ever heard it summarised so well. I cannot agree more with this statement.
You don't see blogs about all the desirable properties of a software company with 10/10 in every direction.
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.
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
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.
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.
> 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.
> We can’t expect a junior engineer to drive a big project; their scope will be limited
I find it a dilemma when it comes to driving "big project", especially in a large company. The engineers who drive such projects often behave more like product managers. They sketch out key product features, work with teams to get roadmaps out, and convince the leadership and teams to get the right resources. In addition, they will also draw a few boxes to have a so-called "architecture diagram", and hand out the actual design and implementation to lower-level engineers. I don't deny the importance of such work, and I do recognize that junior engineers likely won't have the clout or the knowledge to push such project forward. On the other hand, I find the value of such high-level engineers diminish fast in the industry, especially when they want to switch jobs, for the will have lost the ability to get down to specifics to solve tough technical problems. Case in point, I have seen most of the so-called "uber TL" fail interviews because all they could do was drawing a bunch of boxes and talking about strategies or requirements. They may tell you that a recommender pipeline will have retrieval, ranking, and reranking, and even throw around a few model names. But when you ask them any specifics about the landscape, the model architecture, the selection of specific technologies (especially how the selected tech works), they would get stuck. And they certainly can't implement any of the said components.
Note this is not a criticism but a lament. I certainly face the same dilemma, and frequently question how I can continue to be more valuable as I grow in my career, especially given that that I don't plan to say within the same company forever and I don't want to be a professional box drawer for life. The only path I can think of now is to become someone like a great CS professor: the professor does not necessarily write all the papers, but she is invaluable to her students by unblocking them when needed, by understanding new paper better than anyone, by pointing out a direction that is not so obvious to the students, and etc. That is, to be someone like Wernher von Braun or Kelly Johnson. Someone who can code out a system like ClickHouse or at least pin down exactly which data structures to use, instead of telling his team vague ideas like let's use SIMD to speed up the query. Someone who can write a working TLA+ spec to show the flaw in a design by his team instead of telling his team that they can use TLA+ to find intricate bugs. To be honest, I don't know how to become like that while keeping getting promoted to a higher-level IC, but I don't see other ways.
I find it a dilemma when it comes to driving "big project", especially in a large company. The engineers who drive such projects often behave more like product managers. They sketch out key product features, work with teams to get roadmaps out, and convince the leadership and teams to get the right resources. In addition, they will also draw a few boxes to have a so-called "architecture diagram", and hand out the actual design and implementation to lower-level engineers. I don't deny the importance of such work, and I do recognize that junior engineers likely won't have the clout or the knowledge to push such project forward. On the other hand, I find the value of such high-level engineers diminish fast in the industry, especially when they want to switch jobs, for the will have lost the ability to get down to specifics to solve tough technical problems. Case in point, I have seen most of the so-called "uber TL" fail interviews because all they could do was drawing a bunch of boxes and talking about strategies or requirements. They may tell you that a recommender pipeline will have retrieval, ranking, and reranking, and even throw around a few model names. But when you ask them any specifics about the landscape, the model architecture, the selection of specific technologies (especially how the selected tech works), they would get stuck. And they certainly can't implement any of the said components.
Note this is not a criticism but a lament. I certainly face the same dilemma, and frequently question how I can continue to be more valuable as I grow in my career, especially given that that I don't plan to say within the same company forever and I don't want to be a professional box drawer for life. The only path I can think of now is to become someone like a great CS professor: the professor does not necessarily write all the papers, but she is invaluable to her students by unblocking them when needed, by understanding new paper better than anyone, by pointing out a direction that is not so obvious to the students, and etc. That is, to be someone like Wernher von Braun or Kelly Johnson. Someone who can code out a system like ClickHouse or at least pin down exactly which data structures to use, instead of telling his team vague ideas like let's use SIMD to speed up the query. Someone who can write a working TLA+ spec to show the flaw in a design by his team instead of telling his team that they can use TLA+ to find intricate bugs. To be honest, I don't know how to become like that while keeping getting promoted to a higher-level IC, but I don't see other ways.
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.
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.
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 denial by some of the existence of 10x engineers is one of the ongoing baffling mysteries to me.
One explanation of the denial of the existence of 10x developpers I find interesting, but can't remember where I read/heard from, is related to the stakhanovite movement [0].
Basically it's in the 30's in Russia, where a coal miner, Alexei Stakhanov, had a mythic productivity and inspired people to reach that said mythic productivity, as an example. While Stakhanov really existed, it's not factually established that he managed to produce what is claimed.
Same goes for 10x developpers. Is there at least a name for some of them and a concrete example of what they managed to produce ?
That is, I believe, a fairly good explanation.
[0] : https://en.m.wikipedia.org/wiki/Stakhanovite_movement
Basically it's in the 30's in Russia, where a coal miner, Alexei Stakhanov, had a mythic productivity and inspired people to reach that said mythic productivity, as an example. While Stakhanov really existed, it's not factually established that he managed to produce what is claimed.
Same goes for 10x developpers. Is there at least a name for some of them and a concrete example of what they managed to produce ?
That is, I believe, a fairly good explanation.
[0] : https://en.m.wikipedia.org/wiki/Stakhanovite_movement
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?
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 "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.
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.
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.
I group the skepticism that I see around this topic into two buckets.
One is "it's not 10x, but is maybe 4 or 5x"; the other is "if differences exist at all, it's definitely less than 2x".
I get/have sympathy and agreement for the first type on a technically-precise level, but it also doesn't really change any of my behavior as a technologist or people/org leader.
The second type of skepticism I just don't understand at all from people who have worked more than a couple years in industry.
One is "it's not 10x, but is maybe 4 or 5x"; the other is "if differences exist at all, it's definitely less than 2x".
I get/have sympathy and agreement for the first type on a technically-precise level, but it also doesn't really change any of my behavior as a technologist or people/org leader.
The second type of skepticism I just don't understand at all from people who have worked more than a couple years in industry.
> The reality is that the study was looking at the difference best and worst performers, not best vs average
This is a myth, the worst performers didn't complete the task or delivered a faulty solution, those were removed from the study so you didn't see the worst.
Best to worst would be much much larger than 10x, however finding anything larger than 10x would take a very long time as it means waiting around for the slowest to finish.
Edit: And if you add back all of those worst performers, best vs average would also shift significantly towars 10x.
This is a myth, the worst performers didn't complete the task or delivered a faulty solution, those were removed from the study so you didn't see the worst.
Best to worst would be much much larger than 10x, however finding anything larger than 10x would take a very long time as it means waiting around for the slowest to finish.
Edit: And if you add back all of those worst performers, best vs average would also shift significantly towars 10x.
It's completely opposite to the idea that a person's success in today's capitalism is only luck.
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.
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.
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.
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 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.
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.
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.
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.
But nowadays "10x" just goes into the same pile I throw "agile" and other meaningless terms.
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.
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.
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 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.
> 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...
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'?
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'?
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.
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.
[deleted]
Good leetcoder is good engineerer
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 ;)