13 ms·

10x engineers take long naps

85 points by geekuillaume 9y ago

dfsegoat 9y ago
Sorry, I read over the piece and have zero idea what 'naps' have to do with this - it's only mentioned in the title and once in the conclusion. Really hard to figure out what the take home of this article is - I was hoping it tied sleep cycles into performance or something like that.
- pawadu 9y ago
  Read again, its in the first section: "... feel like I’ve never been as productive an engineer as today; and yet, I notice that I’ve never worked less hours in a given week"
  - eberkund 9y ago
    > Getting back to the title: do all 10x developers really take long naps? No, no, they don’t all do that.
- thehardsphere 9y ago
  It's really incoherent. I think the point was to talk about the subjective perception of your personal productivity but the text is really just a jumble of too many different thoughts at once.
- traviswingo 9y ago
  It's a metaphor...the authors' point is that hour in do not equate to value out. An engineer can develop a solution worth tens of thousands of dollars to a company in just a day, by merely automating tedious tasks. This is more of a thought piece than anything.
j45 9y ago
10x doesn't have to mean producing 10x more code - just 10x more effective than the average developer. In my experience, clever (usually simple) architecture in solving a problem will always beat clever code, and volumes of code.
- thehardsphere 9y ago
  10x is 10x the least skilled developer who is still employed, not 10x the average (median) developer.
  - pawadu 9y ago
    You obviously haven't met the 0.1x developer ... ... or the infamous -10x developer. Count your blessings.
    - thehardsphere 9y ago
      I actually read some of the research that produced the 10x number. The 0.1x developer, if they're actually competent enough to remain employed for more than a probationary period, probably isn't at 0.1x; you're probably underrating them because you're better than average and are thus overrating what average is. (This is part of the Dunning-Kruger effect). -10x developers should be fired fairly quickly if they're actually that negative and the business is being managed competently. I've worked with a few; they were fired within months or weeks.
      - whatnotests 9y ago
        I've always considered the Dunning-Kruger effect from the perspective of "too dumb to know I'm dumb" not "too smart to know I'm smart". Interesting to think it goes in both directions!
        tdeck 9y ago
        It's a common misconception that the Dunning-Kruger effect is just about dumb people not knowing they're dumb. In fact, it's about something we all do - overestimating our knowledge and competence in areas where we have little of both. It's worth recognizing the distinction because everyone is subject to the Dunning-Kruger effect when we're out of our depth in some area and there are a lot of "unknown unknowns".
        9y ago
liveoneggs 9y ago
maybe better: https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc (Rich Hickey Hammock Driven Development)
anythingbot 9y ago
the 10x engineer concept is really dehumanizing
jpzisme 9y ago
This might be off, but have previously interpreted the term 10x engineer as someone who is a 10x multiplier to the team and brings the collective level of the group up by ~10x. To me, that especially doesn't correlate with cranking out 10x more code or working 10x more hours.
- apropos 9y ago
  You aren't off at all. The article is making the same argument that the myth of the 10x engineer is not someone who can crank out 10x more lines of code, but someone who can bring 10x (or InfinityX) business value to the company because of what they spend their time working on.
  - rudyrigot 9y ago
    Author here. +1. I didn't mention the multiplying effect of also empowering people, but we agree that the take that defines a "10x engineer" as someone who cranks 10 times more code is irrelevant, even though I have seen it used as such, a lot (mostly as a joke, I must say).
dukoid 9y ago
Two extreme cases that happened to me: - "I have to get this done today, no matter how long it will take" -> procrastinate the whole day, waste the night to do the stuff in low quality, using "it's late now" as an excuse. - "I have to leave early today" -> productive focuessed work to get some stuff done before the time runs out
- Roybot 9y ago
  Case 1 happens to me when I don't completely understand the problem so I don't know where to start. This leads me to procrastinate. I lack a sense of direction in those cases.
  - RugnirViking 9y ago
    I'll agree, but also add that taking the time to understand the problem is half of the work. If someone just said 'type this in' and gave you the code already formed, it would take a fraction of the time
slackingoff2017 9y ago
People spend far too much time ruminating about what makes an especially productive programmer. Essentially it comes down to making good choices most of the time, so basically IQ. Bad developers are bad because they do stupid things. Hallmarks are wheel reinvention, misuse or abuse of patterns, excessive abstraction or complexity, ignorance of security ramifications. You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight. Code written by good developers can be understood and read easily and often appears simple. The extreme complexity that many companies are proud of is just a sign that their developers lack the foresight to build an elegant system.
- FLUX-YOU 9y ago
  >You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight. To what level should a developer be at before joining the workforce? How do we bring all potential developers up to this level so that we can have a smarter workforce? Can you create an education system that reliably produces developers at that level? That's what interviews attempt to do, but since those vary so widely between companies (with some being done terribly), you can't get a coherent picture of what to actually learn that will serve you among the greatest number of companies. This means that, if you can't answer all three questions above, the workforce at large MUST support bad developers writing bad production code at some point in their careers because that is simply how they learn what is and isn't important to know. If we can't create this system, then we're all complaining about nothing because there's no way to avoid writing bad production code at some point in your careers. (I specifically mention production code because conceivably, you could just have them learn and write code in a dev environment, then have that code reviewed, but never let them have much of a business impact. Most of us don't care much if someone is writing bad code in a dev environment because that's meant to break occasionally)
  - twobyfour 9y ago
    >>You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight. > To what level should a developer be at before joining the workforce? > How do we bring all potential developers up to this level so that we can have a smarter workforce? > Can you create an education system that reliably produces developers at that level? The solution is really to give junior developers a level of responsibility (and feedback) that matches their level of experience. Juniors shouldn't be making architectural level decisions or even major design decisions, nor should they be deciding _what_ to build. They should be receiving feedback on the small-scale design decisions they do make, and exposed to the senior devs' decision-making processes so they can develop that level of knowledge. And their responsibilities and exposure to business goals and impact metrics should be gradually increased as they gain the experience to be able to make larger and higher-level decisions.
baydobah 9y ago
"I can tell you of a few engineers currently working on technical problems that offer zero promise to add any business value to their companies, just for the sake of the technical problem being interesting and challenging, the engineer being too inexperienced or not value-driven enough to realize why it’s misguided, and their leadership being too little technical to understand that this work should probably be reprioritized." I think the author works on my team. Since starting my current gig I've built several functioning prototypes at work that have business value. After about 1.5 years I was given lead on a project that just shipped to production, which serves a business need. I don't really consider myself a 10x programmer, but I create useful stuff. The lead developer on our team has been spinning wheels on a project whose result is supposed to be useful. The problem is he doesn't have the proper technical knowledge, and our manager is even less technically inclined than him. He simply smiles and nods whenever the lead spews jargon at him. This project has been going on several years without tangible results. It blows my mind. My issue isn't that his project is useless, it's that our manager strongly urges me to follow his advice. I can't follow the advice of any engineer, lead or otherwise, whom I've never seen ship a system. Period. So I just do what any good engineer does - whatever I think is best for the company. Edit: The sad part is I'm only working 20 hours a week on average. When I work from home I do take naps right after lunch; usually for about 2 hours. I could actually take on a second job and still be sane. It's quite dumbfounding to see what passes for "productivity" in corporate America.
- rudyrigot 9y ago
  Author here. Fortunately, none of the engineers I was referring to are on my team. ;) Still though, I believe you're looking at this right, and by worrying about that, I believe it shows that you are part of the solution rather than the problem. I was working for an employer that was grossly under-using me in the past, and just like you, it felt so useless I had the feeling I could work another similar job simultaneously (I got involved with a lot of non-work-related stuff at the time). I couldn't leave because of visa ties; but as soon as I could, I did, and the growth of my career could finally resume. I consider that year to have been a temporary pause on my career progress, I'm glad it could be that temporary. I know there are many good reasons to stay in a non-perfect job; but are you considering that your knack for doing the most useful thing for your employer could be better valued by another one?
buzzybee 9y ago
I'm seeing it as a feedback loop problem, again. Managers and stakeholders have an easy time remarking on surfaced progress. The developer has to think and communicate everything else. Going purely hands-off doesn't work, because then the developer will tend to wander towards working on the wrong problems and get mired in them. Neither does chaining them down to a deadline, since that creates rushed, ill-considered work. So the people who are perceptually 10x tend to have hit on a strategy that keeps them in the feedback zone without being overly concerned about surfacing everything right this second, and have management that cooperate with their strategy.
- rudyrigot 9y ago
  Author here. I agree that being able to produce advanced value is also a factor of the work environment; and not only the engineer's ability to be in touch with it, but also the environment's ability to keep the engineer in touch when they should be. I didn't think of it, but I think it's a great point.

85 points by geekuillaume 9y ago

Sorry, I read over the piece and have zero idea what 'naps' have to do with this - it's only mentioned in the title and once in the conclusion. Really hard to figure out what the take home of this article is - I was hoping it tied sleep cycles into performance or something like that.

pawadu 9y ago
Read again, its in the first section: "... feel like I’ve never been as productive an engineer as today; and yet, I notice that I’ve never worked less hours in a given week"
- eberkund 9y ago
  > Getting back to the title: do all 10x developers really take long naps? No, no, they don’t all do that.
thehardsphere 9y ago
It's really incoherent. I think the point was to talk about the subjective perception of your personal productivity but the text is really just a jumble of too many different thoughts at once.
traviswingo 9y ago
It's a metaphor...the authors' point is that hour in do not equate to value out. An engineer can develop a solution worth tens of thousands of dollars to a company in just a day, by merely automating tedious tasks. This is more of a thought piece than anything.

j45 9y ago

10x doesn't have to mean producing 10x more code - just 10x more effective than the average developer. In my experience, clever (usually simple) architecture in solving a problem will always beat clever code, and volumes of code.

thehardsphere 9y ago
10x is 10x the least skilled developer who is still employed, not 10x the average (median) developer.
- pawadu 9y ago
  You obviously haven't met the 0.1x developer ... ... or the infamous -10x developer. Count your blessings.
  - thehardsphere 9y ago
    I actually read some of the research that produced the 10x number. The 0.1x developer, if they're actually competent enough to remain employed for more than a probationary period, probably isn't at 0.1x; you're probably underrating them because you're better than average and are thus overrating what average is. (This is part of the Dunning-Kruger effect). -10x developers should be fired fairly quickly if they're actually that negative and the business is being managed competently. I've worked with a few; they were fired within months or weeks.
    - whatnotests 9y ago
      I've always considered the Dunning-Kruger effect from the perspective of "too dumb to know I'm dumb" not "too smart to know I'm smart". Interesting to think it goes in both directions!
      - tdeck 9y ago
        It's a common misconception that the Dunning-Kruger effect is just about dumb people not knowing they're dumb. In fact, it's about something we all do - overestimating our knowledge and competence in areas where we have little of both. It's worth recognizing the distinction because everyone is subject to the Dunning-Kruger effect when we're out of our depth in some area and there are a lot of "unknown unknowns".
      - 9y ago

liveoneggs 9y ago

maybe better: https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc (Rich Hickey Hammock Driven Development)

anythingbot 9y ago

the 10x engineer concept is really dehumanizing

jpzisme 9y ago

This might be off, but have previously interpreted the term 10x engineer as someone who is a 10x multiplier to the team and brings the collective level of the group up by ~10x. To me, that especially doesn't correlate with cranking out 10x more code or working 10x more hours.

apropos 9y ago
You aren't off at all. The article is making the same argument that the myth of the 10x engineer is not someone who can crank out 10x more lines of code, but someone who can bring 10x (or InfinityX) business value to the company because of what they spend their time working on.
- rudyrigot 9y ago
  Author here. +1. I didn't mention the multiplying effect of also empowering people, but we agree that the take that defines a "10x engineer" as someone who cranks 10 times more code is irrelevant, even though I have seen it used as such, a lot (mostly as a joke, I must say).

dukoid 9y ago

Two extreme cases that happened to me: - "I have to get this done today, no matter how long it will take" -> procrastinate the whole day, waste the night to do the stuff in low quality, using "it's late now" as an excuse. - "I have to leave early today" -> productive focuessed work to get some stuff done before the time runs out

Roybot 9y ago
Case 1 happens to me when I don't completely understand the problem so I don't know where to start. This leads me to procrastinate. I lack a sense of direction in those cases.
- RugnirViking 9y ago
  I'll agree, but also add that taking the time to understand the problem is half of the work. If someone just said 'type this in' and gave you the code already formed, it would take a fraction of the time

slackingoff2017 9y ago

People spend far too much time ruminating about what makes an especially productive programmer. Essentially it comes down to making good choices most of the time, so basically IQ. Bad developers are bad because they do stupid things. Hallmarks are wheel reinvention, misuse or abuse of patterns, excessive abstraction or complexity, ignorance of security ramifications. You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight. Code written by good developers can be understood and read easily and often appears simple. The extreme complexity that many companies are proud of is just a sign that their developers lack the foresight to build an elegant system.

FLUX-YOU 9y ago
>You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight. To what level should a developer be at before joining the workforce? How do we bring all potential developers up to this level so that we can have a smarter workforce? Can you create an education system that reliably produces developers at that level? That's what interviews attempt to do, but since those vary so widely between companies (with some being done terribly), you can't get a coherent picture of what to actually learn that will serve you among the greatest number of companies. This means that, if you can't answer all three questions above, the workforce at large MUST support bad developers writing bad production code at some point in their careers because that is simply how they learn what is and isn't important to know. If we can't create this system, then we're all complaining about nothing because there's no way to avoid writing bad production code at some point in your careers. (I specifically mention production code because conceivably, you could just have them learn and write code in a dev environment, then have that code reviewed, but never let them have much of a business impact. Most of us don't care much if someone is writing bad code in a dev environment because that's meant to break occasionally)
- twobyfour 9y ago
  >>You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight. > To what level should a developer be at before joining the workforce? > How do we bring all potential developers up to this level so that we can have a smarter workforce? > Can you create an education system that reliably produces developers at that level? The solution is really to give junior developers a level of responsibility (and feedback) that matches their level of experience. Juniors shouldn't be making architectural level decisions or even major design decisions, nor should they be deciding _what_ to build. They should be receiving feedback on the small-scale design decisions they do make, and exposed to the senior devs' decision-making processes so they can develop that level of knowledge. And their responsibilities and exposure to business goals and impact metrics should be gradually increased as they gain the experience to be able to make larger and higher-level decisions.

baydobah 9y ago

"I can tell you of a few engineers currently working on technical problems that offer zero promise to add any business value to their companies, just for the sake of the technical problem being interesting and challenging, the engineer being too inexperienced or not value-driven enough to realize why it’s misguided, and their leadership being too little technical to understand that this work should probably be reprioritized." I think the author works on my team. Since starting my current gig I've built several functioning prototypes at work that have business value. After about 1.5 years I was given lead on a project that just shipped to production, which serves a business need. I don't really consider myself a 10x programmer, but I create useful stuff. The lead developer on our team has been spinning wheels on a project whose result is supposed to be useful. The problem is he doesn't have the proper technical knowledge, and our manager is even less technically inclined than him. He simply smiles and nods whenever the lead spews jargon at him. This project has been going on several years without tangible results. It blows my mind. My issue isn't that his project is useless, it's that our manager strongly urges me to follow his advice. I can't follow the advice of any engineer, lead or otherwise, whom I've never seen ship a system. Period. So I just do what any good engineer does - whatever I think is best for the company. Edit: The sad part is I'm only working 20 hours a week on average. When I work from home I do take naps right after lunch; usually for about 2 hours. I could actually take on a second job and still be sane. It's quite dumbfounding to see what passes for "productivity" in corporate America.

rudyrigot 9y ago
Author here. Fortunately, none of the engineers I was referring to are on my team. ;) Still though, I believe you're looking at this right, and by worrying about that, I believe it shows that you are part of the solution rather than the problem. I was working for an employer that was grossly under-using me in the past, and just like you, it felt so useless I had the feeling I could work another similar job simultaneously (I got involved with a lot of non-work-related stuff at the time). I couldn't leave because of visa ties; but as soon as I could, I did, and the growth of my career could finally resume. I consider that year to have been a temporary pause on my career progress, I'm glad it could be that temporary. I know there are many good reasons to stay in a non-perfect job; but are you considering that your knack for doing the most useful thing for your employer could be better valued by another one?

buzzybee 9y ago

I'm seeing it as a feedback loop problem, again. Managers and stakeholders have an easy time remarking on surfaced progress. The developer has to think and communicate everything else. Going purely hands-off doesn't work, because then the developer will tend to wander towards working on the wrong problems and get mired in them. Neither does chaining them down to a deadline, since that creates rushed, ill-considered work. So the people who are perceptually 10x tend to have hit on a strategy that keeps them in the feedback zone without being overly concerned about surfacing everything right this second, and have management that cooperate with their strategy.

rudyrigot 9y ago
Author here. I agree that being able to produce advanced value is also a factor of the work environment; and not only the engineer's ability to be in touch with it, but also the environment's ability to keep the engineer in touch when they should be. I didn't think of it, but I think it's a great point.