When evaluating folks for promotion or in general developer experience in terms of measuring productivity of an engineer (junior, mid-level all the way up to tech lead), how is this measured when building any one particular project for 3 months?
I see Alex talk a lot about # of commits when evaluating the work of a code machine and watched the course he had on code quality, but can we give a more concrete example of what would be considered a single commit in a day/week that is substantial enough to satisfy at as such for a responsive web app, or a native (Android/iOS) app on any particular project?
I am thinking of scope since a lot of the time I can build a prototype from scratch - everything sans deploying fully into production (for an AI project or some other responsive web / native iOS app) within two days (think hackathon style) but not completely sloppy or super polished, but something working/basic functionality (and that has a number of commits), but I think I'm having trouble grasping what number of commits on any particular stack is considered substantial in a single day/week and expectation wise per month or quarter on a intermediate vs. long-term project for two quarters or a year? I think I lack clarity and wonder if I will be as performative or hyper-perform compared to my peers (like I can code fast and even without using a CoPilot, but I wonder about code quality and depth rather than simply throwing something together or fluff commits - a bunch of installfest does not count, obviously).
Commit count has a ton of nuance to it. Meta in particular is unique as it's very metrics-oriented, and its culture is built to let engineers write a lot of code. Even at Meta though, there are many very senior engineers who will have super low commit counts like the Product Hybrid Staff Engineers.
When it comes to commit, here's how you should think about it.
It doesn't matter how many commits you spam if the quality is poor. If you're known for poor code quality at a company like FAANG, you're probably 80% of the way there to a PIP. The good news is that if you're truly prioritizing quality, the quantity should come naturally. That was my strategy at Meta as I talk about in-depth in my code quality course: Level Up Your Code Quality As A Software Engineer
It also doesn't matter how much code you're writing if all your commits are for low-impact projects that add 0 (or even negative) business value. Learn how to evaluate projects and ruthlessly prioritize the best ones. I talk about this in my productivity course: Maximize Your Productivity As A Software Engineer
Code volume will vary a lot based on its company and its culture. For example, the average commit count per half for a Meta engineer was around 125 commits. This makes a commit count of 250+ pretty impressive (double). At Google though, I know that the average commit count is far lower per half, more like 50-75. This makes sense as Google is a bigger, older, and slower company that also has to care far more about quality (there's a lot more government scrutiny around Google nowadays).
If you want to be known as a code machine, learn about the average benchmark numbers across your organization/company and beat that by a lot.
Are you looking to measure this for a personal project that you're doing on the side or within the bounds of a larger company that you're currently employed at?
Both, but mostly the side project as I expect that to be more technically complex than the other gig that's there just to pay the bills.