[​​White Belt] Your performance review isn’t for a year, but start logging your accomplishments early.

Consider the poor, hapless software manager: once a year she has to write reviews for all her employees and try to state, in objective and quantifiable terms, how they did on a job that’s intrinsically abstract.

Attempts to quantify programmer performance have never gone well. For example, the junior manager might try to measure how much code a programmer writes. During Apple’s get-it-done push to ship the Lisa computer, managers decided to track the lines of code written each week by each programmer. Bill Atkinson reworked a good amount of the graphics code, making it simpler and much faster​—and also shorter. He logged negative 2,000 lines of code for the week.^[31] What does a manager do with that?

Of course, that’s your manager’s problem—mostly. It becomes your problem when it’s your performance they’re trying to measure and your paycheck that’s affected.

When it’s time to review your performance for the year, you have one essential goal: you need to give your manager the best information possible so you get the best review possible. This has nothing to do with greed; it’s simply making sure she’s aware of your accomplishments for the year. You’ve worked hard, so get credit for it.

Performance Review Mechanics

Companies do performance reviews for obvious reasons: they want to identify who’s doing great and who isn’t. They 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 document 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 material 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 completed, 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. Anything 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 easier in agile environments where you review progress every couple weeks.

Examples: “Delivered on project commitments with 82 percent success rate.” ”Completed tasks within 70 percent of original estimates.”

Cost 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 representatives 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 in Tip 26, ​Know Your (Corporate) Anatomy​. 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 people 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 employees. 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 indicating which quartile you’re in. If you’re in the not-so-great bucket, see ​Performance Improvement​. 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 promotion roles where you still program for your day job. Your recent performance reviews will absolutely factor into discussions of promotion.

There’s one additional factor you can influence: you need to act the role before you can get it. For a tech lead, that means a wide breadth of knowledge, sound design decisions, helping others get the project to its next milestone, and the like.

When your manager is looking for a tech lead, she’s going to gravitate to the programmer she can most easily visualize in that role. If you’re already serving in a fashion that’s similar to a tech lead, guess who goes to the front of the list?

Actions

• Create a file, paper or electronic, where you can keep a log of accomplishments for your next performance review. Finish something on time? Make a note and file it. Solve a gnarly bug? File it. Mine this file when it’s time to write your self-review.

• As review time approaches, consider who you’d want to give you 360 reviews, and have those ready if asked. Pick two people from your team, two from other departments. Don’t just pick friends—pick people who you’ve done meaningful work with.

• About a month ahead of your review, ask your manager directly, “Since my review is coming up, how am I doing? Is there anything I can improve between now and then?”