Hacker News Reader

Comment by ptudan | Hacker News Reader

Amazon promos and firings are based a lot around the amount of lines of code you write, the number of code reviews you do (and the percentage of the time you review when asked), the number of merge requests you have, and the number of iterations per review. If you average more than 2 iterations per MR, you're on the chopping block as it means you're "sloppy".

Its ridiculously dumb. I've heard those numbers matter less as you gain tenure and seniority. But for the new grads and lower level engineers, all the savvy ones were gaming these metrics. It sucked to work in that environment and was a big reason why I left.

View on HN

I've never been seriously threatened with being measured by these metrics, but I have said that if I ever am, my next work task will be some code that takes a single commit and turns it into one commit per line of code changed.

If anyone complains, I will take the extra time to turn it into one commit per character of code changed.

You want commits? I can give you commits. It's not what I'd really like to do, but by golly, I can do it. Commits by the thousands, by the millions (whoops, did I just import a library and run my code over it? sorry), anything you like.

I've been thinking about doing something like that. You'd also want to space the commits over the day as well so you can complain about how you were up till 2 working on things and your commit history will bear it out.

My high school summer jobs was working the phone at an inbound call center, where there is a constant queue of customers calling and you answer each call in turn.

The software used would spit out individual metrics like "number of calls taken," and our supervisor used to look at that metric to make sure we were working and not slacking off at our desks, not on the phone.

People figured it out and would just pick up and hang up the phone ten times in a row to game the metric. In response, the supervisor started looking at "average call time" in addition to the number of calls, to make sure this wasn't happening.

So what people did instead would be pick up ONE call, and leave the line open for an hour, long after the customer had already hung up, in order to game that metric.

Seems like something similar could be done with these Amazon metrics.

Oh for sure. There were tacit agreements between engineers. Splitting MRs into 3 for "readability", adding nits that explicitly "could be fixed without another iteration", having your personal testing repo be public so any random commits you dump in there count.

And then on the even worse side, you have Amazon's stack ranking coming into play. Engineers can screw each other by blocking merges with needless comments, slow dripping reviews (eg problems that were in iteration 1 aren't brought up until iteration 3).

I won't deny that maybe I'm a paranoid person and that I read into patterns that weren't there sometimes. But the fact that those patterns could exist was enough to hurt my mental health to the point that I wanted to leave.

> Its ridiculously dumb. I've heard those numbers matter less as you gain tenure and seniority. But for the new grads and lower level engineers, all the savvy ones were gaming these metrics.

The company care more about weeding out the really bad junior engineers than it does about rewarding the good ones.

Honestly I don't have a big issue with that because I've seen what happens when bad people stick around. It's never fun for the good people, though.

Weeding out bad engineers is necessary. But these metrics are usually used to justify firings on the face than actually using them as an evaluator. Then the directors can pat themselves on the back that they fired someone justly.

Are you a manager at Amazon employing these or seeing your peers employ these metrics?

I've never heard of such a thing. It's leadership principles only AFAIK.

I worked there for a bit over 2 years, pretty recently. I heard this from other engineers and from managers not directly in my chain.

The iterations per MR metric is one I know for a fact is used in PIP docs. Heard this directly from a friend that was PIPed.

> I heard this from other engineers and from managers not directly in my chain.

OK so this is hearsay, your original post did not frame it as such, and you walk it back further here.

In addition other Amazon people seem to not agree, maybe don't post something like this next time.

I'm not making a legal argument here. I would never claim that I could verifiably prove these statements. However, I believe them to be true, and have personally heard from people who would know.

What I would tell you that is verifiably true, is that myself and other engineers all worked under the impression that these metrics were being used. Whether or not they actually were I cannot say for sure, but I can definitely tell you that it affected the culture.

The OLR process at Amazon is notoriously opaque. The HR and management at Amazon are notoriously smart. Amazon has a bad working culture (obviously, this is in my opinion). I would say that it is my duty to share elements of it that were bad for my wellbeing, to help others make informed decisions about their own futures.

Reply on news.ycombinator.com