7 ms·

If I'm understanding your example here, you're basically arguing in favor of per-piece pay rather than fixed. This has its own set of challenges, for example i

If I'm understanding your example here, you're basically arguing in favor of per-piece pay rather than fixed. This has its own set of challenges, for example imagine if developers got paid by the line of code rather than by the quality/efficacy of their code. Outside of physical item production jobs it gets tricky to make per-piece systems work without getting gamed to hell.

onlyrealcuzzo 5y ago
Possibly. You could also pay a salary and adjust it based on productivity. In theory, that's something like how raises and bonuses are supposed to work.
- zepto 5y ago
  Can you think of a transparent way to measure developer productivity?
  - onlyrealcuzzo 5y ago
    One possible option is to make ratings and pay public. If you think your rating doesn't make sense, or your rating does make sense, but your pay is lower than people with much lower ratings - then you have a case to argue. Of course - this could be just as nepotistic as the current system. But I think transparency is bad for nepotism long-term. Usually the most corrupt governments and organizations are the most opaque. Developers aren't really that different from bakers. You could bake 45 pies in 1 hour, and they could all be terrible pies that can't be sold, and you could burn down half the bakery in the process. In the same way, a developer could ship a bunch of features, but they could all be "half-baked" and a nightmare to maintain. You could also try to define metrics for what quality and productivity are. But people will just game that. Ratings can also easily be gamed or nepotistic.
    - zepto 5y ago
      I don’t see you answering the question. You don’t propose any mechanism for rating productivity, and you come up with some potential problems. > Developers aren’t really that different from bakers. I suspect very few people would agree with this. Only with an answer to this question does what you have argued so far apply to knowledge work.
      - joshuamorton 5y ago
        > I don’t see you answering the question. You don’t propose any mechanism for rating productivity, and you come up with some potential problems. They don't need to. As long as the system is transparent and everyone agrees to it, what it is doesn't matter. Performance based on lines of code? Based on peer evaluations? Based on users acquired? Based on meeting arbitrary goals your director sets that year? It doesn't matter as long as the evaluation criteria are predefined and available. Companies don't even need to use the same criteria, you can choose a company whose process you vibe with.
        onlyrealcuzzo 5y ago
        I don't think you need metrics like lines of code. > Based on peer evaluations? Based on their interpretation of how you hit metrics? Why not just look at the metrics directly? I think it's okay if ratings are subjective based on loosely defined job responsibilities. That's how it works at FAANG. Nothing is going to be fair. But I think it's better than just counting how many bugs you fix or how many lines of code you review or how many users your code acquires (which should be mostly determined by your product and design team's decisions).
        joshuamorton 5y ago
        I'm making a slightly higher level point: If some companies choose to make things strictly LoC based, that's fine (even though I think its a dumb measure). If they're transparent about that, and you prefer a FAANG-like "subjective peer eval based on loosely defined job responsibilities" approach, you can avoid the LoC based companies. There doesn't need to an objective, or even a best subjective, measure of productivity, as long as the company's chosen measure is transparent and preregistered.
    - chongli 5y ago
      You could bake 45 pies in 1 hour, and they could all be terrible pies that can't be sold, and you could burn down half the bakery in the process. In the same way, a developer could ship a bunch of features, but they could all be "half-baked" and a nightmare to maintain. You can inspect the pies made by your staff. Terrible pies that can’t be sold either look bad (misshapen, burnt, leaking) or taste bad (too sweet, not sweet enough, salty, over/undercooked). It’s not difficult to figure out. On the other hand, evaluating a developer’s productivity and quality of work would require a lot of code review which takes time and skill and also may require the developer to be present, wasting their time and lowering productivity. Push the review and eval process far enough and you really risk bringing down that developer to an unacceptably low level of productivity.

onlyrealcuzzo 5y ago

Possibly. You could also pay a salary and adjust it based on productivity. In theory, that's something like how raises and bonuses are supposed to work.

zepto 5y ago
Can you think of a transparent way to measure developer productivity?
- onlyrealcuzzo 5y ago
  One possible option is to make ratings and pay public. If you think your rating doesn't make sense, or your rating does make sense, but your pay is lower than people with much lower ratings - then you have a case to argue. Of course - this could be just as nepotistic as the current system. But I think transparency is bad for nepotism long-term. Usually the most corrupt governments and organizations are the most opaque. Developers aren't really that different from bakers. You could bake 45 pies in 1 hour, and they could all be terrible pies that can't be sold, and you could burn down half the bakery in the process. In the same way, a developer could ship a bunch of features, but they could all be "half-baked" and a nightmare to maintain. You could also try to define metrics for what quality and productivity are. But people will just game that. Ratings can also easily be gamed or nepotistic.
  - zepto 5y ago
    I don’t see you answering the question. You don’t propose any mechanism for rating productivity, and you come up with some potential problems. > Developers aren’t really that different from bakers. I suspect very few people would agree with this. Only with an answer to this question does what you have argued so far apply to knowledge work.
    - joshuamorton 5y ago
      > I don’t see you answering the question. You don’t propose any mechanism for rating productivity, and you come up with some potential problems. They don't need to. As long as the system is transparent and everyone agrees to it, what it is doesn't matter. Performance based on lines of code? Based on peer evaluations? Based on users acquired? Based on meeting arbitrary goals your director sets that year? It doesn't matter as long as the evaluation criteria are predefined and available. Companies don't even need to use the same criteria, you can choose a company whose process you vibe with.
      - onlyrealcuzzo 5y ago
        I don't think you need metrics like lines of code. > Based on peer evaluations? Based on their interpretation of how you hit metrics? Why not just look at the metrics directly? I think it's okay if ratings are subjective based on loosely defined job responsibilities. That's how it works at FAANG. Nothing is going to be fair. But I think it's better than just counting how many bugs you fix or how many lines of code you review or how many users your code acquires (which should be mostly determined by your product and design team's decisions).
        joshuamorton 5y ago
        I'm making a slightly higher level point: If some companies choose to make things strictly LoC based, that's fine (even though I think its a dumb measure). If they're transparent about that, and you prefer a FAANG-like "subjective peer eval based on loosely defined job responsibilities" approach, you can avoid the LoC based companies. There doesn't need to an objective, or even a best subjective, measure of productivity, as long as the company's chosen measure is transparent and preregistered.
  - chongli 5y ago
    You could bake 45 pies in 1 hour, and they could all be terrible pies that can't be sold, and you could burn down half the bakery in the process. In the same way, a developer could ship a bunch of features, but they could all be "half-baked" and a nightmare to maintain. You can inspect the pies made by your staff. Terrible pies that can’t be sold either look bad (misshapen, burnt, leaking) or taste bad (too sweet, not sweet enough, salty, over/undercooked). It’s not difficult to figure out. On the other hand, evaluating a developer’s productivity and quality of work would require a lot of code review which takes time and skill and also may require the developer to be present, wasting their time and lowering productivity. Push the review and eval process far enough and you really risk bringing down that developer to an unacceptably low level of productivity.