3 ms·

The Mythical 10x Programmer

14 points by tmfi 6y ago

kar5pt 6y ago
I'm pretty sure the study which gave rise to the 10x myth has been debunked. I think the reason why this myth persists is because of engineers' conceit. Everyone wants to believe that they're the 10xer. Besides even if some engineers were 10x as productive as other engineers, how would we even measure that? 10x as many lines of code written? 10x as many features released? Development work is extremely hard to quantify, so it's unclear what "10x as productive" even means.
xupybd 6y ago
I've moved from being an external consultant to an internal Dev and think I've been able to be 10x more productive in some ways. I have spent time actually doing the administrative tasks, and I have direct access to all stakeholders. This means I don't have to spend time doing requirements gathering. I understand the businesses needs. Once I would have built a web interface with all the extra work required. Now I write a script and a report to display data from the process. I can do that in next to no time, most of my time used to be spent on the front end. It turns out no one needed or wanted a front end. Business events supply all the input via existing systems. Printable reports work much better than web interfaces. I have no security tiers as you either can see a report or can't. It's amazing how much time we spent building parts of systems that no one wanted. I'm producing 10x less of a system than I used to but still solving the business problems. The things I build now are more boring, don't push my technical skills, yet deliver more to the business.
- TheRealDunkirk 6y ago
  This is an important point, which I didn't bring out in my diatribe. I'm a mechanical engineer working as a dev/op. I understand what my engineering-department coworkers are trying to do, and have a good feeling for what it would take from software to help get that done. I'm embedded in the business, talking with people. I don't have a B-school background, and sit around talking to managers, to write requirements docs to chuck over a wall. I see what needs to be done, and do it. Perfect example: When I got put out to pasture (in my story), I was working on rewriting an old, slow application that was used by just a couple dozen people. In about 3 months, I was about 80% done, and got around to asking the really important questions. The program was slow because it was basically doing a pivot operation on an entire database. I took the 800-line query in their existing Java application, rewrote it in 40 lines, and doubled the speed, but why? Turns out that there were just 2 other people in the company that used the output, and I knew one of them, and I knew he didn't need 90% of that data. So we were just getting to the point where -- like you said -- maybe a weekly email of just the relevant data was really all that was needed for the output -- when my boss politically maneuvered to kill the project. So now these users will deal with this horrible mess until the heat-death of the universe.
TheRealDunkirk 6y ago
This old chestnut again. Look, this is really simple. There are 10x people in EVERY endeavor. Why should programming be any different? My favorite example is Tom Brady. Even among the 32 best quarterbacks in the ENTIRE WORLD, he has stood head-and-shoulders above them for DECADES. It's an extreme example, and I hate sports, but it neatly shows that people CAN be THAT much better than their peers, and NOT necessarily carry the baggage that people want to automatically ascribe to such talent. A few years back, I started working at a Fortune 250. The manager wanted me to rewrite, from scratch, a database application that kept track of "tuning" changes to ECM software. He had written a program to do it, but it was slow, and falling over as he added features and new groups to it. It took me about a year and half to understand the process, prototype the database schema, and get a beta version up and running, and then a few more months to get all the bugs worked out. Call it 2 years. At the same time, another group -- who was SUPPOSED to be the ones responsible for writing this kind of software in the company -- restarted a decade-long, lapsed effort to do the same thing. (If they had written proper tools to begin with, this entire class of problem wouldn't need to be solved in the first place, but I digress.) They off-shored the whole thing to a team of 10. It took them another year longer to get to beta, so 3 years. So 2 man-years vs 30. According to this one project, I'm a 15x programmer. Their program is so slow, they brought in Microsoft to try to fix it, and failed. My program can display a calibration in 6 seconds. Theirs takes 2 minutes... to get the FIRST PAGE of hundreds. It's so counterintuitive, they've only managed to cajole the smallest engineering group into using it. My program is still being used by thousands of engineers, and has run with only a few tiny patches for 4 years now. Our reward for this outstanding success? We were forced to give our application to the other group. My boss was officially reprimanded, and forced out of his position. I was put out to pasture with a boss who buried all of my efforts with bureaucracy. An inquisition was held by the CIO about all of this. The boss that did all of this retribution was promoted. My old boss got a new position. I left the company and came back in 3 months to work with him again. Even after 40 years of programming being a thing, large manufacturing companies still want to try to treat programming as though it were production line work, and it's just not. I would guess the situation is better at companies who understand that software is their primary product, but blue-chip companies are going to have to realize that EVERY company is a software-first company now.
- 6y ago

14 points by tmfi 6y ago

I'm pretty sure the study which gave rise to the 10x myth has been debunked. I think the reason why this myth persists is because of engineers' conceit. Everyone wants to believe that they're the 10xer. Besides even if some engineers were 10x as productive as other engineers, how would we even measure that? 10x as many lines of code written? 10x as many features released? Development work is extremely hard to quantify, so it's unclear what "10x as productive" even means.

xupybd 6y ago

I've moved from being an external consultant to an internal Dev and think I've been able to be 10x more productive in some ways. I have spent time actually doing the administrative tasks, and I have direct access to all stakeholders. This means I don't have to spend time doing requirements gathering. I understand the businesses needs. Once I would have built a web interface with all the extra work required. Now I write a script and a report to display data from the process. I can do that in next to no time, most of my time used to be spent on the front end. It turns out no one needed or wanted a front end. Business events supply all the input via existing systems. Printable reports work much better than web interfaces. I have no security tiers as you either can see a report or can't. It's amazing how much time we spent building parts of systems that no one wanted. I'm producing 10x less of a system than I used to but still solving the business problems. The things I build now are more boring, don't push my technical skills, yet deliver more to the business.

TheRealDunkirk 6y ago
This is an important point, which I didn't bring out in my diatribe. I'm a mechanical engineer working as a dev/op. I understand what my engineering-department coworkers are trying to do, and have a good feeling for what it would take from software to help get that done. I'm embedded in the business, talking with people. I don't have a B-school background, and sit around talking to managers, to write requirements docs to chuck over a wall. I see what needs to be done, and do it. Perfect example: When I got put out to pasture (in my story), I was working on rewriting an old, slow application that was used by just a couple dozen people. In about 3 months, I was about 80% done, and got around to asking the really important questions. The program was slow because it was basically doing a pivot operation on an entire database. I took the 800-line query in their existing Java application, rewrote it in 40 lines, and doubled the speed, but why? Turns out that there were just 2 other people in the company that used the output, and I knew one of them, and I knew he didn't need 90% of that data. So we were just getting to the point where -- like you said -- maybe a weekly email of just the relevant data was really all that was needed for the output -- when my boss politically maneuvered to kill the project. So now these users will deal with this horrible mess until the heat-death of the universe.

TheRealDunkirk 6y ago

This old chestnut again. Look, this is really simple. There are 10x people in EVERY endeavor. Why should programming be any different? My favorite example is Tom Brady. Even among the 32 best quarterbacks in the ENTIRE WORLD, he has stood head-and-shoulders above them for DECADES. It's an extreme example, and I hate sports, but it neatly shows that people CAN be THAT much better than their peers, and NOT necessarily carry the baggage that people want to automatically ascribe to such talent. A few years back, I started working at a Fortune 250. The manager wanted me to rewrite, from scratch, a database application that kept track of "tuning" changes to ECM software. He had written a program to do it, but it was slow, and falling over as he added features and new groups to it. It took me about a year and half to understand the process, prototype the database schema, and get a beta version up and running, and then a few more months to get all the bugs worked out. Call it 2 years. At the same time, another group -- who was SUPPOSED to be the ones responsible for writing this kind of software in the company -- restarted a decade-long, lapsed effort to do the same thing. (If they had written proper tools to begin with, this entire class of problem wouldn't need to be solved in the first place, but I digress.) They off-shored the whole thing to a team of 10. It took them another year longer to get to beta, so 3 years. So 2 man-years vs 30. According to this one project, I'm a 15x programmer. Their program is so slow, they brought in Microsoft to try to fix it, and failed. My program can display a calibration in 6 seconds. Theirs takes 2 minutes... to get the FIRST PAGE of hundreds. It's so counterintuitive, they've only managed to cajole the smallest engineering group into using it. My program is still being used by thousands of engineers, and has run with only a few tiny patches for 4 years now. Our reward for this outstanding success? We were forced to give our application to the other group. My boss was officially reprimanded, and forced out of his position. I was put out to pasture with a boss who buried all of my efforts with bureaucracy. An inquisition was held by the CIO about all of this. The boss that did all of this retribution was promoted. My old boss got a new position. I left the company and came back in 3 months to work with him again. Even after 40 years of programming being a thing, large manufacturing companies still want to try to treat programming as though it were production line work, and it's just not. I would guess the situation is better at companies who understand that software is their primary product, but blue-chip companies are going to have to realize that EVERY company is a software-first company now.

6y ago