6 ms·

Ask HN: Efficiency of 10x engineer while refactoring legacy/messed up code base?

Will their efficiency be still 10x if they are assigned to maintain and debug a shitty(but working) code base?

flukus 10y ago
No, because 10x is a myth. Usually someone described (probably by themselves) as a 10xer are the ones responsible for the code base being so bad in the first place. 10xers only work on green fields, they never get a chance to see what a catastrophe their ideas turned out to be.
- gregjor 10y ago
  Generalizations, not true. In my experience many of the most talented and valuable programmers work on important legacy systems. There is a class of programmers who only want to work on green fields projects, and they may think they are 10X or ninjas or rockstars. They aren't. That's arrogance, not skill or expertise or ability to deliver. I have 40 years programming experience to back that up. I agree that measuring individual programming productivity, or making any general statements about it, can be so hard that it's almost meaningless to say anything. Someone can be wildly good on project A with team X, and then flail on project B with yeam Y. I wrote about this: http://typicalprogrammer.com/why-dont-software-development-methodologies-work http://typicalprogrammer.com/why-dont-software-development-m...
  - _benedict 10y ago
    "That's arrogance... I have 40 years programming experience to back that up." Ironic juxtaposition.
    - gregjor 10y ago
      Maybe, I didn't notice that. I was pointing out the difference between experience and believing that I can do better than other programmers because I watched an online course about AngularJS and now I can fix everything. I try to stay humble when learning a new code base.
gregjor 10y ago
Disclaimer: I don't call myself 10X anything but I do work through 10X Management. I only work on legacy code, that's my specialty. My opinions are my own and don't represent 10X Management. First off not all legacy code is "shitty." The main reason I am 10 or 100 or 1000 times more effective with legacy code is that I'm usually the only programmer the customer has talked to who will work with it. Everyone else has one solution: Throw it away and start over with [insert favorite cool language/framework/ideology]. So at least in my experience it's not that I'm 10X more effective, it's that everyone else is 0X effective because they won't even try. It's easy and maybe fun to simply dismiss legacy systems as junk and shit and catastrophes, but when a business has a system that mostly works and they need some debugging, enhancement, improvement it's usually irresponsible to tell them to start over. When you do that you are telling the customer to throw away something that works, even though it has problems, and take a huge gamble on a new system that is 75% unlikely to even go live. You are telling your customer that your one hour reading of some code that you declare "shitty" is more informed than all of the cumulative experience of previous developers. You are telling your customer to change business processes, retrain staff, all on your word that you are more clever than the last team. Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. That's a story I hear about software systems every month. The most important metric of software is whether it solves a business problem and adds value or not. What language it's written in, or whether the last programmer used spaces or tabs or camelCase or knew OOP as well as you think you do are not relevant metrics from the customer's perspective. And since a lot of the code I work on is not actually that old -- in fact it's just as likely to be the unfinished remains of the last green fields team -- I can say without hesitating that the worst code to work on comes from programmers who are so committed to an ideology or language or toolkit they lose sight of requirements and the only goal that matters: adding value to the business.
- somehnreader 10y ago
  This is the best thing I read for ages. I work with legacy systems all the time, lately mostly CRUD web apps, but I have debugged myself through pages of Excel macros, database drivers in enterprise systems and some code that was almost as old as me, and 100% agree with what you have written. Bookmarking this post for future reference.
deleted 10y ago
[deleted]
BjoernKW 10y ago
10x is a strange label. I don't think that 10 times the efficiency of an average engineer is achievable consistently anyway. Programming depends on so many extrinsic factors like the environment you're working in, the product you're working on and the people you're working with. Effective communication probably is the single most important aspect of successful software development. Thinking of yourself as someone who is 10 times better than others likely doesn't help in that respect. That said, there are certainly engineers who particularly excel at working on legacy code bases. Refactoring and modernising an existing codebase poses an interesting challenge and it provides actual business value. Anyone can start a new greenfield application. Working on a legacy codebase takes at least a bit of courage and a deep understanding of the business involved. People often seem to forget that a supposedly shitty but working codebase for the most part probably didn't become that way because its original developers were just stupid but because the business requirements are inherently complex and contain a lot of edge cases. By decrying legacy code you might throw out years or even decades of expert knowledge about the business.
- gregjor 10y ago
  Very true. In many businesses their software systems are the only coherent and (mostly) consistent description of business processes. There may not be any documentation and often no single person in the company knows how everything works. Customers will tell you how they'd like things to work -- green fields projects give them a chance to dream and try to fix everything -- but whatever code they have tells you how things actually work. Ignore that at your peril. I don't care how 10X someone thinks they are. No one can walk into a business, have a one hour meeting glancing at some screens, click through some code ("Oh wow. Shitty. This is terrible.") and learn even a tiny bit of how things actually work. Yet I see proposals for tens or hundreds of thousands of dollars based on that kind of shallow analysis, and a customer high on the promise of seeing their dreams realized in what will be the first perfect software development project in history. You're exactly right, "Anyone can start a new greenfield application. Working on a legacy codebase takes at least a bit of courage and a deep understanding of the business involved."
dagw 10y ago
There is no such thing as a general 10x engineer. There are engineers that are 10x better than average at writing network stack and engineers that are 10x better at writing PDE solvers and engineers that are 10x better at creating user friendly web front ends, but it's not the same person. By the same vein there are absolutely engineers that are 10x better than average at dealing with legacy code bases, but a massive factor is also how experienced they are with the domain that the codebase is about. For example is the code base some sort of logistics management system, then someone who has worked on a lot of logistics management systems in the past is going to have a significant advantage.
usgroup 10y ago
Notice the poster selection bias on this thread?
itamarst 10y ago
A more realistic view of 10x engineer is not someone who can produce 10x amount of code... it's producing the same amount of value at 1/10th the effort by being able to focus on actual goal. Sometimes that means fixing existing codebase instead of the massive effort to do a rewrite (see gregjor's great comment). Sometimes that means figuring out that the custom legacy software can be replaced by an off-the-shelf solution. Sometimes that means figuring out that only some of the legacy software is actually important, so only that part needs to be maintained and the rest can be deprecated. See also https://codewithoutrules.com/2016/08/25/the-01x-programmer/ https://codewithoutrules.com/2016/08/25/the-01x-programmer/
Nerdenator 10y ago
Well, depends. For example, we had a 10x guy recommend that we re-write our health insurance web app back-end in Golang, but then, we realized that meant we couldn't cover generic prescriptions. In that case, he wouldn't have remained 10x over the older Python/Django code.
- atomical 9y ago
  Golang doesn't support generic prescriptions?
skylark 10y ago
This 10x thing is quite frankly stupid. The distribution of developer skill (if that's even something that can be plotted) is not bimodal with good developers and bad developers, it's normal. Sure someone 2 SDs above the mean might be 10x more productive than someone 2 SDs below the mean, but the same can be said for literally anything that requires skill. While we're at it, why don't we call Gordon Ramsay a 10x chef? Or Yo-Yo Ma a 10x cellist. While this is technically true, it's not particularly insightful, and certainly not something you should use to label yourself. To answer your question, yes someone skilled at software development will be slowed down if dealing with a legacy codebase.
- gregjor 10y ago
  I agree with almost everything. Talent and experience make a difference, but programmer productivity is situational. Some teams and projects bring out the best in everyone. And I've had bosses and customers and team members who make sure no one is very productive. Working with legacy code is a skill too. I don't think it's true that a skilled programmer will necessarily be slowed down with a legacy codebase. Another way to look at legacy vs. green field is that with a legacy system there's already a fairly complete spec, expressed in the code. Learning to read and understand code is a skill that programmers can learn if they care to.
bjourne 10y ago
Absolutely! But the efficiency gain will come from knowing what to do, not from doing it ten times faster. For example, if the shitty code base doesn't have unit tests a 10x programmer might decide to put everything else on hold and write a unit test suite. A 1x programmer would perhaps not understand the long term benefits of testing, and instead spend his or her time patching bug after bug. Another trap a 10x programmer would not fall into is deciding to rewrite the whole system from scratch because the code is hard to understand. But sometimes the only way forward is to rewrite it all. It boils down to being a judgement call and the more experienced you are the better judgement calls you make.

Will their efficiency be still 10x if they are assigned to maintain and debug a shitty(but working) code base?

No, because 10x is a myth. Usually someone described (probably by themselves) as a 10xer are the ones responsible for the code base being so bad in the first place. 10xers only work on green fields, they never get a chance to see what a catastrophe their ideas turned out to be.

gregjor 10y ago
Generalizations, not true. In my experience many of the most talented and valuable programmers work on important legacy systems. There is a class of programmers who only want to work on green fields projects, and they may think they are 10X or ninjas or rockstars. They aren't. That's arrogance, not skill or expertise or ability to deliver. I have 40 years programming experience to back that up. I agree that measuring individual programming productivity, or making any general statements about it, can be so hard that it's almost meaningless to say anything. Someone can be wildly good on project A with team X, and then flail on project B with yeam Y. I wrote about this: http://typicalprogrammer.com/why-dont-software-development-methodologies-work http://typicalprogrammer.com/why-dont-software-development-m...
- _benedict 10y ago
  "That's arrogance... I have 40 years programming experience to back that up." Ironic juxtaposition.
  - gregjor 10y ago
    Maybe, I didn't notice that. I was pointing out the difference between experience and believing that I can do better than other programmers because I watched an online course about AngularJS and now I can fix everything. I try to stay humble when learning a new code base.

gregjor 10y ago

Disclaimer: I don't call myself 10X anything but I do work through 10X Management. I only work on legacy code, that's my specialty. My opinions are my own and don't represent 10X Management. First off not all legacy code is "shitty." The main reason I am 10 or 100 or 1000 times more effective with legacy code is that I'm usually the only programmer the customer has talked to who will work with it. Everyone else has one solution: Throw it away and start over with [insert favorite cool language/framework/ideology]. So at least in my experience it's not that I'm 10X more effective, it's that everyone else is 0X effective because they won't even try. It's easy and maybe fun to simply dismiss legacy systems as junk and shit and catastrophes, but when a business has a system that mostly works and they need some debugging, enhancement, improvement it's usually irresponsible to tell them to start over. When you do that you are telling the customer to throw away something that works, even though it has problems, and take a huge gamble on a new system that is 75% unlikely to even go live. You are telling your customer that your one hour reading of some code that you declare "shitty" is more informed than all of the cumulative experience of previous developers. You are telling your customer to change business processes, retrain staff, all on your word that you are more clever than the last team. Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. That's a story I hear about software systems every month. The most important metric of software is whether it solves a business problem and adds value or not. What language it's written in, or whether the last programmer used spaces or tabs or camelCase or knew OOP as well as you think you do are not relevant metrics from the customer's perspective. And since a lot of the code I work on is not actually that old -- in fact it's just as likely to be the unfinished remains of the last green fields team -- I can say without hesitating that the worst code to work on comes from programmers who are so committed to an ideology or language or toolkit they lose sight of requirements and the only goal that matters: adding value to the business.

somehnreader 10y ago
This is the best thing I read for ages. I work with legacy systems all the time, lately mostly CRUD web apps, but I have debugged myself through pages of Excel macros, database drivers in enterprise systems and some code that was almost as old as me, and 100% agree with what you have written. Bookmarking this post for future reference.

deleted 10y ago

[deleted]

BjoernKW 10y ago

10x is a strange label. I don't think that 10 times the efficiency of an average engineer is achievable consistently anyway. Programming depends on so many extrinsic factors like the environment you're working in, the product you're working on and the people you're working with. Effective communication probably is the single most important aspect of successful software development. Thinking of yourself as someone who is 10 times better than others likely doesn't help in that respect. That said, there are certainly engineers who particularly excel at working on legacy code bases. Refactoring and modernising an existing codebase poses an interesting challenge and it provides actual business value. Anyone can start a new greenfield application. Working on a legacy codebase takes at least a bit of courage and a deep understanding of the business involved. People often seem to forget that a supposedly shitty but working codebase for the most part probably didn't become that way because its original developers were just stupid but because the business requirements are inherently complex and contain a lot of edge cases. By decrying legacy code you might throw out years or even decades of expert knowledge about the business.

gregjor 10y ago
Very true. In many businesses their software systems are the only coherent and (mostly) consistent description of business processes. There may not be any documentation and often no single person in the company knows how everything works. Customers will tell you how they'd like things to work -- green fields projects give them a chance to dream and try to fix everything -- but whatever code they have tells you how things actually work. Ignore that at your peril. I don't care how 10X someone thinks they are. No one can walk into a business, have a one hour meeting glancing at some screens, click through some code ("Oh wow. Shitty. This is terrible.") and learn even a tiny bit of how things actually work. Yet I see proposals for tens or hundreds of thousands of dollars based on that kind of shallow analysis, and a customer high on the promise of seeing their dreams realized in what will be the first perfect software development project in history. You're exactly right, "Anyone can start a new greenfield application. Working on a legacy codebase takes at least a bit of courage and a deep understanding of the business involved."

dagw 10y ago

There is no such thing as a general 10x engineer. There are engineers that are 10x better than average at writing network stack and engineers that are 10x better at writing PDE solvers and engineers that are 10x better at creating user friendly web front ends, but it's not the same person. By the same vein there are absolutely engineers that are 10x better than average at dealing with legacy code bases, but a massive factor is also how experienced they are with the domain that the codebase is about. For example is the code base some sort of logistics management system, then someone who has worked on a lot of logistics management systems in the past is going to have a significant advantage.

usgroup 10y ago

Notice the poster selection bias on this thread?

itamarst 10y ago

A more realistic view of 10x engineer is not someone who can produce 10x amount of code... it's producing the same amount of value at 1/10th the effort by being able to focus on actual goal. Sometimes that means fixing existing codebase instead of the massive effort to do a rewrite (see gregjor's great comment). Sometimes that means figuring out that the custom legacy software can be replaced by an off-the-shelf solution. Sometimes that means figuring out that only some of the legacy software is actually important, so only that part needs to be maintained and the rest can be deprecated. See also https://codewithoutrules.com/2016/08/25/the-01x-programmer/ https://codewithoutrules.com/2016/08/25/the-01x-programmer/

Nerdenator 10y ago

Well, depends. For example, we had a 10x guy recommend that we re-write our health insurance web app back-end in Golang, but then, we realized that meant we couldn't cover generic prescriptions. In that case, he wouldn't have remained 10x over the older Python/Django code.

atomical 9y ago
Golang doesn't support generic prescriptions?

skylark 10y ago

This 10x thing is quite frankly stupid. The distribution of developer skill (if that's even something that can be plotted) is not bimodal with good developers and bad developers, it's normal. Sure someone 2 SDs above the mean might be 10x more productive than someone 2 SDs below the mean, but the same can be said for literally anything that requires skill. While we're at it, why don't we call Gordon Ramsay a 10x chef? Or Yo-Yo Ma a 10x cellist. While this is technically true, it's not particularly insightful, and certainly not something you should use to label yourself. To answer your question, yes someone skilled at software development will be slowed down if dealing with a legacy codebase.

gregjor 10y ago
I agree with almost everything. Talent and experience make a difference, but programmer productivity is situational. Some teams and projects bring out the best in everyone. And I've had bosses and customers and team members who make sure no one is very productive. Working with legacy code is a skill too. I don't think it's true that a skilled programmer will necessarily be slowed down with a legacy codebase. Another way to look at legacy vs. green field is that with a legacy system there's already a fairly complete spec, expressed in the code. Learning to read and understand code is a skill that programmers can learn if they care to.

bjourne 10y ago

Absolutely! But the efficiency gain will come from knowing what to do, not from doing it ten times faster. For example, if the shitty code base doesn't have unit tests a 10x programmer might decide to put everything else on hold and write a unit test suite. A 1x programmer would perhaps not understand the long term benefits of testing, and instead spend his or her time patching bug after bug. Another trap a 10x programmer would not fall into is deciding to rewrite the whole system from scratch because the code is hard to understand. But sometimes the only way forward is to rewrite it all. It boils down to being a judgement call and the more experienced you are the better judgement calls you make.