3 ms·

I keep hearing this argument about "knowledge workers" yet writers produce books, designers produce design documents, developers ship code. sometimes you slow

I keep hearing this argument about "knowledge workers" yet writers produce books, designers produce design documents, developers ship code. sometimes you slow down because you're starting something new or you're blocked by other people, but in general productivity measured in code changes frequency / volume and the impact of the feature being worked on is rather straightforward (how many users use the feature, how much revenue it makes). 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.

twawaaay 4y ago
Developers do not just ship code. If you think developers only code you are naive and unfamiliar with developers' work. Developers solve problems and then ship implementations of those solutions. You can ship completely technically correct implementation to a wrong problem or wrong solution of a problem and it will look perfectly fine for an untrained eye. My O(n^3) solution that has 1000 lines of code would be 5 times more valuable than 200 lines of code of O(log(n)) solution that I was able to write because I just fucking know what I am doing. The algorithm using lines of code as proxy for productivity will say the junior jackass did 5 times more work than me in the same amount of time. And then you get the graybeard who changes a tiny bit in the data structure and makes entire problem go away. Find heuristics for that! Only a person that delves in and spends a moment figures out that that half million lines of code is completely unnecessary because of Y. The problem with measuring value of a knowledge worker is that you can't enumerate all possible outcomes to be able to tell with certainty that there is a better outcome, because you don't have the knowledge -- they have it. A person with knowledge has better library of possible solutions and better chance of finding it. The value of knowledge worker in this case is being able to find better solution (because they have the knowledge you do not). The implementation, at least in case of developers, is usually the simple part of the problem. Imagine you are in an unfamiliar city. You order a taxi and then spend 1h driving from A to B. The taxi is comfortable and the driver is perfect gentleman. You pay your fare and hop off at B. Only after the fact you will or will not realise that actually, B was just one block from A and the driver essentially screwed you. In this situation a map or instructions from somebody could tell you this, but with no map or instructions you are at the mercy of the driver who may or may not be doing good job and you will be unable to tell until after some time you got some more knowledge (got familiar with the city and got the Aha! moment).
- username_my1 4y ago
  same as the other response I specifically linked the change frequency to impact tldr: impact (feature $value * users using it) / change rate (frequency * volume) no need for long replies ;)
  - orbital-decay 4y ago
    You just refactored a piece of company software, severely reducing tech debt. Or made an in-house framework that made the others' work easier. Or mentored another engineer. By that formula you should be fired immediately.
deleted 4y ago
[deleted]
strix_varius 4y ago
> 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?

twawaaay 4y ago

Developers do not just ship code. If you think developers only code you are naive and unfamiliar with developers' work. Developers solve problems and then ship implementations of those solutions. You can ship completely technically correct implementation to a wrong problem or wrong solution of a problem and it will look perfectly fine for an untrained eye. My O(n^3) solution that has 1000 lines of code would be 5 times more valuable than 200 lines of code of O(log(n)) solution that I was able to write because I just fucking know what I am doing. The algorithm using lines of code as proxy for productivity will say the junior jackass did 5 times more work than me in the same amount of time. And then you get the graybeard who changes a tiny bit in the data structure and makes entire problem go away. Find heuristics for that! Only a person that delves in and spends a moment figures out that that half million lines of code is completely unnecessary because of Y. The problem with measuring value of a knowledge worker is that you can't enumerate all possible outcomes to be able to tell with certainty that there is a better outcome, because you don't have the knowledge -- they have it. A person with knowledge has better library of possible solutions and better chance of finding it. The value of knowledge worker in this case is being able to find better solution (because they have the knowledge you do not). The implementation, at least in case of developers, is usually the simple part of the problem. Imagine you are in an unfamiliar city. You order a taxi and then spend 1h driving from A to B. The taxi is comfortable and the driver is perfect gentleman. You pay your fare and hop off at B. Only after the fact you will or will not realise that actually, B was just one block from A and the driver essentially screwed you. In this situation a map or instructions from somebody could tell you this, but with no map or instructions you are at the mercy of the driver who may or may not be doing good job and you will be unable to tell until after some time you got some more knowledge (got familiar with the city and got the Aha! moment).

username_my1 4y ago
same as the other response I specifically linked the change frequency to impact tldr: impact (feature $value * users using it) / change rate (frequency * volume) no need for long replies ;)
- orbital-decay 4y ago
  You just refactored a piece of company software, severely reducing tech debt. Or made an in-house framework that made the others' work easier. Or mentored another engineer. By that formula you should be fired immediately.

deleted 4y ago

[deleted]

strix_varius 4y ago

> 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?