Diff count/LoC count is recorded and made publicly available for all engineers in a graph that lets you easily compare metrics between developers and teams. This means if you are constantly comparing your output to the rest of the team.
The multi-axis performance review criteria that requires you to show deliverables on things like your impact on team-building or culture. This means that when you might normally get a couple week low-output time between projects, you are usually looking for something to fill in the non-coding axis, like organizing a team virtual offsite event or searching for a way to improve the codebase.
Organizing team activities and code quality initiatives are a good thing, but the explcitivity in which you need to show deliverable impact on all axis is something I found unique to Meta and very exhausting.
Doesn't that just encourage writing code for max LoC rather than efficiency or maintainability? Instead of generalizing a procedure you use in multiple places to make it a single function, if you write it out (slightly differently) each time you do it, then you get a higher LoC count?
I mean people there aren't stupid and there is a fairly high engineering bar, your code won't get through review if you're doing stuff like that.
Where it really digs is when you are 1.5 weeks into writing an in depth project plan, meeting with other engineers, coordinating cross teams, researching, reviewing code etc. you better have a good explanation why your delivery over time graph has a big flat spot.
> Where it really digs is when you are 1.5 weeks into writing an in depth project plan, meeting with other engineers, coordinating cross teams, researching, reviewing code etc. you better have a good explanation why your delivery over time graph has a big flat spot.
That's 95% of what I do in my company. I guess by Meta's standards I'm not working?
That penalizes those implementing one line bug fixes buried in the codebase. Each one may be worth 10K lines of new code but numeric driven management will never know.
I've never experienced this at Meta. In fact I've worked considerably less intensely there than at my previous place, and I was considered a high performer in my team.
It comes down to the extreme focus on performance review. It creates an environment where every engineer is pressured to move some metrics like time spent on app, number of videos watched, or ad revenue. Because you're compared with your peers, you have to work a little more than them to maintain a good rating and stay in the race.
The multi-axis performance review criteria that requires you to show deliverables on things like your impact on team-building or culture. This means that when you might normally get a couple week low-output time between projects, you are usually looking for something to fill in the non-coding axis, like organizing a team virtual offsite event or searching for a way to improve the codebase.
Organizing team activities and code quality initiatives are a good thing, but the explcitivity in which you need to show deliverable impact on all axis is something I found unique to Meta and very exhausting.