Hacker News Reader

Comment by hncurious | Hacker News Reader

Result: git committing, excessively.

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.

sounds like hell, but at the same time, he is a legend.

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

Not only that, but other engineers apparently pointed out the gaming and management didn’t care.

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.

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

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

But that's my point. It shouldn't be a red flag on the candidate, and shouldn't need to be explained.

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.

“I made a mistake.” Easy. “Not a good fit”.

Nobody expects someone to get married after a couple dates.

Couple quick departures is alright, but I recently interviewed someone who was like 10 jobs in 8 years…

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

Thankfully, someone has already create a tool [0] for just this scenario!

[0] https://github.com/artiebits/fake-git-history

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.

I guess I should stop squashing my commits when I merge!

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.

"Bug fixes and performance improvements." Why blame the poor guy when even big companies do this.

And stop squashing.

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.

Reply on news.ycombinator.com