11 ms·

If the 10x and gatekeeping people want to give us methods for getting to 10x productivity/skill, I'm all for it. But articles and threads like these always fail

If the 10x and gatekeeping people want to give us methods for getting to 10x productivity/skill, I'm all for it. But articles and threads like these always fail to give up a method of reliably training that quality and accurately testing for it. Until I can hold up a plaque where humanity agrees that I'm a proven 1x, 5x, or 10x engineer and I deserve money and a job according to each of those levels, it's all just posturing and debate.

adam_arthur 6y ago
Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive. The traits I see in engineers who I consider to be 10x: Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach. Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is. Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct. Objectivity. Always quantify objectively to yourself why you made a given design decision, why did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points? Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example. Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet. Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution. Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course. Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue. It's not about specific knowledge at all, or training. People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.
- fctorial 6y ago
  > These people legit code 8-10 hours a day straight. That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js). Can you do creative work for 10 hours in a stretch, every day.
  - adam_arthur 6y ago
    I did this myself for many years in a startup :) Averaging around 350k lines of code a year for a few years. This was mostly frontend/product focused work, so there is more boilerplate than in other disciplines, of course. It's also important to note, the higher quality the codebase is, the less energy it takes to add to it. If you spend 50% of your time reverse engineering spaghetti code, it will be way more tiring than adding to a codebase where design is sound, code is very human readable/friendly etc. It certainly takes a lot of energy, but why do you say it's impossible?
    - fctorial 6y ago
      I can feel my IQ dropping at a steady rate when I program for long stretches of time.
      - adam_arthur 6y ago
        In my case I was working in a codebase that I largely built myself, so I understood all design decisions and code at all times. It's much easier to operate in this environment. I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments. It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.
        dmitriy_ko 6y ago
        So it was more or less a large solo project? How do you know your code base was much better than those less clean/spaghetti codebases? Your own code is obviously easier to read/understand than that of others. In general it's easier to write code than to read/understand code of others. Developers who are founding members of a codebase are able to navigate it better vs those who come later and therefore able to work much faster. It may give them a false impression that they are genius 10x coder. Then when developer who comes later is not able to be productive, founding developer would blame it on incompetence of newer developer. But it could also be that codebase is of poor quality, but as founding developer you don't see it. It's hard to be objective about your own code. Now let's go to the reverse situation when you are spending hours "tracing state through spaghetti-like code". It could in fact be that it's actually a great code written by a 10x developer, but you are not smart enough to understand how it works. It's natural to blame someone else and not you.
908B64B197 6y ago
And yet, you can make a lot of money hiring 10x.
jgwil2 6y ago
IMO being "10x" or whatever is not really about productivity or skill, or rather, those are necessary but not sufficient. What it really comes down to is doing the work that makes other developers more productive. In other words, the 10x developer doesn't output ten times as many lines of code or complete ten times as many stories. They simply make everyone else's life a little easier by identifying and working on the important stuff.

adam_arthur 6y ago

Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive. The traits I see in engineers who I consider to be 10x: Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach. Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is. Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct. Objectivity. Always quantify objectively to yourself why you made a given design decision, why did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points? Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example. Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet. Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution. Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course. Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue. It's not about specific knowledge at all, or training. People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.

fctorial 6y ago
> These people legit code 8-10 hours a day straight. That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js). Can you do creative work for 10 hours in a stretch, every day.
- adam_arthur 6y ago
  I did this myself for many years in a startup :) Averaging around 350k lines of code a year for a few years. This was mostly frontend/product focused work, so there is more boilerplate than in other disciplines, of course. It's also important to note, the higher quality the codebase is, the less energy it takes to add to it. If you spend 50% of your time reverse engineering spaghetti code, it will be way more tiring than adding to a codebase where design is sound, code is very human readable/friendly etc. It certainly takes a lot of energy, but why do you say it's impossible?
  - fctorial 6y ago
    I can feel my IQ dropping at a steady rate when I program for long stretches of time.
    - adam_arthur 6y ago
      In my case I was working in a codebase that I largely built myself, so I understood all design decisions and code at all times. It's much easier to operate in this environment. I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments. It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.
      - dmitriy_ko 6y ago
        So it was more or less a large solo project? How do you know your code base was much better than those less clean/spaghetti codebases? Your own code is obviously easier to read/understand than that of others. In general it's easier to write code than to read/understand code of others. Developers who are founding members of a codebase are able to navigate it better vs those who come later and therefore able to work much faster. It may give them a false impression that they are genius 10x coder. Then when developer who comes later is not able to be productive, founding developer would blame it on incompetence of newer developer. But it could also be that codebase is of poor quality, but as founding developer you don't see it. It's hard to be objective about your own code. Now let's go to the reverse situation when you are spending hours "tracing state through spaghetti-like code". It could in fact be that it's actually a great code written by a 10x developer, but you are not smart enough to understand how it works. It's natural to blame someone else and not you.

908B64B197 6y ago

And yet, you can make a lot of money hiring 10x.

jgwil2 6y ago

IMO being "10x" or whatever is not really about productivity or skill, or rather, those are necessary but not sufficient. What it really comes down to is doing the work that makes other developers more productive. In other words, the 10x developer doesn't output ten times as many lines of code or complete ten times as many stories. They simply make everyone else's life a little easier by identifying and working on the important stuff.