[deleted]
10x (engineer, context) pairs
121–130 of 132 posts
Re: 10x (engineer, context) pairs
#122What makes an engineer 10x is if he does shit or he talks on the internet about the absence of 10x engineers.
Re: 10x (engineer, context) pairs
#123I contend that the only reason their existence is debated or controversial, is because the concept hurts the pride of those who like to think of themselves as best-of-the-best engineers, but are afraid they're really not. I've worked with 10x engineers maybe 2-3 times in 20 years. One single-handedly wrote 85% of and another wrote most of the internal libraries at . They would regularly take tasks that most people wo…
> One single-handedly wrote 85% of and another wrote most of the internal libraries at .
There is a trap here, though. There is another group of engineers, who jump on any greenfield project before everyone else manages to discuss the plan and then they write some code very quickly, showing you a "finished" solution. Those people often appear 10x to management as well. However, after deploying their code to production, it turns out it has many issues and is a source of never ending frustration for the people who maintain it. Unfortunately at that time the "super hero" has moved to a new greenfield project, and is not willing to fix their bugs or help because they are "busy" or "in a flow".
I don't think those people are really 10x. They are often an annoyance to the rest of the team and if the management doesnt break this pattern early, you end up with a team where one person codes 90% of stuff, gets most of the credit, but 10 other people get frustrated maintaining it, and overall the team pace is not 10x higher, but may be even slower than a similarly sized group of average devs.
So if you are in a management position, don't just look at how much code a person writes in a short time or what percentage of the product they created, but also look at the quality of their work and how good they are at sharing their knowledge with the rest of the team.
Having said that, I have met some true 10xers who created high quality stuff fast and were very helpful to their teammates, but they are quite rare and often don't get all the praise they deserve, particularly in environments valuing the "ship fast and break things" strategy.
Re: 10x (engineer, context) pairs
#124I know an objectively-measured 500x engineer.
On a 6-month crash project with 1000 engineers assigned, at the end, fully half the code delivered was his. You can't get any more objective than that.
To be clear: this was a project where, if not delivered on the 6-month mark, the company would not be paid. It is hard to see how, without his work, the project could have delivered on time.
I have worked with a few others of similar ability. I have never had a bad experience with one.
Re: 10x (engineer, context) pairs
#125Yeah, there are plenty of fake 10x engineers out there, or temporary 10x-ers who are only doing well because of their working environment. But I have worked with a few people who were clear 10x engineers. Everything they worked on they did better and faster and cleaner. They could often solve problems that other skilled people couldn't even get started on. Yes, they usually picked important and impactful things to wo…
Some people are just smarter than others - much smarter. These engineers have their brains wired differently, helping them be more suited to programming/design work. If we accept the existence of 10x chess players (state champions) and 1000x chess players (grandmasters), why not 10x engineers? I personally worked with (and managed) amazing engineers that are AT LEAST 10x more productive than the worst AND average eng…
[deleted]
Re: 10x (engineer, context) pairs
#126Re: 10x (engineer, context) pairs
#127I contend that the only reason their existence is debated or controversial, is because the concept hurts the pride of those who like to think of themselves as best-of-the-best engineers, but are afraid they're really not. I've worked with 10x engineers maybe 2-3 times in 20 years. One single-handedly wrote 85% of and another wrote most of the internal libraries at . They would regularly take tasks that most people wo…
> One single-handedly wrote 85% of and another wrote most of the internal libraries at . There is a trap here, though. There is another group of engineers, who jump on any greenfield project before everyone else manages to discuss the plan and then they write some code very quickly, showing you a "finished" solution. Those people often appear 10x to management as well. However, after deploying their code to productio…
Engineers often overestimate how bad the “greenfielder” is for the business. In most cases you aren’t selling an elegant technical solution, you’re just selling a solution. And if you don’t ship it ASAP you won’t have time to worry about maintainability, you’ll be bankrupt.
For most businesses, a greenfielder is a 10x engineer.
(This is just an aside, I agree that there exist “true” 10x-ers having had the joy of working with 2 of them over the last 20 years).
Re: 10x (engineer, context) pairs
#128Earlier quoted context omitted.
> One single-handedly wrote 85% of and another wrote most of the internal libraries at . There is a trap here, though. There is another group of engineers, who jump on any greenfield project before everyone else manages to discuss the plan and then they write some code very quickly, showing you a "finished" solution. Those people often appear 10x to management as well. However, after deploying their code to productio…
Engineers often overestimate how bad the “greenfielder” is for the business. In most cases you aren’t selling an elegant technical solution, you’re just selling a solution . And if you don’t ship it ASAP you won’t have time to worry about maintainability, you’ll be bankrupt. For most businesses, a greenfielder is a 10x engineer. (This is just an aside, I agree that there exist “true” 10x-ers having had the joy of wor…
I didn't mean just inelegant code, but buggy, incorrect, incomprehensible code that does not meet business requirements and, after being demoed internally to management and getting all the praise, requires significantly more work to get to production level quality.
Anybody can be a 10x if they don't have to solve the problem correctly.
Also, pushing a very low quality product to production too early might just as well kill the company as pushing a great product too late. History knows plenty of late comers who won the market.
A programmer comes to an interview.
- What are your strengths?
- I'm fast at maths.
- Cool, how much is 1563 * 74?
- 66689
- That's not even close to correct!
- But it was fast.
Re: 10x (engineer, context) pairs
#129I know an objectively-measured 500x engineer. On a 6-month crash project with 1000 engineers assigned, at the end, fully half the code delivered was his. You can't get any more objective than that. To be clear: this was a project where, if not delivered on the 6-month mark, the company would not be paid. It is hard to see how, without his work, the project could have delivered on time. I have worked with a few others…
It may be that this developer really did single-handedly save the day, but:
> half the code delivered was his. You can't get any more objective than that.
Counting lines of code is a famously ineffective way to measure productivity. It encourages low-density code style, and encourages working on easy development tasks. It also encourages prioritising velocity over quality, although in many contexts that may be what you want.
Re: 10x (engineer, context) pairs
#130I know an objectively-measured 500x engineer. On a 6-month crash project with 1000 engineers assigned, at the end, fully half the code delivered was his. You can't get any more objective than that. To be clear: this was a project where, if not delivered on the 6-month mark, the company would not be paid. It is hard to see how, without his work, the project could have delivered on time. I have worked with a few others…
It may be that this developer really did single-handedly save the day, but: > half the code delivered was his. You can't get any more objective than that. Counting lines of code is a famously ineffective way to measure productivity. It encourages low-density code style, and encourages working on easy development tasks. It also encourages prioritising velocity over quality, although in many contexts that may be what y…
It can be quite effective after the fact. Our 500x engineer had no reason to pad, and every reason to avoid wasting time writing anything nonfunctional.
In the event, he assigned two-week tasks, and where not done on time he would do them himself over the weekend. During the two weeks, he would do up to ten such tasks, despite that he reserved the harder tasks for himself.