Per last performance review, how can I best demonstrate that I've improved since then to my manager?
I've gotten feedback from a mid performance review and my manager wants to see improvements in various areas. It includes improving my debugging skills by paying closer attention to pertinent details (and not getting distracted) for example.
Since then, I've become much more conscious and aware of the errors that I run into and much more deliberate in my debugging approach. This has resulted in me being able to diagnose problems much more accurately, and has also lended to me problem-solving much more effectively as well.
The problem is I'm not sure how to best demonstrate (or prove) that value improvement to my manager. Unlike PRs (which are often more visible in the value it demonstrates) -- you see what you get, my debugging skills/tactics are not readily obvious to the outside party unless they're observing my day-to-day activity. I can say that I've gotten better but if I have nothing to back that up with aren't they just words without weight? Who's to say that I'm even right in my own assessment without social feedback? I could be dunning kruger for all I know.
Is it enough for me to simply document those performance improvements and share (or talk about) them with my manager?
Note: My ultimate goal is to get promoted so I'm trying to (1) show that I've taken their feedback seriously and (2) demonstrate actual improvement since my last performance review.
Let me know if I'm thinking about this the right way or if am I overcomplicating it. Thanks!
Discussion
(2 comments)- 22 years agoRobinhood, Meta, Course Hero, PayPal
Like with code in general, there's 2 axes when it comes to debugging:
- Quantity - Are you fixing more bugs than in the previous review cycle? I imagine whatever you use to track work (e.g. Asana tasks, JIRA tickets) has some sort of tag for bugs, so you can get this high-level information.
- Quality - Are you fixing bugs of higher complexity that junior/mid-level engineers couldn't solve? Is your fix deeper and more holistic like in my case study about fixing a multi-million dollar bug for Instagram?
Something else I do when I debug is I am constantly generating a "paper trail". At Meta, we had an internal tool called "Tasks". So when I got a bug at Meta, I would write everything into the task.
New hypothesis on why it's breaking? Add a comment to the task.
Disproved a hypothesis on why it's breaking? Add a comment to the task.
Added some logs that yielded some juicy new information on the bug's root cause? Add a comment to the task.
By the time I finished the bug, I would have this clean journal of the process I used to arrive at the fix. I would share that in my performance review for really high-impact bugs I fixed, and if you have this same writing habit, you can do the same.
Lastly, I recommend these other resources on debugging:
- 22 years agoMeta, Pinterest, Kosei
How did your manager come to the conclusion that you could improve your debugging skills and attention to detail?
If you don't know, ask! You can even ask for examples: "I really appreciate your feedback, do you have an example in mind where I could have been faster with debugging?"
Getting this context is important since that becomes the way you can also demonstrate improvement. Like you said, you want to go beyond just feeling like you got better. Ideally it's something you have peer feedback about, or it's a quantifiable change.
If I had to guess, your manager probably delivered this feedback based on two inputs:
- Looking at your code changes and looking at comments from other engineers pointing out bugs, having a lot of back and forth in review, or your code being blamed for issues in postmortems.
- Peer feedback from other engineers about the above.
In either case, a good way to show that you take the feedback seriously is to show your work. (like Alex suggested) A few tactics:
- Can you go above and beyond in code review showing your proactive thinking and bug fixing?
- Can you do a review of your past changes and make a summary post about common mistakes you observed, and some tips for your teammates to avoid the same issues.
- Can you collect data (either from observation or looking at their work) on how other engineers on the team are able to debug more effectively?
