4 ms·

Facebook, for one. Source: I've sat in on meetings where engineers were ranked, with # of commits being a key metric. That experience taught me the importance

Facebook, for one. Source: I've sat in on meetings where engineers were ranked, with # of commits being a key metric. That experience taught me the importance of making lots of small commits, more than any readability concerns ever could :)

Loughla 3y ago
I work outside tech, but can you please explain how number of X would be a good measure at all? What would be the justification for counting anything as a straight number as a measure in a creative field?
- nine_zeros 3y ago
  > I work outside tech, but can you please explain how number of X would be a good measure at all? What would be the justification for counting anything as a straight number as a measure in a creative field? You answered your own question. Management doesn't want to view engineering as a "creative field". In their ideal world, they want it to work like an assembly line. And for decades they've attempted to quantify it like an assembly line. But as of 2023, management has never been more wrong. A good question is, "Why does management even desire quantification?" The answer to this is rather simple and unbelievable to most engineers toiling so hard. The answer is - management (of all levels) is lazy and unskilled. They want to demonstrate to their bosses that they are running an efficient ship. They quantify it with # of commits or other such proxies. This gets them their own promotions. They don't care if the company survives or if their reports are working on the right things or if engineering challenges differ from one project to another. The most important thing for all managers is - their own promotion.
- pjbeam 3y ago
  It isn't, at all. It's laziness on the part of management.
- bee_rider 3y ago
  In general it is considered good to make lots of small commits, a commit is a bundle of changes you send to the shared project, you want to keep them small so they are easy to integrate and debug (if necessary). But just counting them is a dumb way to judge productivity, and every programmer hates it. The way to become a manager at a tech company is to be good at programming for a long time, an extremely specialized skill set that has nothing to do with management.
  - bigbee 3y ago
    It's true that the way to become a software engineering manager starts at being a good engineer. The way to become a senior manager however is usually to be good at management.
- esrauch 3y ago
  So the thing is that volume of output is still important even in creative fields; if you run a logo design business and A makes the logos that satisfies 10 companies and B makes the logos for 1 company that is a pretty direct business outcome. There's counter-examples of the one logo was your whale customer that needs perfection versus 10 small businesses where you can just put the company name in a few fonts, but the raw volume of output is extremely relevant aspect of employee performance. With coding in practice the high performers who deliver business value are often (but not always) the same people writing a lot of code; low performers might only make a couple PRs per month while a high performer did a couple per day. The problem is that is more of a proxy outcome: it's also easily possible for a low performer to shovel out several negative-value PRs per day and for someone who does only a couple small PRs per month to be doing something difficult that delivers enormous value (especially if those few changes are like updating an ML model or finding key performance optimization opportunities).
  - nine_zeros 3y ago
    > if you run a logo design business and A makes the logos that satisfies 10 companies and B makes the logos for 1 company that is a pretty direct business outcome There's a flaw with equating this to # of commits or lines of code. That flaw is - the amount of revenue increases with the number of logos produced but the amount of revenue does NOT increase with the # of commits or number of lines produced.
    - evilduck 3y ago
      There's the clear connection to revenue potential between zero and one commits. I don't think commits and LoC are linear to someone's value to the codebase or org, but IME there's strong correlation between consistently low commits and lines of code output and ineffectiveness. Hard problems and low output happen situationally, generally not for quarters and years on end.
      - nine_zeros 3y ago
        > There's the clear connection to revenue potential between zero and one commits. But there is no correlation to revenue potential between 99 and 100 commits. And most companies are not stuck at the first commit. > Hard problems and low output happen situationally, generally not for quarters and years on end. Absolutely untrue. The hardest problems I have solved required me to build observability over 2 quarters, write RFCs and get buy-in from other engineers. None of these contribute to commits.

Loughla 3y ago

I work outside tech, but can you please explain how number of X would be a good measure at all? What would be the justification for counting anything as a straight number as a measure in a creative field?

nine_zeros 3y ago
> I work outside tech, but can you please explain how number of X would be a good measure at all? What would be the justification for counting anything as a straight number as a measure in a creative field? You answered your own question. Management doesn't want to view engineering as a "creative field". In their ideal world, they want it to work like an assembly line. And for decades they've attempted to quantify it like an assembly line. But as of 2023, management has never been more wrong. A good question is, "Why does management even desire quantification?" The answer to this is rather simple and unbelievable to most engineers toiling so hard. The answer is - management (of all levels) is lazy and unskilled. They want to demonstrate to their bosses that they are running an efficient ship. They quantify it with # of commits or other such proxies. This gets them their own promotions. They don't care if the company survives or if their reports are working on the right things or if engineering challenges differ from one project to another. The most important thing for all managers is - their own promotion.
pjbeam 3y ago
It isn't, at all. It's laziness on the part of management.
bee_rider 3y ago
In general it is considered good to make lots of small commits, a commit is a bundle of changes you send to the shared project, you want to keep them small so they are easy to integrate and debug (if necessary). But just counting them is a dumb way to judge productivity, and every programmer hates it. The way to become a manager at a tech company is to be good at programming for a long time, an extremely specialized skill set that has nothing to do with management.
- bigbee 3y ago
  It's true that the way to become a software engineering manager starts at being a good engineer. The way to become a senior manager however is usually to be good at management.
esrauch 3y ago
So the thing is that volume of output is still important even in creative fields; if you run a logo design business and A makes the logos that satisfies 10 companies and B makes the logos for 1 company that is a pretty direct business outcome. There's counter-examples of the one logo was your whale customer that needs perfection versus 10 small businesses where you can just put the company name in a few fonts, but the raw volume of output is extremely relevant aspect of employee performance. With coding in practice the high performers who deliver business value are often (but not always) the same people writing a lot of code; low performers might only make a couple PRs per month while a high performer did a couple per day. The problem is that is more of a proxy outcome: it's also easily possible for a low performer to shovel out several negative-value PRs per day and for someone who does only a couple small PRs per month to be doing something difficult that delivers enormous value (especially if those few changes are like updating an ML model or finding key performance optimization opportunities).
- nine_zeros 3y ago
  > if you run a logo design business and A makes the logos that satisfies 10 companies and B makes the logos for 1 company that is a pretty direct business outcome There's a flaw with equating this to # of commits or lines of code. That flaw is - the amount of revenue increases with the number of logos produced but the amount of revenue does NOT increase with the # of commits or number of lines produced.
  - evilduck 3y ago
    There's the clear connection to revenue potential between zero and one commits. I don't think commits and LoC are linear to someone's value to the codebase or org, but IME there's strong correlation between consistently low commits and lines of code output and ineffectiveness. Hard problems and low output happen situationally, generally not for quarters and years on end.
    - nine_zeros 3y ago
      > There's the clear connection to revenue potential between zero and one commits. But there is no correlation to revenue potential between 99 and 100 commits. And most companies are not stuck at the first commit. > Hard problems and low output happen situationally, generally not for quarters and years on end. Absolutely untrue. The hardest problems I have solved required me to build observability over 2 quarters, write RFCs and get buy-in from other engineers. None of these contribute to commits.