What is a healthy mindset that I can use when thinking about of code velocity?

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

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!

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.