4 ms·

Result: git committing, excessively.

by hncurious 5y ago

ARandomerDude 5y ago
And stop squashing.
- lumost 5y ago
  I work at a company where code activity is reviewed from time to time by individuals who are at least somewhat familiar with the breadth of activity an Engineer does. Curiously, it's desirable to both have many PRs and few revisions - but also large ambiguous and difficult PRs. Obviously this can thus be gamed.
908B64B197 5y ago
Reminds me of someone. Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume. So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in. Inheritance? Polymorphism? Interfaces? Not in the generated code for sure. Duplicated code all over. Other engineers were furious but management kept defending him "he's just a junior and his metrics are off the charts, you guys just can't keep up with him". Three promotions in 18 months and jumped to a FAANG not long after.
- abledon 5y ago
  sounds like hell, but at the same time, he is a legend.
- geoduck14 5y ago
  If getting a promotion really is as easy as committing lots of lines of code, and you are THE ONLY one to figure it out, then you deserve a promotion
  - MattGaiser 5y ago
    Not only that, but other engineers apparently pointed out the gaming and management didn’t care.
    - 908B64B197 5y ago
      I think they were just reorganized when it happened? Or the company had been acquired. Anyways, it became the new way to evaluate devs not long after he joined.
- dxf 5y ago
  >Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume. Sorry to hijack your comment, but I would like to say: There are many, many good reasons why someone would want to quit a job after only a short period of time at a company (harassment being an obvious one). It took me a long time to realize this fact, and stop viewing a quick departure as a potential red flag and also stop asking questions like "Why are you looking for a new role?" Someone leaving a toxic environment really doesn't want to spend any part of the interview talking about the past; they want to show you they will be a valuable member of your team, while also learning if your company is one they want to work for. We should all consider that the next time we are reviewing resumes and interviewing candidates.
  - skeeter2020 5y ago
    It's still a red flag that needs to be explained. Unfortunately most employees will assume they did not leave voluntarily. The OP's reticence to jump is understandable
    - dxf 5y ago
      But that's my point. It shouldn't be a red flag on the candidate, and shouldn't need to be explained.
      - Clewza313 5y ago
        That's the way it ought to be, but unfortunately that's not the way it is considered by many in reality, so it's rational for a candidate to want to avoid that situation.
    - sjg007 5y ago
      “I made a mistake.” Easy. “Not a good fit”. Nobody expects someone to get married after a couple dates.
  - katbyte 5y ago
- aahortwwy 5y ago
  > So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in. I do this unironically. Mostly for producing unit tests from more sophisticated testing tools. I'm not silly enough to tell my coworkers that's what I'm doing, though.
mmh0000 5y ago
Thankfully, someone has already create a tool [0] for just this scenario! [0] https://github.com/artiebits/fake-git-history https://github.com/artiebits/fake-git-history
2muchcoffeeman 5y ago
I’ve worked with a guy who made lots of small commits with the same commit text. You’d look at a pull request with 30 very minor changes possibly in many places with the same message.
- _tom_ 5y ago
  I guess I should stop squashing my commits when I merge!
  - distances 5y ago
    Or rather, create team policy to require squashing. I greatly favor this over a million "fix" commits that may or may not compile when you're bisecting.
- hulitu 5y ago
  "Bug fixes and performance improvements." Why blame the poor guy when even big companies do this.

Result: git committing, excessively.

ARandomerDude 5y ago

And stop squashing.

lumost 5y ago
I work at a company where code activity is reviewed from time to time by individuals who are at least somewhat familiar with the breadth of activity an Engineer does. Curiously, it's desirable to both have many PRs and few revisions - but also large ambiguous and difficult PRs. Obviously this can thus be gamed.

908B64B197 5y ago

Reminds me of someone. Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume. So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in. Inheritance? Polymorphism? Interfaces? Not in the generated code for sure. Duplicated code all over. Other engineers were furious but management kept defending him "he's just a junior and his metrics are off the charts, you guys just can't keep up with him". Three promotions in 18 months and jumped to a FAANG not long after.

abledon 5y ago
sounds like hell, but at the same time, he is a legend.
geoduck14 5y ago
If getting a promotion really is as easy as committing lots of lines of code, and you are THE ONLY one to figure it out, then you deserve a promotion
- MattGaiser 5y ago
  Not only that, but other engineers apparently pointed out the gaming and management didn’t care.
  - 908B64B197 5y ago
    I think they were just reorganized when it happened? Or the company had been acquired. Anyways, it became the new way to evaluate devs not long after he joined.
dxf 5y ago
>Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume. Sorry to hijack your comment, but I would like to say: There are many, many good reasons why someone would want to quit a job after only a short period of time at a company (harassment being an obvious one). It took me a long time to realize this fact, and stop viewing a quick departure as a potential red flag and also stop asking questions like "Why are you looking for a new role?" Someone leaving a toxic environment really doesn't want to spend any part of the interview talking about the past; they want to show you they will be a valuable member of your team, while also learning if your company is one they want to work for. We should all consider that the next time we are reviewing resumes and interviewing candidates.
- skeeter2020 5y ago
  It's still a red flag that needs to be explained. Unfortunately most employees will assume they did not leave voluntarily. The OP's reticence to jump is understandable
  - dxf 5y ago
    But that's my point. It shouldn't be a red flag on the candidate, and shouldn't need to be explained.
    - Clewza313 5y ago
      That's the way it ought to be, but unfortunately that's not the way it is considered by many in reality, so it's rational for a candidate to want to avoid that situation.
  - sjg007 5y ago
    “I made a mistake.” Easy. “Not a good fit”. Nobody expects someone to get married after a couple dates.
- katbyte 5y ago
aahortwwy 5y ago
> So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in. I do this unironically. Mostly for producing unit tests from more sophisticated testing tools. I'm not silly enough to tell my coworkers that's what I'm doing, though.

mmh0000 5y ago

Thankfully, someone has already create a tool [0] for just this scenario! [0] https://github.com/artiebits/fake-git-history https://github.com/artiebits/fake-git-history

2muchcoffeeman 5y ago

I’ve worked with a guy who made lots of small commits with the same commit text. You’d look at a pull request with 30 very minor changes possibly in many places with the same message.

_tom_ 5y ago
I guess I should stop squashing my commits when I merge!
- distances 5y ago
  Or rather, create team policy to require squashing. I greatly favor this over a million "fix" commits that may or may not compile when you're bisecting.
hulitu 5y ago
"Bug fixes and performance improvements." Why blame the poor guy when even big companies do this.