6 ms·

A look at the 10x paradigm

32 points by devupio 10y ago

j45 10y ago
It's less about 10x programmers and programmers that can do 10x architecture. Clever and elegant architecture will always beat clever programming. It's almost always a large part of how "10x programmers" achieve so much. 10x effectiveness comes out in different way on different projects, be it new code vs existing code, or knowing enough about the solution space vs being in an unknown world.
- maxxxxx 10y ago
  I'd say that coming up with a 10x architecture is also a matter of luck. Sometimes your architecture pans out, sometimes it doesn't. It's hard to anticipate future requirements. Where good people win is that they adapt quickly when there are signs that the design doesn't work. A lot of people just "stick to the plan" although everybody knows that it won't work.
  - gnaritas 10y ago
    > It's hard to anticipate future requirements. It's not about that, it's about keeping what you do nimble enough to always be ready for change when it comes. That means not having duplication in the system, having things well factored and encapsulated so there's a distinction between the abstract and the implementation so at any time any component can be made a change point and become pluggable. What makes a good architecture good is that it can be changed without scrapping the whole thing or breaking the whole thing. > Where good people win is that they adapt quickly when there are signs that the design doesn't work. It's not that they do adapt quickly, it's that they "can". > A lot of people just "stick to the plan" although everybody knows that it won't work. Because they're stuck with a bad design that can't be changed due to issues like bad factoring, lots of code duplication and copy pasting, etc.
    - maxxxxx 10y ago
      "Because they're stuck with a bad design that can't be changed due to issues like bad factoring, lots of code duplication and copy pasting, etc." From my experience they just don't try. There are (almost) always ways to improve.
      - ktRolster 10y ago
        It really helps to look for small changes you can make to improve things.
      - gnaritas 10y ago
        Of course there are always ways to improve, but when duplication reaches a certain level, people just stop changing things because they can't keep up with the bugs it produces or the changes it forces all over the place. Anything can be fixed with enough effort, but there's a point at which it's no longer justifiable in terms of dollars to undergo that effort.
  - devishard 10y ago
    I think "anticipating future requirements" is entirely the wrong way to approach the problem. Instead, you should look at how those requirements will be produced. If your architecture "thinks" the same way as your users, it will be able to be modified easily to include more of their thinking. So instead of trying to predict future requirements, you should attempt to capture and accurately model the way your users think about the problem. Sometimes that creates designs that mathematically/algorithmically seem pretty ugly. But in the long run I'll often discover that the ugliness exists for a reason--people mostly only add complexity to their mental models because that complexity allows them to solve a problem. So even when the domain expert's thinking seems overcomplicated, it's usually actually the least complicated model that accurately represents the problem.
    - j45 10y ago
      It's a delicate, and necessary balance to pit future requirements or road mapping enough to get a sense of where the architecture could stay, or head in the next 6-18 months. Quite often in super early projects, the domain is not understood, so the architecture reflects the learning (or misguided assumptions).
    - tensor 10y ago
      This has definitely not been my experience. Users vary greatly, some like simple mental models, but some love complex mental models. You definitely shouldn't be letting your users define your product. Rather, listen to your users problems, listen to what they think a solution is, then let your design team determine if there is a better and more simple solution. Sometimes there may not be, but often there is.
      - devishard 10y ago
        Of course you shouldn't let users define your product. Nothing about what I said suggests that. When you get requirements from your users, they're going to mix in how they think about the problem with how they think that problem should be represented in the program. The problem with that is that they don't know what computers can do, so they can't possibly be expected to know how the problem should be represented in the program. And in fact, the UI, which is the only thing they ever see, will probably be more task-oriented than representation-oriented, so they probably will never see how your program actually models the problem and therefore won't be able to suggest good changes to it. Ultimately, though, there's an underlying mental model that the user is using for the task. And for most fields, there's really only one correct mental model, so I actually disagree that expert users have different mental models, at least not with significant differences.
  - j45 10y ago
    10x architecture isn't about building the entire architecture up front. It's about seeing what's possible/imaginable, and not building yourself into a corner today so it can grow and breathe. I have a few enterprise projects now over 10 years old that began as simple projects. It took having enough understanding of the domain and problem set and then anticipating what was expected to grow and change, and what did not.
    - maxxxxx 10y ago
      Did you nail all your designs from the start or did you have to adapt them to new facts?
      - j45 10y ago
        Not building one's self into a corner is one of the hardest things to avoid. No design is complete in the start. It needs to find a balance between being a foundation for exploring and developing through the problem domain, but remaining flexible. I think a lot about managing and mitigating risks through clever and simply designed architecture that can do a lot. The less there is to the design the more it can remain flexible to deal with new facts. The fine balance of over architecting/abstracting vs under abstracting/architecting is for me a matter of finding the balance between the size, impact and possible number of unknowns about what I'm trying to design when I begin vs the future. Where possible, understanding the domain before daring to design or interpret is often the most important factor. For the few large enterprise systems I've designed in unrelated fields in the past 10 years, I haven't ended up throwing away or majorly refactoring the schema or design. What did change is the stack and tools that became available and making sure I kept a laser focus on an n-tier architecture so different layers of the presentation, business logic and app logic could be swapped in and out over it's lifetime. I guess I can say comfortably that risk of designs falling apart was minimized, and luck has increased because I didn't begin without an understanding of the core principles, entities, and interactions ultimately the details and workflow the system has to manage. I can't stress the importance of keeping things as simple as possible, because complexities are guaranteed to arise in the future. To me, features, and schema changes over time can become like perpetually flying bullets. I absolutely have refactored or adjusted as I go? Sure. Does all of it get thrown away? Rarely. Have I over-architected a solution to cover my butt and the new facts never came, totally. Has a new tech, stack or library come out that made me need to replace what I had built or modified to do what I need, always. I do lots of paper models to try and see the core patterns, and what could be interpreted in a number of different ways should something grow in that direction. This type of strategy is far more difficult when working in a problem space where there is a lot of research and development. How about you? Would love to hear how you approach things that have different balances of known/unknown facts.
  - collyw 10y ago
    Its probably luck if you are relatively inexperienced. But hopefully you learn from both your mistakes and your successes and get it right more often than not as you gain more experience.
- devishard 10y ago
  Yes and no. I think that generally I'm maybe a 5x programmer when it comes to architecture. Architecture is what I'm good at. But when I come onto a team for the first time, they don't just give me the keys to the kingdom. I don't get to make large-scale architectural decisions immediately. Instead, they have me work on smaller sections of the application. And when I'm working on smaller sections, the attributes that make me good at architecture work against me. I generally work slowly, taking a step back to understand the problem from the user's perspective, and modeling that understanding in code rather than writing code that short-sightedly solves only the problem at hand. That works well for architecture, but in smaller sections it just appears slow, like I'm not producing. It does have positive effects in the long term even for small sections of code, but those benefits aren't seen until long enough later that I don't really get credit for them. The result is that I don't make a good impression at first and it takes me a long time at a new job before I'm given authority to make architectural decisions. It would be easy for me to blame other people for not seeing my "genius" here but the truth is that this is only a problem I can work on--I need the flexibility to be able to demonstrate productivity early on and make a good impression, otherwise my poor self-presentation gets in the way of me contributing to the team in the most effective way possible. So I guess what I'm saying here is, you need both. It's not enough to just have elegant architecture, you also have to have quick programming skills.
  - j45 10y ago
    I absolutely agree that you need quick programming skills, but the architecture is the magnifier and multiplier of clear programming skills. Quite often, simpler and less code makes it easier for others to participate. Joining an existing project requires a demonstrated ability to build the trust to refactor and re-architect anything over time. Otherwise patchwork works.
- gnaritas 10y ago
  > Clever and elegant architecture will always beat clever programming. And clever elegant architecture and clever programming will beat either alone. It's not an either or situation, you want them all.
  - deleted 10y ago
    [deleted]
Darmani 10y ago
There are a couple ways to be called a 10x programmer. One is by doing more, by throwing around more code and building more features. This is the kind that the article talks about. It's quite hard to maintain this kind of multiplier, no matter how much technical debt you're willing to create. I can think of one example of someone like this, and his multiplier was definitely not 10x. At the time, he was at best labelled "up-and-coming." He'd go home over the weekend and write thousands of lines of code, and then the team would come in and find everything broken. Another is by doing less, and simply being at a higher level than others. In my experience, no-one gets to 10x by just banging harder and letting other people clean up the mess. Even if you do, those aren't the people whose impact is felt for years after they leave, at least not in any positive sense. You get to 10x by being the one person who can spot the mess the rest of the team is about to create before they've written the first line. Your impact isn't felt for years by writing code: it's felt by setting the architecture, by making design decisions that constraint people into writing good code for years to come.
- ktRolster 10y ago
  In my experience, no-one gets to 10x by just banging harder and letting other people cleaning up the mess. Yeah, that's a good one. Cleaning up your messes is a way to improve your architecture skill quickly. I can give you other ideas that will quickly push you to 10x skill level: * Focus. Put away your phone, don't surf the internet at work. That alone will raise you above the crowd and let you go home early. * Fix bugs early. Don't send them out to QA, don't send them to customers. Once your bug count starts increasing, it's a death cycle that slows you down like molasses. * As soon as bugs (or problems) come in, try to think of a way to avoid that problem in the future. Over time, you'll develop habits that will serve you well.
devishard 10y ago
This article starts off with addressing how so-called-10x developers are often just building tech debt into their applications. I was with Tiwari on that. Then he moves on to creating a non-judgmental culture... not sure I agree there. And then... linters? Huh? I think that the anti-judgment folks are trying to achieve something good, but they're throwing out the baby with the bathwater. We need to make a distinction between judging behaviors and judging people. The former isn't just good, it's fundamental--the only way to improve your behaviors is to judge them. But judging people is generally pointless, at least without some sort of temporal limitation--almost everyone starts at a new job as -0.5x net contribution until they're onboarded and improves from there.
- d23 10y ago
  > This article starts off with addressing how so-called-10x developers are often just building tech debt into their applications. I was with Tiwari on that. Then he moves on to creating a non-judgmental culture... not sure I agree there. And then... linters? Huh? Thank you. Did anyone read the damn article? It's all over the place -- borderline nonsensical. I suppose it's intended to be a promotion of their company. Color me unconvinced.
x64_lol 10y ago
Where is this rush to hire 10x people taking place? I asked the last 10 recruiters who called me if they know what a 10x developer is, and they had no idea.
wvenable 10y ago
Like others here, I don't consider 10x programmers to be someone who writes 10x the amount of code. In fact, most 10x programmers actually write less code but get more done with it. Personally I think the narrative works better when you think there are 1x programmers and 0.1x programmers. And a very large number of developers are actually between 1.0 and 0.1. These 0.1x programmers somehow manage to solve problems by simply puttering away at it over time. For example, these programmers might start out reading a web service into an XML file, re-opening that XML file to process the result, copying that file someone else that is never read again, taking the result and inserting it into a database table, reading the table to create an aggregate result, and then finally inserting that result into another system. And they do this all day long every day for every problem they come across. Not everyone is quite that bad, there are 0.5x programmers who know better than that but still manage to write 6 classes to solve a problem that could be done in a single 2-screen long function. Tools and processes can help and code reviews are pretty invaluable. Any good process will have weeded out 0.1x programmers already and they will settle in those places without them.
- eecks 10y ago
  > 6 classes to solve a problem that could be done in a single 2-screen long function Isn't the former promoted as better programming? IoC, decoupling, Law of Demeter, testability etc
  - 1138 10y ago
    Promoted? Yes. Actually? No.
    - deleted 10y ago
      [deleted]
    - eecks 10y ago
      So, genuine question, why?
      - 10y ago
ktRolster 10y ago
Every study I've ever seen has found that some programmers are dramatically more productive than others (10x is a vague estimate). I don't think it's a controversial 'paradigm' at all. It also matches with the fact that skill in general is an exponential distribution, not a bell curve.
wting 10y ago
10x is a measure of impact relative to others. From that definition, I have no doubt it exists. There's a couple ways to find 10x'ers: # A person that does things no one else can. A problem requires calculating taxes for an invoice. Someone who computes this programmatically is better than a person who hand calculates everything. A problem requires calculating the area under the curve. Someone who uses calculus is better than someone who only knows algebra and geometry. A problem requires charging a user's credit card once on checkout. Someone who understands idempotent operations is infinitely better. (I was charged 3 times for a single purchase yesterday, and now disputing with the merchant.) # A person that grows the people around them. A person growing teammates to 2x or 3x their previously level has a cumulative 10x impact. This can be teaching how to approach problems, choose the right abstractions, make engineering tradeoffs, manage risk, write robust code that is easily testable, etc. # A person that makes others more efficient. If the average dev waits 1 hr for a build, and someone reduces that to 5 minutes then they have saved: x devs * y builds / day * 55 min This has indirect effects such as maintaining flow state, minimizing context switching, etc. # A person that brings down the teammates. A dev that builds fast enough (5x), but grows tech debt such that the rest of the team operates at 0.5x. By definition they are a 10x relative to their teammates. :P
deleted 10y ago
[deleted]
leovonl 10y ago
Fact: everybody wants a 10x programmer but nobody wants to be a 10x manager. Also, dealing with a skilled programmer is not just a matter of top-down policy: a 10x programmer may have a different opinion about tools and processes and will not be happy on simply conforming - as opposed to the programmer who doesn't know better.
- ktRolster 10y ago
  >but nobody wants to be a 10x manager. How would one go about becoming a 10x manager? Like, what would that person accomplish?
x64_lol 10y ago
I see the point here. No matter what it's called, you're talking about people that don't use best practices, for better or worse. Best practices will get you where you're going in a predictable way, but there is a ton of inefficiency, as they don't take your specific problem into account. When I was new to moving away from best practices, I wrote a lot of difficult to understand code that was very performant. I spent my evenings reading documentation, reading the code of the people I admired (mostly decompiled framework code), and was very excited to put what I learned into practice and learn by experience. It made me proud to write code that out-performed my coworker's code by orders of magnitude. I worked for one of the top 100 most trafficked sites in the US, and on a platform that was not designed for that level of traffic (none are). A month later, the lead architect and I had a discussion that did not go my way. I was asked to write a very public and humbling apology to the team, and that apology still exists hosted on the internal network at that company (in a place that is easy to find). I had a lot of talent, but not a lot of wisdom. From that day on, I was to work on the most difficult projects exclusively, and under direct supervision of that architect. We worked on maintaining the performance edge, but doing so in a way that is easy for other developers to understand and extend. He taught me to interface directly with the other departments and senior management to make changes to the development process before work got to development; to enable us to do our best. It was a difficult road, and I was yelled at a lot; but eventually the architect cleared me to work without supervision. What followed is the most productive two years the company I worked for had ever had. I was promoted multiple times, was awarded patents, and was able to do a lot of lasting good. I had a hand in every project, feature, and department. I designed and internally evangelized a few myself, and had become the go-to guy to get difficult things done. You know this company, if I told you their name you'd recognize them and their product immediately (you've likely used my work). I left about 4 years ago to build my own company. I do consulting during the day, and take jobs that require a hero to survive (to stay sharp). Since I left, there have been no significant new features or achievements out of the company I left. Moral of the story: If you're talented, your idea of a good night is reading documentation and decompiling/memorizing products you like, and want to be a 10x developer; get someone you admire to yell at you, rip your work apart every day, and tell you that you're garbage for a year. It will do you (and your company) a lot of good.
- 10y ago
hashkb 10y ago
http://kytrinyx.com/presentations/here-be-dragons http://kytrinyx.com/presentations/here-be-dragons An excellent talk that can put this in perspective for non technical people.
blacksmythe 10y ago
Does anyone doubt that there are 2x programmers (programmers twice as effective as an average senior developer)? I have worked with a number of them. If one were to assume some sort of power law or Gaussian tail distribution, it is logical to assume that a few 10x programmers exist. However, they are going to be sufficiently rare that you are not likely to be able to find them or recruit them. A more interesting question is if there are 3-4x programmers, and if so, is it feasible to find and recruit them? I have worked with people (rarely) that I would consider 4x programmers.
BerislavLopac 10y ago
The main problem with the "10x productivity" myth is that it's not clear what is that 10x _of_. Is it the amount of functionality? Or maintainability of the code? Reusability? Performance? I've seen many developers implement some functionality in a record amount of time, but the resulting code was later discovered to be a) bug-ridden, b) difficult to maintain, c) unscalable or d) all of the above.
- mathgeek 10y ago
  > the resulting code was later discovered to be a) bug-ridden, b) difficult to maintain, c) unscalable or d) all of the above. I think this describes most code that's ever been written.

32 points by devupio 10y ago

j45 10y ago

It's less about 10x programmers and programmers that can do 10x architecture. Clever and elegant architecture will always beat clever programming. It's almost always a large part of how "10x programmers" achieve so much. 10x effectiveness comes out in different way on different projects, be it new code vs existing code, or knowing enough about the solution space vs being in an unknown world.

maxxxxx 10y ago
I'd say that coming up with a 10x architecture is also a matter of luck. Sometimes your architecture pans out, sometimes it doesn't. It's hard to anticipate future requirements. Where good people win is that they adapt quickly when there are signs that the design doesn't work. A lot of people just "stick to the plan" although everybody knows that it won't work.
- gnaritas 10y ago
  > It's hard to anticipate future requirements. It's not about that, it's about keeping what you do nimble enough to always be ready for change when it comes. That means not having duplication in the system, having things well factored and encapsulated so there's a distinction between the abstract and the implementation so at any time any component can be made a change point and become pluggable. What makes a good architecture good is that it can be changed without scrapping the whole thing or breaking the whole thing. > Where good people win is that they adapt quickly when there are signs that the design doesn't work. It's not that they do adapt quickly, it's that they "can". > A lot of people just "stick to the plan" although everybody knows that it won't work. Because they're stuck with a bad design that can't be changed due to issues like bad factoring, lots of code duplication and copy pasting, etc.
  - maxxxxx 10y ago
    "Because they're stuck with a bad design that can't be changed due to issues like bad factoring, lots of code duplication and copy pasting, etc." From my experience they just don't try. There are (almost) always ways to improve.
    - ktRolster 10y ago
      It really helps to look for small changes you can make to improve things.
    - gnaritas 10y ago
      Of course there are always ways to improve, but when duplication reaches a certain level, people just stop changing things because they can't keep up with the bugs it produces or the changes it forces all over the place. Anything can be fixed with enough effort, but there's a point at which it's no longer justifiable in terms of dollars to undergo that effort.
- devishard 10y ago
  I think "anticipating future requirements" is entirely the wrong way to approach the problem. Instead, you should look at how those requirements will be produced. If your architecture "thinks" the same way as your users, it will be able to be modified easily to include more of their thinking. So instead of trying to predict future requirements, you should attempt to capture and accurately model the way your users think about the problem. Sometimes that creates designs that mathematically/algorithmically seem pretty ugly. But in the long run I'll often discover that the ugliness exists for a reason--people mostly only add complexity to their mental models because that complexity allows them to solve a problem. So even when the domain expert's thinking seems overcomplicated, it's usually actually the least complicated model that accurately represents the problem.
  - j45 10y ago
    It's a delicate, and necessary balance to pit future requirements or road mapping enough to get a sense of where the architecture could stay, or head in the next 6-18 months. Quite often in super early projects, the domain is not understood, so the architecture reflects the learning (or misguided assumptions).
  - tensor 10y ago
    This has definitely not been my experience. Users vary greatly, some like simple mental models, but some love complex mental models. You definitely shouldn't be letting your users define your product. Rather, listen to your users problems, listen to what they think a solution is, then let your design team determine if there is a better and more simple solution. Sometimes there may not be, but often there is.
    - devishard 10y ago
      Of course you shouldn't let users define your product. Nothing about what I said suggests that. When you get requirements from your users, they're going to mix in how they think about the problem with how they think that problem should be represented in the program. The problem with that is that they don't know what computers can do, so they can't possibly be expected to know how the problem should be represented in the program. And in fact, the UI, which is the only thing they ever see, will probably be more task-oriented than representation-oriented, so they probably will never see how your program actually models the problem and therefore won't be able to suggest good changes to it. Ultimately, though, there's an underlying mental model that the user is using for the task. And for most fields, there's really only one correct mental model, so I actually disagree that expert users have different mental models, at least not with significant differences.
- j45 10y ago
  10x architecture isn't about building the entire architecture up front. It's about seeing what's possible/imaginable, and not building yourself into a corner today so it can grow and breathe. I have a few enterprise projects now over 10 years old that began as simple projects. It took having enough understanding of the domain and problem set and then anticipating what was expected to grow and change, and what did not.
  - maxxxxx 10y ago
    Did you nail all your designs from the start or did you have to adapt them to new facts?
    - j45 10y ago
      Not building one's self into a corner is one of the hardest things to avoid. No design is complete in the start. It needs to find a balance between being a foundation for exploring and developing through the problem domain, but remaining flexible. I think a lot about managing and mitigating risks through clever and simply designed architecture that can do a lot. The less there is to the design the more it can remain flexible to deal with new facts. The fine balance of over architecting/abstracting vs under abstracting/architecting is for me a matter of finding the balance between the size, impact and possible number of unknowns about what I'm trying to design when I begin vs the future. Where possible, understanding the domain before daring to design or interpret is often the most important factor. For the few large enterprise systems I've designed in unrelated fields in the past 10 years, I haven't ended up throwing away or majorly refactoring the schema or design. What did change is the stack and tools that became available and making sure I kept a laser focus on an n-tier architecture so different layers of the presentation, business logic and app logic could be swapped in and out over it's lifetime. I guess I can say comfortably that risk of designs falling apart was minimized, and luck has increased because I didn't begin without an understanding of the core principles, entities, and interactions ultimately the details and workflow the system has to manage. I can't stress the importance of keeping things as simple as possible, because complexities are guaranteed to arise in the future. To me, features, and schema changes over time can become like perpetually flying bullets. I absolutely have refactored or adjusted as I go? Sure. Does all of it get thrown away? Rarely. Have I over-architected a solution to cover my butt and the new facts never came, totally. Has a new tech, stack or library come out that made me need to replace what I had built or modified to do what I need, always. I do lots of paper models to try and see the core patterns, and what could be interpreted in a number of different ways should something grow in that direction. This type of strategy is far more difficult when working in a problem space where there is a lot of research and development. How about you? Would love to hear how you approach things that have different balances of known/unknown facts.
- collyw 10y ago
  Its probably luck if you are relatively inexperienced. But hopefully you learn from both your mistakes and your successes and get it right more often than not as you gain more experience.
devishard 10y ago
Yes and no. I think that generally I'm maybe a 5x programmer when it comes to architecture. Architecture is what I'm good at. But when I come onto a team for the first time, they don't just give me the keys to the kingdom. I don't get to make large-scale architectural decisions immediately. Instead, they have me work on smaller sections of the application. And when I'm working on smaller sections, the attributes that make me good at architecture work against me. I generally work slowly, taking a step back to understand the problem from the user's perspective, and modeling that understanding in code rather than writing code that short-sightedly solves only the problem at hand. That works well for architecture, but in smaller sections it just appears slow, like I'm not producing. It does have positive effects in the long term even for small sections of code, but those benefits aren't seen until long enough later that I don't really get credit for them. The result is that I don't make a good impression at first and it takes me a long time at a new job before I'm given authority to make architectural decisions. It would be easy for me to blame other people for not seeing my "genius" here but the truth is that this is only a problem I can work on--I need the flexibility to be able to demonstrate productivity early on and make a good impression, otherwise my poor self-presentation gets in the way of me contributing to the team in the most effective way possible. So I guess what I'm saying here is, you need both. It's not enough to just have elegant architecture, you also have to have quick programming skills.
- j45 10y ago
  I absolutely agree that you need quick programming skills, but the architecture is the magnifier and multiplier of clear programming skills. Quite often, simpler and less code makes it easier for others to participate. Joining an existing project requires a demonstrated ability to build the trust to refactor and re-architect anything over time. Otherwise patchwork works.
gnaritas 10y ago
> Clever and elegant architecture will always beat clever programming. And clever elegant architecture and clever programming will beat either alone. It's not an either or situation, you want them all.
- deleted 10y ago
  [deleted]

Darmani 10y ago

There are a couple ways to be called a 10x programmer. One is by doing more, by throwing around more code and building more features. This is the kind that the article talks about. It's quite hard to maintain this kind of multiplier, no matter how much technical debt you're willing to create. I can think of one example of someone like this, and his multiplier was definitely not 10x. At the time, he was at best labelled "up-and-coming." He'd go home over the weekend and write thousands of lines of code, and then the team would come in and find everything broken. Another is by doing less, and simply being at a higher level than others. In my experience, no-one gets to 10x by just banging harder and letting other people clean up the mess. Even if you do, those aren't the people whose impact is felt for years after they leave, at least not in any positive sense. You get to 10x by being the one person who can spot the mess the rest of the team is about to create before they've written the first line. Your impact isn't felt for years by writing code: it's felt by setting the architecture, by making design decisions that constraint people into writing good code for years to come.

ktRolster 10y ago
In my experience, no-one gets to 10x by just banging harder and letting other people cleaning up the mess. Yeah, that's a good one. Cleaning up your messes is a way to improve your architecture skill quickly. I can give you other ideas that will quickly push you to 10x skill level: * Focus. Put away your phone, don't surf the internet at work. That alone will raise you above the crowd and let you go home early. * Fix bugs early. Don't send them out to QA, don't send them to customers. Once your bug count starts increasing, it's a death cycle that slows you down like molasses. * As soon as bugs (or problems) come in, try to think of a way to avoid that problem in the future. Over time, you'll develop habits that will serve you well.

devishard 10y ago

This article starts off with addressing how so-called-10x developers are often just building tech debt into their applications. I was with Tiwari on that. Then he moves on to creating a non-judgmental culture... not sure I agree there. And then... linters? Huh? I think that the anti-judgment folks are trying to achieve something good, but they're throwing out the baby with the bathwater. We need to make a distinction between judging behaviors and judging people. The former isn't just good, it's fundamental--the only way to improve your behaviors is to judge them. But judging people is generally pointless, at least without some sort of temporal limitation--almost everyone starts at a new job as -0.5x net contribution until they're onboarded and improves from there.

d23 10y ago
> This article starts off with addressing how so-called-10x developers are often just building tech debt into their applications. I was with Tiwari on that. Then he moves on to creating a non-judgmental culture... not sure I agree there. And then... linters? Huh? Thank you. Did anyone read the damn article? It's all over the place -- borderline nonsensical. I suppose it's intended to be a promotion of their company. Color me unconvinced.

x64_lol 10y ago

Where is this rush to hire 10x people taking place? I asked the last 10 recruiters who called me if they know what a 10x developer is, and they had no idea.

wvenable 10y ago

Like others here, I don't consider 10x programmers to be someone who writes 10x the amount of code. In fact, most 10x programmers actually write less code but get more done with it. Personally I think the narrative works better when you think there are 1x programmers and 0.1x programmers. And a very large number of developers are actually between 1.0 and 0.1. These 0.1x programmers somehow manage to solve problems by simply puttering away at it over time. For example, these programmers might start out reading a web service into an XML file, re-opening that XML file to process the result, copying that file someone else that is never read again, taking the result and inserting it into a database table, reading the table to create an aggregate result, and then finally inserting that result into another system. And they do this all day long every day for every problem they come across. Not everyone is quite that bad, there are 0.5x programmers who know better than that but still manage to write 6 classes to solve a problem that could be done in a single 2-screen long function. Tools and processes can help and code reviews are pretty invaluable. Any good process will have weeded out 0.1x programmers already and they will settle in those places without them.

eecks 10y ago
> 6 classes to solve a problem that could be done in a single 2-screen long function Isn't the former promoted as better programming? IoC, decoupling, Law of Demeter, testability etc
- 1138 10y ago
  Promoted? Yes. Actually? No.
  - deleted 10y ago
    [deleted]
  - eecks 10y ago
    So, genuine question, why?
    - 10y ago

ktRolster 10y ago

Every study I've ever seen has found that some programmers are dramatically more productive than others (10x is a vague estimate). I don't think it's a controversial 'paradigm' at all. It also matches with the fact that skill in general is an exponential distribution, not a bell curve.

wting 10y ago

10x is a measure of impact relative to others. From that definition, I have no doubt it exists. There's a couple ways to find 10x'ers: # A person that does things no one else can. A problem requires calculating taxes for an invoice. Someone who computes this programmatically is better than a person who hand calculates everything. A problem requires calculating the area under the curve. Someone who uses calculus is better than someone who only knows algebra and geometry. A problem requires charging a user's credit card once on checkout. Someone who understands idempotent operations is infinitely better. (I was charged 3 times for a single purchase yesterday, and now disputing with the merchant.) # A person that grows the people around them. A person growing teammates to 2x or 3x their previously level has a cumulative 10x impact. This can be teaching how to approach problems, choose the right abstractions, make engineering tradeoffs, manage risk, write robust code that is easily testable, etc. # A person that makes others more efficient. If the average dev waits 1 hr for a build, and someone reduces that to 5 minutes then they have saved: x devs * y builds / day * 55 min This has indirect effects such as maintaining flow state, minimizing context switching, etc. # A person that brings down the teammates. A dev that builds fast enough (5x), but grows tech debt such that the rest of the team operates at 0.5x. By definition they are a 10x relative to their teammates. :P

deleted 10y ago

[deleted]

leovonl 10y ago

Fact: everybody wants a 10x programmer but nobody wants to be a 10x manager. Also, dealing with a skilled programmer is not just a matter of top-down policy: a 10x programmer may have a different opinion about tools and processes and will not be happy on simply conforming - as opposed to the programmer who doesn't know better.

ktRolster 10y ago
>but nobody wants to be a 10x manager. How would one go about becoming a 10x manager? Like, what would that person accomplish?

x64_lol 10y ago

I see the point here. No matter what it's called, you're talking about people that don't use best practices, for better or worse. Best practices will get you where you're going in a predictable way, but there is a ton of inefficiency, as they don't take your specific problem into account. When I was new to moving away from best practices, I wrote a lot of difficult to understand code that was very performant. I spent my evenings reading documentation, reading the code of the people I admired (mostly decompiled framework code), and was very excited to put what I learned into practice and learn by experience. It made me proud to write code that out-performed my coworker's code by orders of magnitude. I worked for one of the top 100 most trafficked sites in the US, and on a platform that was not designed for that level of traffic (none are). A month later, the lead architect and I had a discussion that did not go my way. I was asked to write a very public and humbling apology to the team, and that apology still exists hosted on the internal network at that company (in a place that is easy to find). I had a lot of talent, but not a lot of wisdom. From that day on, I was to work on the most difficult projects exclusively, and under direct supervision of that architect. We worked on maintaining the performance edge, but doing so in a way that is easy for other developers to understand and extend. He taught me to interface directly with the other departments and senior management to make changes to the development process before work got to development; to enable us to do our best. It was a difficult road, and I was yelled at a lot; but eventually the architect cleared me to work without supervision. What followed is the most productive two years the company I worked for had ever had. I was promoted multiple times, was awarded patents, and was able to do a lot of lasting good. I had a hand in every project, feature, and department. I designed and internally evangelized a few myself, and had become the go-to guy to get difficult things done. You know this company, if I told you their name you'd recognize them and their product immediately (you've likely used my work). I left about 4 years ago to build my own company. I do consulting during the day, and take jobs that require a hero to survive (to stay sharp). Since I left, there have been no significant new features or achievements out of the company I left. Moral of the story: If you're talented, your idea of a good night is reading documentation and decompiling/memorizing products you like, and want to be a 10x developer; get someone you admire to yell at you, rip your work apart every day, and tell you that you're garbage for a year. It will do you (and your company) a lot of good.

10y ago

hashkb 10y ago

http://kytrinyx.com/presentations/here-be-dragons http://kytrinyx.com/presentations/here-be-dragons An excellent talk that can put this in perspective for non technical people.

blacksmythe 10y ago

Does anyone doubt that there are 2x programmers (programmers twice as effective as an average senior developer)? I have worked with a number of them. If one were to assume some sort of power law or Gaussian tail distribution, it is logical to assume that a few 10x programmers exist. However, they are going to be sufficiently rare that you are not likely to be able to find them or recruit them. A more interesting question is if there are 3-4x programmers, and if so, is it feasible to find and recruit them? I have worked with people (rarely) that I would consider 4x programmers.

BerislavLopac 10y ago

The main problem with the "10x productivity" myth is that it's not clear what is that 10x _of_. Is it the amount of functionality? Or maintainability of the code? Reusability? Performance? I've seen many developers implement some functionality in a record amount of time, but the resulting code was later discovered to be a) bug-ridden, b) difficult to maintain, c) unscalable or d) all of the above.

mathgeek 10y ago
> the resulting code was later discovered to be a) bug-ridden, b) difficult to maintain, c) unscalable or d) all of the above. I think this describes most code that's ever been written.