Performance reviews for developers
It just occurred to me that I’ve never had (or given) a really well executed developer-centric performance review, and it had me thinking about what should be in such a review. There are a lot of things that should be discussed in any performance review, I’m not going to go over those. I want to talk about the kinds of questions a developer and their manager probably ought to discuss at their review.
To me, the most important part of a performance review is to help the person getting the review get better at their job. It’s a chance for people to get feedback that will help them figure out which skills they need to improve and determine where they may be lacking in terms of professionalism. The second most important part of a performance review is to help the manager get as much value out of the employee as possible. Does this person work better undisturbed most of the time or regularly collaborating with others? Is this person happiest grinding away at hard problems that discourage most people? Do they like or dislike refactoring old code that could use improvement?
With that in mind, here are some questions that managers might want to discuss with developers in their performance review:
- What code that you wrote this year are you most proud of?
- What code that you wrote this year would you rewrite if you had the time?
- Did you work on anything this year that you felt was a waste of time?
- How was the release schedule? Did we release too often or not often enough?
- What skills got rusty this year that you want to get back to using?
The last thing I’d add is that I think annual performance reviews are really important. In many cases where programmers manage other programmers, they tend to be ignored or handled in a cursory fashion, but I think that’s a big mistake. So if you’re a manager, do your performance reviews and put some real work into them. Your employees will benefit, even if they don’t appreciate them.
No Comments Yet