4 ms·

> developers ship code Developers ship solutions to problems, which often involves some code. A developer who solves the problem in a fast, cheap, maintainable

> developers ship code Developers ship solutions to problems, which often involves some code. A developer who solves the problem in a fast, cheap, maintainable way with an off-the-shelf package is superior to a developer who solves the same problem in a slow, expensive way with many thousands of lines of unmaintainable code. > but in general productivity measured in code changes frequency / volume Oh my. I don't even know what to say to this other than: - https://www.goodreads.com/quotes/536587-measuring-programming-progress-by-lines-of-code-is-like-measuring https://www.goodreads.com/quotes/536587-measuring-programmin... > anyone who argues against this is ether on the poor side of this measurement or work in a cash flush environment where no one cared about this If you can't point to the person on your team who's churning out mountains of crap because they think productivity is measured in lines of code, then...

username_my1 4y ago
it's funny that you felt the need to point out the first part of my argument and forgot about the second one. impact (feature $value * users using it) / change rate (frequency * volume) is a full enough overview of an engineer's output in a crude manner. if you implement a feature that makes 10$s per user for 100M users in 2 lines of code you're the best developer out there..... if you write 10000 lines of code to ship something that makes 0.005ct for 100 users ... you should not be employed. As an engineering manager I advice every developer to find a way to learn to measure their output because that is a good way for them to know their value (ask for a raise, move to a different company ...)
- unicornhose 4y ago
  > As an engineering manager Knew it. (Sorry for the snark, I know it’s unwelcome on this website, but rarely do I see something so indistinguishable from parody.)
- hnfong 4y ago
  I don't see how the change rate matters. If one line of code produces $1M of impact, should it be considered inferior or superior to a developer who produced a 100k line codebase with a couple thousand commits? But measuring direct impact to the bottom line for a developer is just confusing the roles of the business development team / sales team and the devs. As a manager, do you choose who works on which feature? If so, doesn't that make your subjective choice (on who gets to make the $$$ feature) the only metric that matters?

username_my1 4y ago

it's funny that you felt the need to point out the first part of my argument and forgot about the second one. impact (feature $value * users using it) / change rate (frequency * volume) is a full enough overview of an engineer's output in a crude manner. if you implement a feature that makes 10$s per user for 100M users in 2 lines of code you're the best developer out there..... if you write 10000 lines of code to ship something that makes 0.005ct for 100 users ... you should not be employed. As an engineering manager I advice every developer to find a way to learn to measure their output because that is a good way for them to know their value (ask for a raise, move to a different company ...)

unicornhose 4y ago
> As an engineering manager Knew it. (Sorry for the snark, I know it’s unwelcome on this website, but rarely do I see something so indistinguishable from parody.)
hnfong 4y ago
I don't see how the change rate matters. If one line of code produces $1M of impact, should it be considered inferior or superior to a developer who produced a 100k line codebase with a couple thousand commits? But measuring direct impact to the bottom line for a developer is just confusing the roles of the business development team / sales team and the devs. As a manager, do you choose who works on which feature? If so, doesn't that make your subjective choice (on who gets to make the $$$ feature) the only metric that matters?