What is a healthy mindset that I can use when thinking about of code velocity?
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?
Discussion
(3 comments)- 2a year agoSenior Software Engineer [L5] at Google
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!
- 3
.png?alt=media&token=c14b9d84-f163-4292-9fa4-9dfd6090470c)
a year agoSenior Software Engineer and Career CoachI 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
- 1a year agoEngineer at Robinhood
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):
- Being proactive with testing (writing thorough test plans in pull requests and also writing tests)
- Lower turnaround time for putting up pull requests and merging in code. This usually means that you're getting more familiar with the codebase and the processes, so we should expect this to naturally decline as you're spending less time thinking and more time coding.
- The surface area of questions you ask to support your code is lower. You'll never stop asking questions in your career, but the question should be narrower and feel a lot less like you're asking someone else to effectively write your code for you.
