[bottle_roket]

Obviously it’s a huge company with thousands of teams, but I’ve been an engineer on 3 different product teams and certain things have been the same everywhere.

I would say purely from a coding perspective the workload is typical ~40ish hours a week. The stress comes from the biannual performance reviews that grade you explicitly across 4 axis.

If you got your projects delivered on time with high quality code that’s just 1 axis. What did you do to improve the codebase? What did you do to help drive the mission of the team? How many code reviews did you do(they count)? What did you do to improve the team culture?

I think these things are all important, but everywhere else I have worked a lot of these are more implicit. At FB you need to have bullet points and evidence of these contributions every 6 months to get a satisfactory rating. Couple this typical giant corporation red tape (legal, marketing sign off, metrics reviews) to getting anything released.

Some people seem to not have trouble keeping up with it, but I find it exhausting. I’ve gotten good reviews during my employment here but it’s been grueling.

[tdeck]

> How many code reviews did you do(they count)?

A friend who works at Facebook was telling me recently that since he gets judged explicitly on the code review count, he feels like he needs to immediately drop everything when a code review comes in so he can get to it before someone else approves and it gets merged. As you might expect, he finds that very disruptive.

[codewiz]

Well, what would happen if everyone prioritized writing code over reviewing their coworkers' code?

Since junior engineers and new hires are not yet able to review code effectively, senior engineers end up reviewing a lot more code than they write.

I think recognizing and rewarding this behavior in performance reviews is entirely reasonable for any tech company that wants a sustainable codebase.

[tdeck]

The problem isn't that code reviews get recognized and rewarded, it's that once a change is merged you can't review it, so people "race" to review changes before their colleagues get to it. That's not a healthy system. It's better to let people manage their time to promote flow, letting them batch up code reviews at a certain time of day if that's more effective.

I'll just add that nowhere I've worked has counted code reviews in this way and they still get done, so it's not a disaster when you don't officially penalize people for their review count.

[akomtu]

Those extra axes seem easy to fake. Just "review" all code reviews you see - takes 5 sec per CR and your metrics skyrocket. Mission of the team? Write some bs docs with vision and ideas: nobody needs them, but you get to mark the checkbox. Team culture? Say you've organized a book reading club, even do a couple meetings - just bring a book there and mark the checkbox. Books don't actually need to be read. Want to score some diversity points? Say your book reading club studied "white fragility" - nobody is going to verify you havent and nobody really cares, but you get to mark the checkbox.

[romanhn]

That wouldn't fly at FB. Doing busywork without producing impact doesn't count for anything. And CR comments are reviewed by managers - a bunch of LGTMs doesn't add up to much. It might unblock the team, but the goal is to uplevel the team, so meaty comments that impart knowledge are searched out.

[cutemonster]

I would have thought that people would start doing smaller and smaller change requests, collaboratively enabling each other to do more and smaller & quicker code reviews

True teamwork

[akomtu]

What's the incentive for those managers to take you down like that? Even then, you can write prose in comments - semi-related thoughts that are very difficult to distinguish from actually valuable comments.

[romanhn]

The incentive is the calibrations where the org leaders get together to compare notes and align on scoring. A manager who's not aligned would not only see their reports' scores forcefully shifted, but their own performance as a manager would be seen in a more negative light.

[sundvor]

This sounds like some different version of hell to me.

But hey, if you can make it work - and it sounds like you do - then all the power to you! :) I must admit I do like seeing the middle digit you're raising in their direction there.

(Edit: Even though CRs ought to be taken seriously, for the sake of your fellow engineers).

[zelos]

Goodhart's law in effect.

I once had a job where a portion of our bonus was related to an automated code quality score. Needless to say, we reverse engineered the algorithm and scripted the (pointless, probably slightly harmful) changes to the source to maximise the score.

[cutemonster]

What did and didn't the score algorithm like?

(Did you reverse eng it during work time :-))

[zelos]

There were several components, but the parts that were I can remember were gamed were code duplication - someone figured out the minimum number of matching lines required for it to be detected and made minor changes in the middle of blocks - and number of imports. The penalty for .* imports was quite low, so we just ended up with wildcard imports everywhere.

[cutemonster]

Ok :-) I'm surprised they were looking for duplicated code, interesting

[yeswecatan]

I feel like a lot of the anxiety around reviews is an unquenchable thirst for more. My understanding is that if you just meet expectations you get 100% of your bonus. If you're happy with your salary alone (which is probably higher than 99% of tech companies) then why get stressed?

[romanhn]

Meeting expectations is a pretty high bar to start with. The next lower rating (Meets Most Expectations) is a cause of stress because two of those in a row frequently results in a PIP at Facebook.