2 ms·

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 tur

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.

ptudan 5y ago
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.