10 ms·

I don't disagree but the idea of equating software development with some sort of artistry also allows the existence of the 10x programmer as, you know, a more g

I don't disagree but the idea of equating software development with some sort of artistry also allows the existence of the 10x programmer as, you know, a more gifted artists. Whether any one of us believes in 10x'ers aside, there are a lot of problems with this from the perspective of those paying the salaries, not least of which it means developers are not simply interchangeable cogs in a machine/process. The most horrendous application I ever worked on was a java servlet app where the original developers didn't understand thread safety. They didn't let that stop them though. Every collection was a synchronized list or concurrent hash map, every access was wrapped in a mutex or synchronized{} block. It was really really bad; lots of race conditions and deadlocks, lots of production outages and a lot of "add more locks". In the neighborhood of 200,000 lines of this. It was "artistry" of a sort. That application got the company to IPO, so the business owners were overjoyed with it. What's the point? Gatekeepers can gatekeep, artists can create art, but even the most banal garbage can make someone a lot of money.

3pt14159 6y ago
Well there are more productive programmers and less productive ones. It's pretty obvious to me. I don't like trying to quantify it as 10x or 20x, because it's kinda pointless to try and I don't view it as a scalar. I can't program graphics cards, but I can rebuild some of the data feeds that the Nasdaq pipes to hedge funds. I don't think a game developer could do what I do. It's the specialization that really counts, not the raw productivity, but raw productivity does count too. In terms of your example, yes. The problem with software is that a bad architecture can complete hobble it and there are plenty of cases with unbeautiful code that makes a pile of money. I think there is artistry in software, but that wasn't the primary reason I compared it to music. I was trying to express the vastness of the domain and the range of complexity and how one could find a part in the search space that is simple enough to be called easy. Hence the garage band metaphor. Not everyone is going to be writing compilers. Some people don't want to throw their brain at a heap of complexity all day long. They just want to make pretty buttons that have a satisfying snappiness to them and call it a day. What I'm trying to say is that there isn't one "programming" and for the people that need to hear "programming is easy, anyone can do it" in order to get the courage to try to take it up, I think that message is good. It doesn't mean they'll be working for Nasa on space probes, but they can make a comfortable living on low stakes stuff and have fun while they're at it.
adam_arthur 6y ago
I've been consistently amazed at how far companies can get on shoddy code. In my experience, even majorly successful startups that turn into companies worth 10's of billions tend to have lots of technical debt. Honestly, I believe that at some scale its very difficult to get the caliber of experience and talent that can keep a codebase clean. People often say accruing technical debt is a form of shortcutting to a more business focused goal, but in my experience the technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff. Especially when you consider a SaaS company where your product lives forever and is meant to scale, taking on technical debt for short term gain is almost never the right decision. Not to reopen the 10x engineer debate, but I've observed that the top 20% of engineers tend to do 80% of the total work of an org. Of course, 10x is relative... But there are definitely individuals that are 10x more productive than the median engineer. And for whatever reason, that seems more to do with an individual's personality and drive than their level of experience... Though of course experience helps. Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others. What I see in a lot of these SaaS codebases is that it takes a week to do something that should take 1 day, due to amount of technical debt and spaghetti code. Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business). The impact that it has on velocity is just monumental. Code quality and philosophy of well written code is not stressed at all in school... One example of how far off we are from maturity as a discipline. There is a whole school of thought that's currently neglected that will become mainstream in the future IMO. Similar to other engineering disciplines...
- vsareto 6y ago
  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.
lhorie 6y ago
I think the comparison is quite apt, given that the most popular artists are usually not the ones that have "mastered their craft" the most. One can argue that White Stripes' 7 Nation Army or Andy Warhol's Campbell's Soup Cans are not feats of technical mastery by any stretch of imagination, but the key is that there is no correlation between technical difficulty and monetary value in the first place. With that said, it's also worth mentioning that the world is vast enough that there's a bit of everything. Yes, there are companies making millions on the back of terrible excel spreadsheet hackjobs. But there's also Google's impressive infrastructure. And there's lichess.org running a hugely popular app on just a few servers. Success in itself it not one-dimensional.
- munificent 6y ago
  > One can argue that White Stripes' 7 Nation Army or Andy Warhol's Campbell's Soup Cans are not feats of technical mastery by any stretch of imagination, but the key is that there is no correlation between technical difficulty and monetary value in the first place. I see arguments like this a lot and it think it conflates two very different kinds of "technical difficulty"—design difficulty and execution difficulty. Given the sheet music, any guitarist can play 7 Nation Army in a few minutes. It is not physically difficult to play. Also, it's not hard to come up with a completely original melody or artistic work. Just throw a couple of random unrelated things together. But it is extraordinarily difficult to have such a mastery of composition and understanding of what music is already familiar to people to be able to find a melody that is both original and enjoyable to a wide variety of people. The level of cultural, musical, and historical knowledge required to do that is extremely difficult and rare. It's like taking your boat to the world's most popular fishing hole and knowing where everyone else fishes so well that you can still manage to stake out an unvisited spot that hasn't been fished out and reel in a giant.
  - lhorie 6y ago
    > But it is extraordinarily difficult to have such a mastery of composition and understanding of what music is already familiar to people The problem with this argument IMHO is that if it were true, one would in fact be able to just bang out hits by developing such mastery. But music hits get popular primarily on the basis of luck, survivor bias, branding, etc, not strictly based on artists' composition skills. There are plenty of very talented one-hit wonders, and even criticisms that popular music is "manufactured" (implying that it is relatively easy to just follow some vague formula of 4/4, II-V-I chord progressions and lyrics about love and end up with something that resembles a hit).
hajile 6y ago
Price's Law is a thing. It states that the square root of all scientists publish half of all scientific papers. If you have 25 programmers on a project, it is rather likely that 4-6 of them do at least half of the work. That would be a 5x developer. Very often, productivity is linked to perseverance. If you socialize and only actually codes 1-4 hours per day, you likely are far less productive than the on-the-spectrum programmer who pounds out code for an entire work day (or longer).
- drran 6y ago
  It looks like you have a wrong metric for the productivity. A lot of projects failed just because developers created millions lines of code. The performant developer solves problems quickly, without creating problems for others, i.e. he unloads burden from the project.
  - lanstin 6y ago
    Seriously. We have hired a lot of people recently and the people that submit a five line PR make me happy and the fifteen file PRs make me sad.
    - randomswede 6y ago
      I have slowly managed to train my colleagues that a PR should be "one thing". My team ends up doing a whole lot of internal tooling, so we're frequently creating "new small tool" and one colleague started by working away and only raising the PR when the toll was essentially done. This, essentially, ends up with a PR review that takes hours to complete, only to end up with at least a few "changes required". Leading to updates, and a re-review, usually with enough time lapsed that the review ends up being "from scratch" (partially due to the size of the PR, partially due to the time lapsed). We've now mostly converged to "start with a PR just setting the skeleton up and one testable function", meaning that what used to be a single monster PR now ends up as 5-15 PRs, each one much easier to review. Amusingly, this also tends to end up with things being completed faster.
908B64B197 6y ago
> Whether any one of us believes in 10x'ers aside I've met a lot of folks who didn't believe it... right until they met one. > That application got the company to IPO They got lucky they could IPO before scaling became an issue. Just imagine Google not being able to scale. Or Facebook.
- IncRnd 6y ago
  > I've met a lot of folks who didn't believe it... right until they met one. That right there is the truth about 10x engineers. We have one in particular I will mention. Sometimes he is a 5x, and at other times he is 20x. This is true and measurable according to the number of tickets that get closed, stay closed, and test as correct. He doesn't read HN, stack overflow, fb, twitter, tiktok, blogs, or emails during work hours. He sits down and cranks out code.
  - 908B64B197 6y ago
    > measurable according to the number of tickets that get closed, stay closed, and test as correct 10x engineers also have compounding effects. These are impossible to measure, but you'll notice them when you see them. They flat out write better code. Better code fails gracefully, is easy to read and especially nice to extend. Juniors seems to magically be able to ship features really quickly on that particular codebase and onboard really fast. If you dig deeper you'll see the 10x giving hints and feedback.
WalterBright 6y ago
There's artistry in mechanical engineering, electronics, etc., too. Take a close look at various bridge designs, and you'll see the artistry.
watwut 6y ago
> I don't disagree but the idea of equating software development with some sort of artistry also allows the existence of the 10x programmer as, you know, a more gifted artists. [...] The most horrendous application I ever worked on was a java servlet app where the original developers didn't understand thread safety. The knowledge of thread safety is not an inborn thing nor issue of talent. It is literally issue of knowledge that you can acquire if you previously did not had it. And companies can get away with bad code for quite a long.

3pt14159 6y ago

Well there are more productive programmers and less productive ones. It's pretty obvious to me. I don't like trying to quantify it as 10x or 20x, because it's kinda pointless to try and I don't view it as a scalar. I can't program graphics cards, but I can rebuild some of the data feeds that the Nasdaq pipes to hedge funds. I don't think a game developer could do what I do. It's the specialization that really counts, not the raw productivity, but raw productivity does count too. In terms of your example, yes. The problem with software is that a bad architecture can complete hobble it and there are plenty of cases with unbeautiful code that makes a pile of money. I think there is artistry in software, but that wasn't the primary reason I compared it to music. I was trying to express the vastness of the domain and the range of complexity and how one could find a part in the search space that is simple enough to be called easy. Hence the garage band metaphor. Not everyone is going to be writing compilers. Some people don't want to throw their brain at a heap of complexity all day long. They just want to make pretty buttons that have a satisfying snappiness to them and call it a day. What I'm trying to say is that there isn't one "programming" and for the people that need to hear "programming is easy, anyone can do it" in order to get the courage to try to take it up, I think that message is good. It doesn't mean they'll be working for Nasa on space probes, but they can make a comfortable living on low stakes stuff and have fun while they're at it.

adam_arthur 6y ago

I've been consistently amazed at how far companies can get on shoddy code. In my experience, even majorly successful startups that turn into companies worth 10's of billions tend to have lots of technical debt. Honestly, I believe that at some scale its very difficult to get the caliber of experience and talent that can keep a codebase clean. People often say accruing technical debt is a form of shortcutting to a more business focused goal, but in my experience the technical debt is almost always created by accident through lack of experience rather than a conscious tradeoff. Especially when you consider a SaaS company where your product lives forever and is meant to scale, taking on technical debt for short term gain is almost never the right decision. Not to reopen the 10x engineer debate, but I've observed that the top 20% of engineers tend to do 80% of the total work of an org. Of course, 10x is relative... But there are definitely individuals that are 10x more productive than the median engineer. And for whatever reason, that seems more to do with an individual's personality and drive than their level of experience... Though of course experience helps. Especially as a project scales, somebody who makes good technical decisions will only increase the productivity margin between themselves and others. What I see in a lot of these SaaS codebases is that it takes a week to do something that should take 1 day, due to amount of technical debt and spaghetti code. Software is still a new industry. I fully believe the companies that win in the long run will be the ones that have the best codebases (assuming software is what differentiates your business). The impact that it has on velocity is just monumental. Code quality and philosophy of well written code is not stressed at all in school... One example of how far off we are from maturity as a discipline. There is a whole school of thought that's currently neglected that will become mainstream in the future IMO. Similar to other engineering disciplines...

vsareto 6y ago
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.

lhorie 6y ago

I think the comparison is quite apt, given that the most popular artists are usually not the ones that have "mastered their craft" the most. One can argue that White Stripes' 7 Nation Army or Andy Warhol's Campbell's Soup Cans are not feats of technical mastery by any stretch of imagination, but the key is that there is no correlation between technical difficulty and monetary value in the first place. With that said, it's also worth mentioning that the world is vast enough that there's a bit of everything. Yes, there are companies making millions on the back of terrible excel spreadsheet hackjobs. But there's also Google's impressive infrastructure. And there's lichess.org running a hugely popular app on just a few servers. Success in itself it not one-dimensional.

munificent 6y ago
> One can argue that White Stripes' 7 Nation Army or Andy Warhol's Campbell's Soup Cans are not feats of technical mastery by any stretch of imagination, but the key is that there is no correlation between technical difficulty and monetary value in the first place. I see arguments like this a lot and it think it conflates two very different kinds of "technical difficulty"—design difficulty and execution difficulty. Given the sheet music, any guitarist can play 7 Nation Army in a few minutes. It is not physically difficult to play. Also, it's not hard to come up with a completely original melody or artistic work. Just throw a couple of random unrelated things together. But it is extraordinarily difficult to have such a mastery of composition and understanding of what music is already familiar to people to be able to find a melody that is both original and enjoyable to a wide variety of people. The level of cultural, musical, and historical knowledge required to do that is extremely difficult and rare. It's like taking your boat to the world's most popular fishing hole and knowing where everyone else fishes so well that you can still manage to stake out an unvisited spot that hasn't been fished out and reel in a giant.
- lhorie 6y ago
  > But it is extraordinarily difficult to have such a mastery of composition and understanding of what music is already familiar to people The problem with this argument IMHO is that if it were true, one would in fact be able to just bang out hits by developing such mastery. But music hits get popular primarily on the basis of luck, survivor bias, branding, etc, not strictly based on artists' composition skills. There are plenty of very talented one-hit wonders, and even criticisms that popular music is "manufactured" (implying that it is relatively easy to just follow some vague formula of 4/4, II-V-I chord progressions and lyrics about love and end up with something that resembles a hit).

hajile 6y ago

Price's Law is a thing. It states that the square root of all scientists publish half of all scientific papers. If you have 25 programmers on a project, it is rather likely that 4-6 of them do at least half of the work. That would be a 5x developer. Very often, productivity is linked to perseverance. If you socialize and only actually codes 1-4 hours per day, you likely are far less productive than the on-the-spectrum programmer who pounds out code for an entire work day (or longer).

drran 6y ago
It looks like you have a wrong metric for the productivity. A lot of projects failed just because developers created millions lines of code. The performant developer solves problems quickly, without creating problems for others, i.e. he unloads burden from the project.
- lanstin 6y ago
  Seriously. We have hired a lot of people recently and the people that submit a five line PR make me happy and the fifteen file PRs make me sad.
  - randomswede 6y ago
    I have slowly managed to train my colleagues that a PR should be "one thing". My team ends up doing a whole lot of internal tooling, so we're frequently creating "new small tool" and one colleague started by working away and only raising the PR when the toll was essentially done. This, essentially, ends up with a PR review that takes hours to complete, only to end up with at least a few "changes required". Leading to updates, and a re-review, usually with enough time lapsed that the review ends up being "from scratch" (partially due to the size of the PR, partially due to the time lapsed). We've now mostly converged to "start with a PR just setting the skeleton up and one testable function", meaning that what used to be a single monster PR now ends up as 5-15 PRs, each one much easier to review. Amusingly, this also tends to end up with things being completed faster.

908B64B197 6y ago

> Whether any one of us believes in 10x'ers aside I've met a lot of folks who didn't believe it... right until they met one. > That application got the company to IPO They got lucky they could IPO before scaling became an issue. Just imagine Google not being able to scale. Or Facebook.

IncRnd 6y ago
> I've met a lot of folks who didn't believe it... right until they met one. That right there is the truth about 10x engineers. We have one in particular I will mention. Sometimes he is a 5x, and at other times he is 20x. This is true and measurable according to the number of tickets that get closed, stay closed, and test as correct. He doesn't read HN, stack overflow, fb, twitter, tiktok, blogs, or emails during work hours. He sits down and cranks out code.
- 908B64B197 6y ago
  > measurable according to the number of tickets that get closed, stay closed, and test as correct 10x engineers also have compounding effects. These are impossible to measure, but you'll notice them when you see them. They flat out write better code. Better code fails gracefully, is easy to read and especially nice to extend. Juniors seems to magically be able to ship features really quickly on that particular codebase and onboard really fast. If you dig deeper you'll see the 10x giving hints and feedback.

WalterBright 6y ago

There's artistry in mechanical engineering, electronics, etc., too. Take a close look at various bridge designs, and you'll see the artistry.

watwut 6y ago

> I don't disagree but the idea of equating software development with some sort of artistry also allows the existence of the 10x programmer as, you know, a more gifted artists. [...] The most horrendous application I ever worked on was a java servlet app where the original developers didn't understand thread safety. The knowledge of thread safety is not an inborn thing nor issue of talent. It is literally issue of knowledge that you can acquire if you previously did not had it. And companies can get away with bad code for quite a long.