Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

From the amazon I know, people only care about a. not getting fired and b. promotions. For devs, the matrix looks like this:

1. Shipping: deliver tickets or be pipped.

2. Having Less comments on their PRs: for some drastically dumb reason, having a PR thoroughly reviewed is a sign of bad quality. L7 and above use this metric to Pip folks.

3. Docs: write docs, get them reviewed to show you're high level.

Without AI, an employee is worse off in all of the above compared to folks who will cheat to get ahead.

I can't see how "requesting" folks for forego their own self-preservation will work. especially when you've spent years pitting people against each other.



Not only is having too many comments on your PRs bad for you, but so is not leaving comments on other people's PRs. Both are metrics used


I'd leave lots of comments out of spite whenever I would feel my PRs had been treated unfairly. If I am going down, you all are coming with me.

I specifically look at the quality / substance of the comments when I'm reviewing someone for promo/transfer/fire.

Welcome to Amazon, you'll fit right in.

> 2. Having Less comments on their PRs: for some drastically dumb reason, having a PR thoroughly reviewed

I'm very far away from liking Amazon's engineering culture and general work culture, but having PRs with countless of discussions and feedback on it does signal that you've done a lot of work without collaborating with others before doing the work. Generally in teams that work well together and build great software, the PRs tend to have very little on them, as most of the issues were resolved while designing together with others.


I've been involved in so many CRs where I've given feedback over 10 revs, then the submitter cancels the CR and files a new one, for the metrics.

If the review tooling is any good, getting the code somewhere it can see it is a convenient way for people to give and receive feedback. As the saying goes, the system is what it does!

(And/but yes/no, I have never worked at NAGFAM...)


Eh I feel like there are some features where you just have to get in the weeds to even design it and the code review itself is part of the process of designing/figuring out the edge cases.

> Eh I feel like there are some features where you just have to get in the weeds to even design it and the code review

I agree, but those are separate tasks completely (in my view) compared to "Someone writes code that goes into production", usually called "spikes" or something else to differentiate them from "normal" tasks. They're quite literally just about exploration and figuring out the design, before the "real" work starts.


4. Don't work in the corporate equivalent of The Hunger Games.

At least in the past the idea is you do the dance , vest and leave.

I missed my FAANG chance during the good years. No retirement for me!


if someone responded with a lot of PR comments, I would set up a meeting directly and avoid unnecessary discussion on PR.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: