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