How can I demonstrate velocity as an L3 transfer hire?
I joined this new team in October and I'm finding it hard to demonstrate velocity as an entry-level developer. I'm sure this has been discussed before on this thread but what are some sure-shot things to do to increase my commit count?
I know this isn't the healthiest way to approach things but commits and reviews are the best way to demonstrate impact at the L3 level and I'm trying to maximize my impact until the end of this year.
How can I add code quickly? e.g. Add extra unit tests for edge cases, add logging statements, etc.
Discussion
(2 comments)- 2a year agoMeta, Pinterest, Kosei
If you haven't already, go through the recent session about writing a lot of high quality code quickly.
Two things I'll call out explicitly:
- Spend the extra time to break down your own code into small chunks, and get each one reviewed. Makes life easier for your reviewers, and you are able to land more commits.
- Follow the code changes on your team. If you notice patterns you can improve, or bugs/style improvements, these are often easy code changes for you to make.
- 1a year agoRobinhood, Meta, Course Hero, PayPal
Meta-point: Don't worry too much about this as you just joined the team 3 months ago, and I imagine it wouldn't be a huge factor in your performance review (clarify this with your manager though).
How can I add code quickly? e.g. Add extra unit tests for edge cases, add logging statements, etc.
At Meta, we called this kind of work "Better Engineering", and this is usually great work to do during this time (holiday season) due to code freezes. Back at Meta, I would churn out a lot of these diffs during December, and I pushed all my mentees to do the same.
That being said, you don't want to hop into a negative extreme here and write pointless code. I remember back at Instagram, an engineer extracted a null check into a utility method and wrote a unit test against that: That's just useless and slows down the testing suite. Try to find genuinely impactful work here, which I talk about more here.
For your 2 specific examples about commit ideas:
- Writing tests: Are there sections of the codebase that have historically seen regressions? Maybe they regressed so badly a SEV occurred? If so, write unit tests there. Aside from this, you generally want to write tests in code areas that are regularly changing. The legacy module that hasn't been touched for 5 years and won't be touched for 5 more is probably not going to regress - You don't want to write tests against this kind of code.
- Adding logs: Are there some metrics your team would like that needs more logging? Are certain types of bugs hard to debug due to a lack of proper information around the code flow? If so, add logs here. Similar to tests, it's really easy to add useless logs, particularly around areas of the code that are stable and never produce unexpected results.
