Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

This question already has an answer here:

Many companies have annual reviews and/or performance appraisals for their employees. I've heard that it's generally a good idea to muster up some hard data to analyze and bring to the review. The better the data, the better the chances to help support a promotion or raise.

What I mean by hard data, are tangible numbers-- something that can be measured and/or calculated. Obviously data that a developer would have access to.

Something intangible would be how beautiful the code a developer has written. I think this would be very hard to measure, nor would upper management care for it.

My question is: For a software developer, what kind of hard data should be analyzed and brought to a review to help highlight good work that was done?

An example I've been given in the past: The support tickets produced by each project a developer was involved in. Are the numbers low? Are the rate per month getting lower? Etc.

share|improve this question

marked as duplicate by gnat, Kilian Foth, thorsten müller, Martijn Pieters, Jalayn Apr 11 '13 at 12:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

I recommend keeping track of what noticeable things you've done, like: coming up with a good solution to some problem, helped out your colleagues on different occasions, delivered high quality (low bug count) when a milestone was near, or other similar examples that connect to some criteria over which the assessment is made. – Andrei Vajna II Feb 10 '11 at 15:40

7 Answers 7

up vote 16 down vote accepted

I disagree with this premise and would probably avoid it unless my management had specifically requested it as the metrics are too easy to game.

Metric based evaluation is best kept to areas where something concretely measurable is deficient with an individual.

Too much of the job is not measurable this way for this argument to hold much ground for me. Usually a significant portion of the most valuable folks look bad with this type of measurement and a decent manager knows this.

Support staff is one area of exception as response time and catching issues before they become problems are very hard to game and quite measurable.

share|improve this answer
+1: If you do your job to the best of your abilities you most likely won't have to worry too much about performance reviews. Also not being a jerk is always a positive. – Lucas McCoy Feb 9 '11 at 7:33

While it sound like a good idea to have hard data I would advise against it. Things like builds broken, builds fixes, lines of code contributed and so on are pretty meaningless without context for each change. You would look desperate to me if you need numbers to proof that you are doing a good job.

It is much better to have references like good feedback from peers or people you work with as well as e.g. customers and so on at hand. Of course you also need to know where you played a key role in terms of contributions.

In the end though... either your manager knows these things already because you have a good communication so it wont matter too much or if they dont know a quick review and meeting wont safe you either. It just helps to reiterate successes they already know about.

So keep the communication flowing all the time then you wont have to scramble for numbers when review time comes around.

share|improve this answer
It seems entirely reasonable to assume that even good managers trying to do performance reviews for a dozen direct reports are going to need reminders about your particular accomplishments at your annual review. Given that, reminders that have a numeric component are likely to be more meaningful than the random feedback you may get from customers. Saying that you implemented a change that decreased support calls by 30% or reduced downtime by 10% probably means more than the "Very cool! Thanks so much!" email the customer sent you after the change went live. – Justin Cave Feb 8 '11 at 23:33
So how are you going to come up with these numbers so that they are even remotely true and reflect your input in a team environment? I doubt thats possible... – Manfred Moser Feb 9 '11 at 0:17
It depends on the strengths you want to underscore. Perhaps you closed 40% of the bugs/ stories on a team of 4. Perhaps you tuned a process saving 15 seconds on an operation CSRs do 10000 times a day @ $9/hr. Perhaps you were on one project where the team saved $x and a second project where the team saved $y and you claim a personal contribution of 0.25*x + 0.2*y. Remember that you're often giving your manager ammunition to plead the case to his manager that the entire team deserves high ratings or/ extra $-- numbers are more persuasive as you go up the ladder. – Justin Cave Feb 9 '11 at 2:02
All those number you come up with are highly subjective and therefore imho of not much value at all. I understand that these number can portray value, but imho they can just as easily get you into trouble for twisting the truth. E.g. you close 40% of the bugs .. those are all going to be of different complexity and workload. You will also have taken a different amount of help from others for them and so on. Or you could have just done the closing of the bugs and not actually the development. So really the 40% number does not mean much at all. And that applies to pretty much all metrics.. – Manfred Moser Feb 9 '11 at 4:29
@Peter - Which is why it depends on the strengths you want to underscore. It would be silly for a manager to state at the beginning of the year that performance would be based on the number of tickets closed; that would clearly lead to people gaming the system. A developer looking back on their performance has a much better chance of determining that a particular metric reasonably measures their impact. The support guy that is closing tons of tickets with excellent response time underscores that. His colleague that solved dozens of impossible cases would underscore a different metric. – Justin Cave Feb 9 '11 at 14:32

If you can get the data from the sales, marketing or finance department, how much revenue your products are bringing in to the company (or are forecast to), and for your own part, the percentage of features (from source control checkin logs), bug fixes (from the bug reporter system), support tickets resolved, etc. you were personally involved in contributing.

Added: If you can't justify your own worth to the company in terms of the financial bottom line... might be time to update your resume just in case.

share|improve this answer

Where I work we are encouraged to give specific examples to support our ratings when we do a self-evaluation at the end of the fiscal year. Thus this is more about specific stories and concrete examples than giving a statistic that may not be as meaningful for some people.

The Econ 101 Management Method is an article by Joel Spolsky that may be useful here in showing the caution about using metrics like minimizing bug counts or support tickets.

share|improve this answer

Wanna know a dirty little secret from the inner circles of management? You can't tell anyone I told you.

Your promotion/raise is already a done deal before you even hit the chair for your annual review. Technically it isn't supposed to be that way, and HR pays lip service to the fact that the content of your review is input for the promotion/raise decision, but that just isn't true anywhere I've worked. I pretty much already know (at least approximately) how much budget I've got for raises by the time I write the review. Sometimes I have the overall budget as much as 10 months before the review. So essentially the performance review is an exercise in making your evaluation fit the raise you already know they are getting. This is pretty much why performance evaluations are useless, in my opinion.

Note: There are some exceptions. If an employee can make a really strong case, I can sometimes go back to negotiating my budget somewhat, but is politically challenging at best to go back to the well and ask for more. Of course, this assumes that you bring facts to the evaluation that are completely unfamiliar to your supervisor. If your supervisor is paying that little attention to your work, you probably ought to consider moving on anyway.

share|improve this answer
This is very true, but I have worked places where the budget that is set in advance is for the group not the individual so the group's manager has some flexibility in how to allocate it. – Bill Feb 9 '11 at 16:10
I agree that the budget is generally set at the group level. However, the system forces the manager to "pencil in" each person's raise to get a feel for how the aggregate will work out, it is easy for them to get locked into to their initial numbers psychologically. – JohnFx Feb 9 '11 at 16:15

Bring whatever evidence makes the best case for your particular abilities and contributions.

If you were a part of the project that deployed the giant new ERP system, looking at support tickets generated is likely going to be a poor metric for you. In all probability, there was a giant spike in support tickets as people who were unfamiliar with the new system tried to figure out how to do what they used to do in some other system in the new system. Plus, users are generally more likely to raise issues with new systems rather than old systems whose warts everyone has learned to live with. A spike in tickets a reflection of a major change not necessarily a reflection of a poor implementation. On the other hand, if your primary responsibility is the maintenance of an existing system, then a declining bug rate might well indicate that your changes are having a positive impact on the business.

Dollar figures are always helpful but those are the most difficult to get. If your company sells software products, the new features you worked on probably drove some number of new sales that netted the company some amount of cash. It may take a bit of work to approximate that sort of number, though, and it gets harder as the company size increases. If you are in an internal IT department, the project manager may have done an explicit cost/ benefit analysis on each project to quantify, say, the productivity improvements that a new system would introduce. Using those numbers as a starting point to quantifying the business impact of your code is a great starting point.

share|improve this answer

The only kind of hard data that may matter is if you can prove a direct relationship between your work and savings or gains. This can be cost or time benefits (time is money). Is there anything that you significantly contributed to to improve efficiency at work? Can you measure this?

The rest is all soft. How do you work in your team, do people ask you for help, do they need your help, have you proposed new ways of doing business that make it better in some fashion, how happy are your customers (before you joined, at the start of your work, and now)... ?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.