Do your homework ahead of time. Learn what’s in the review process and especially who is expected to contribute to your review. Take a look at a blank review form to see the kinds of things you’ll be graded on.
About a month ahead of time, informally poll all the people you know who will be included in the process (including your boss) and say, “Hey, man, my review is coming up; how does it seem like I’m doing?” Do this in person, not by email. Make it seem easy and offhanded—not serious like a heart attack. Be sure to work on anything you hear that’s negative.
If your company has them, write your self-review with the formal review in mind. Be sure to focus on numbers and productivity (for example, “My applet makes the new build system go two times faster”), but never exaggerate.
All companies care about timeliness and quality as well as your ability to work both individually and as a team. Cover all those bases.
Think about the way your boss sees your job. If there’s something she doesn’t know about that’s important in what you do, be sure to mention it in detail.
—Mark “The Red” Harlan, engineering manager
want to reward the great, and…we’ll get to the other side later.
Raises in salary are usually tied to the performance review, and the raise budget is usually a fixed amount for the whole department. Assuming it’s been a good year for the business, the department is allocated a budget for raises. Let’s say it allows for a 3 percent overall raise. They could just give 3 percent to everybody and be done. Often, however, they want to give more to the stars (like 5 percent) and less to the slackers (like nothing).
Thus, we get back to the hapless manager: she has to docu-ment who are the stars and who are the slackers. Let’s look at common approaches used to create this document.
The Self-Review
The first approach is to punt the review to you. You get a form that says, in formalish terms, “What have you done
for the company lately?” Take this review very seriously:
there’s a good chance that much of its content will be copied and pasted into your official review.
As you go through the year, you need to be collecting mate-rial for the self-review. There are five major buckets to fill.
Quality
Here we want anything that can show you’re writing solid code: defect rate per line of code, bugs fixed, test cases written, and such. They don’t need to be hard measures:
positive comments from co-workers, design principles you started applying, or improvements you’ve made to your team’s test infrastructure are all helpful.
Examples: “Fixed forty-two product defects, including five severity-one defects.” “Consistently unit-tested code, with 2:1 average test case to application code ratio.”
Quantity
Fortunately, quantities are easier to measure: features com-pleted, product releases shipped, source code commits, and so forth, are good fodder. Don’t forget the version control system; it can give you lots of statistics about what you’ve changed in the code base.
Also, keep in mind that code is only part of your job. Any-thing that benefits the business is worth considering Examples: “Shipped version 1.2 of Widget Factory in my role as a widget programmer.” “Assisted customer support, providing key information to resolve four support tickets.”
Timeliness
You don’t get assignments without an expectation of when you’ll get it finished. Track your hit rate and—assuming it’s not terrible—report it in your self-review. This is much eas-ier in agile environments where you review progress every couple weeks.
Examples: “Delivered on project commitments with 82 per-cent success rate.” ”Completed tasks within 70 perper-cent of original estimates.”
116
•
Chapter 3. Manage Thy SelfCost Savings to Company
Programmers have a reputation for driving costs up rather than down. However, managers are always looking for ways to stretch their budgets, so if you have something to brag about here, brag.
Examples: “Improved message handling capability from 100 emails/second to 150 emails/second, thus making better use of company servers.” “Compressed data in less-used database columns, reducing storage footprint by 42 percent with negligible impact to performance.”
Making the Team Look Good
Your team’s value within the company isn’t just an equation like revenue contribution vs. cost. Perception counts just as much as any numbers. Any kudos you bring in for the team—and therefore your manager—are worth mentioning.
Examples: “Analyzed web server logs and identified top bounce pages; improved these pages and increased visitor retention.” “Improved GUI look-and-feel before important trade show, earning positive comments from company rep-resentatives at the show.”
Finally, one note about what not to include: don’t clutter the self-review with tasks that are considered business overhead.
“Attended 942 meetings” can be left off.
When you get the self-review form, ask your manager how much detail to include. If you’ve been good about logging accomplishments over the year, you’ll have more than enough content, so pick the best. If not, jog your memory by reviewing old email or scanning your commits in the version control system.
The 360-Degree Review
The next review-writing approach is to punt the problem to your peers. The manager picks a couple other programmers and a couple people from other parts of the company that have worked with you over the year.
Your manager may ask you for candidate reviewers. Who in the company has the best impression of your work? You
need to know, well ahead of time, who your allies are across the company.
Here’s where it pays to wander beyond the bounds of the engineering cubes, as discussed inTip 26, Know Your (Corpo-rate) Anatomy, on page 163. If you can reply to your manager with 360 reviewers that include your product’s support lead and product manager, for example, you’re well on your way to an awesome review.
The Manager’s Review
Finally, having as much of the review written by other peo-ple as possible, it’s the manager’s turn to craft the final review. It may be—like many reviews I received—your self-review with some annotations by the manager and a few comments from the 360 reviews tacked onto the end. Your manager isn’t getting paid to compose great literature here.
The review from your manager shouldn’t come as a surprise.
Any reasonable manager will be giving you kudos and tips for improvement throughout the year. The document you get handed should be a summary of those.
Ranking
Many larger companies require managers to rank their em-ployees. It’s the same thing as grading on a curve: the human resources department asserts that each team’s performance follows a normal distribution with a couple rock stars, a couple slackers, and a bunch of normal folks in the middle.
This will show up as something like a one to four rank indi-cating which quartile you’re in. If you’re in the not-so-great bucket, seePerformance Improvement, on page 119. Otherwise, don’t worry about it.
Here’s a dirty secret: every manager loathes ranking employees.
The manager puts a ton of effort into hiring an awesome team, and then HR comes along and asserts that the team must have a certain number of slackers.
Promotion
Some teams have designated technical leads or other promo-tion roles where you still program for your day job. Your 118