I am a junior engineer, and I am worried that the code velocity that I have right now, which is about 1-2 quality commits per week (By quality commits, I refer to ~100-200 lines of core code) is too slow.
I understand that not all code is the same, and code quality >> code quantity, and this job is a lot more than just coding. However, I am curious as to on average, how many quality commits would expect a junior vs senior vs staff to churn out in a week? Should one even be asking this question, is there a better way that I can frame my mentality towards this?
I wrote about this somewhat recently: https://www.linkedin.com/feed/update/urn:li:activity:7044932251666567168/.
In short, I think code velocity statistics are valuable and worth working on, but make sure you understand it's an imperfect metric and don't over-optimize for it. Ultimately, your goal with code is to do something useful ("impact").
Quality commits can be a few lines long, so I wouldn't index too highly selecting exclusively for those you mentioned that are between 100-200 lines in delta. It's best to just count the number of cls generally.
In terms figuring out what's "normal", the best way is to look around. Some code bases are much slower than others to develop in, often due to years of tech debt. If you can, pull up code velocity statistics from folks who code in your code base, who are probably going to be mostly folks on your direct team and adjacent teams.
Hope this helps!
I agree with Kuan's point entirely. I'll just add one major tip for improving code velocity:
Schedule pairing sessions with more senior engineers. First, ask if you can shadow them as they work on a feature. After a few times, ask if they would be open to shadowing you or working together on a feature.
The more important one is shadowing them though.
Take advantage of your time as a junior engineer to learn from your more senior peers about things you likely don't know you don't know. Things like interactions with git, navigating the codebase, finding edge cases, testing, verifying your changes, deploying, etc.
Do this and you will learn a lot on how to ship at a faster pace
Regardless of your title/role, the main way you should treat code velocity is "am I writing code at a reasonable velocity and quality to meet the expectations of my project and/or level"? If you're able to meet the timeline of the projects and sufficiently match the expectations of your level/next level (based off the expectations of your manager), just call it a day.
I'd expect a notable increase of velocity and quality for junior to mid level though, so I would look for these improvements (off the top of my head):