4 ms·

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.

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 5y ago
> 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.
- deleted 5y ago
  [deleted]
- codewiz 5y ago
  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 5y ago
    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.
yeswecatan 5y ago
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 5y ago
  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.
akomtu 5y ago
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.
- sundvor 5y ago
  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 5y ago
  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 5y ago
    What did and didn't the score algorithm like? (Did you reverse eng it during work time :-))
    - zelos 5y ago
      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.

tdeck 5y ago

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

deleted 5y ago
[deleted]
codewiz 5y ago
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 5y ago
  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.

yeswecatan 5y ago

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

akomtu 5y ago

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.

sundvor 5y ago
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 5y ago
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 5y ago
  What did and didn't the score algorithm like? (Did you reverse eng it during work time :-))
  - zelos 5y ago
    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.