3 ms·

LoC is a terrible metric - did they count the lines other engineers removed? I was half of a very productive duo on a greenfield project subsystem - a project

LoC is a terrible metric - did they count the lines other engineers removed? I was half of a very productive duo on a greenfield project subsystem - a project I joined midway: my partner wrote a lot of code, I estimate ~70% of final lines in the code base were his. What the LoC count won't tell you is all the refactoring, deletion, tests and error handling code I had to add, because his code only worked for the happy path. Can you say he was being 2x more productive than I was? I say no, because he was breaking the nightly build at least once a week before I joined, blocking the rest of the team, this ended when I added pre-commit tests.

ncmncm 5y ago
When the numbers are large enough, the details don't matter much. Maybe he is really only a 250x engineer? A 100x engineer? It doesn't change the fact that without him no product would have been delivered.
- sangnoir 5y ago
  > It doesn't change the fact that without him no product would have been delivered. I agree. I'm only arguing that there are times when engineers who enable "10x/100x" engineering don't get the visibility they deserve, sometimes until after they quit. This hits close to home for me as I witnessed my partner being showered with praise for being "super productive" based on LoC alone, code which wasn't close to being production-ready. If you don't care about code quality, and want to be seen by management/people outside of your team as a 10x engineer with minimal effort: you can follow the same playbook.
  - ncmncm 5y ago
    Agreed. It is rare that you can get objectively meaningful numbers. So, while it is convenient that half the code delivered was his, that is not the meaningful measure. When I was in school, the standard for engineer productivity was 10 lines of tested code per day, averaged. Maybe we do better today, with fewer footguns and faster compilers. But we expect more meaningful results from a line of code, too.
- Aqueous 5y ago
  no, no, no, no. if you deliver the product only by taking shortcuts that impede other engineers you do not get credit for ‘delivering’ the product. having been the next engineer to come along, this attitude drives me up a wall.

ncmncm 5y ago

When the numbers are large enough, the details don't matter much. Maybe he is really only a 250x engineer? A 100x engineer? It doesn't change the fact that without him no product would have been delivered.

sangnoir 5y ago
> It doesn't change the fact that without him no product would have been delivered. I agree. I'm only arguing that there are times when engineers who enable "10x/100x" engineering don't get the visibility they deserve, sometimes until after they quit. This hits close to home for me as I witnessed my partner being showered with praise for being "super productive" based on LoC alone, code which wasn't close to being production-ready. If you don't care about code quality, and want to be seen by management/people outside of your team as a 10x engineer with minimal effort: you can follow the same playbook.
- ncmncm 5y ago
  Agreed. It is rare that you can get objectively meaningful numbers. So, while it is convenient that half the code delivered was his, that is not the meaningful measure. When I was in school, the standard for engineer productivity was 10 lines of tested code per day, averaged. Maybe we do better today, with fewer footguns and faster compilers. But we expect more meaningful results from a line of code, too.
Aqueous 5y ago
no, no, no, no. if you deliver the product only by taking shortcuts that impede other engineers you do not get credit for ‘delivering’ the product. having been the next engineer to come along, this attitude drives me up a wall.