Busting the 10x software engineer myth
251–260 of 356 posts
Re: Busting the 10x software engineer myth
#252Earlier quoted context omitted.
If you measure his impact in turns of extra CO2 emitted you might take a different view.
Isn't that true for any trillion dollar industry? Industries use energy whether you like it or not, and it's unfair to make such a big deal from one just because it's adopted in a different pattern than others. Agriculture, mining, electricity, transportation, defence...all have CO2 emissions, and it's extremely hard to get rid of it.
Re: Busting the 10x software engineer myth
#253Software engineers that create negative value exist, so it shouldn’t be controversial that there are developers that go the other direction.
Re: Busting the 10x software engineer myth
#254Re: Busting the 10x software engineer myth
#255Re: Busting the 10x software engineer myth
#256As I get older, and maybe because I worked at a company whose product is “talent optimization”, I think a lot of the “10x” thing is just a function engagement and passion. That is to say it’s not entirely skill or “intelligence”. You could take the best programmer but if you point them at a project they don’t give a crap about they’ll phone it in. Point them at something they’re passionate about and they’ll have absu…
And then return to 10x when transferred back to projects they enjoyed.
Re: Busting the 10x software engineer myth
#257This is a silly comparison. The engineers I've worked with in my career that stand out don't stand out because they can write for-loops faster than others or public-class-Foo-public-static-void-main-string-args-System.out.println-hello faster than others. They are much more productive because they are better at ensuring they understand the problems they're trying to solve, and solving the problem with the least amount of superfluous work.
> No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts.
This example seems like a counter-example to me. It's important to separate out one's (potentially flawed) judgement vs the actual value an engineer brings. This engineer made everyone else less productive. Simply calling someone a "10x engineer" does not make it so.
> The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers.
The rest of the article is a distraction from this generally good piece of advice. For many things, finding a competent programmer familiar with your tools and stack who can write the CRUD operations you need should be acceptable. A lot of software engineering interviewing distracts from this, with gotcha trivia questions about whether one can recite from memory algorithms from a text book that are not relevant to the work.
Re: Busting the 10x software engineer myth
#258Earlier quoted context omitted.
I guess this all depends on your definition of 10x. It sounds like you are saying 10x the average person rather than 10x the average person who works in that field. I'm a 10x developer if we count non developers. I am not if we could people who work as developers. Likewise there are expert marathon runners who are 10X, or more, than the average human. But there are not marathon runners who run 10x faster than other p…
Claude Shannon, Dennis Ritchie, Vitalik Buterin, Jeff Dean are all 10x programmers. Let's not pretend they dont exist
I think there are two kinds of companies that make tech:
1. Companies where all of the technical problems they need to solve can be solved by typical engineers.
2. Companies where some of the technical problems they need to solve are too difficult to be solved by typical engineers.
In the latter case you do need "special" engineers and you need to point them at these problems. But what percentage of companies fall into category #2?
Re: Busting the 10x software engineer myth
#259I see a variation on this article, several times a year. I can't speak for other cultures, but the US has a fundamental mindset that all but worships "exceptionalism." We like mavericks, rule-benders, and exceptionally talented individuals. Being attractive, and having a winning [public] persona is also very helpful. Sometimes, good actors can use attractiveness and persona to cover up for a lack of accomplishment an…
This is, at best, half true. The high performers might get the most attention from certain teachers (esp. in middle class and upper middle class schools), but systemically they are ignored.
1. The general idea in education circles is that the higher performers “will do fine” without any additional attention, so they don’t need much help. As such, very little research attention is focused on them.
2. Gifted education is a joke in the US. Almost completely ignored.
3. Most honors classes are also a joke in that they are often regular classes with more busy work.
4. AP classes are sometimes good, but it’s often easier just to take an actual college course if your school allows it. Same or less classroom time and much less busy work.
5. School administrators are evaluated based on performance metrics. In almost all cases it is more beneficial and often easier to improve the low performers than it is to improve the high performers. This is largely due to the metrics that have been chosen for evaluation.
As for Japan, that observation is very true. That said, most of the talent mismatches disappear starting at high school and sometimes junior high school due to tracking (of which I am a fan).
Re: Busting the 10x software engineer myth
#260Out of the 50 ish devs I've worked with closely, I've seen two I would say are in the '10x' camp. They were relentless in writing solid, simple, bug-free code, and doing so faster than everyone else. They were also effective in communicating their work. i.e. They weren't head-down in the corner savants. Their productivity was also significantly more consistent across a range of areas and task complexity, compared wit…
Also thinking in factors may not be the right approach here. We should look at it in a more binary way: Can a developer achieve the requirements or not? In most cases the magnitude of skill shows in what a developer can solve at all, not how fast he/she can solve it.