It's performance review season for me and the rest of the folks at General Assembly — a time of year that lends itself to introspection (along with a host of other emotions). Everyone approaches reviews differently: with trepidation, excitement, annoyance, indifference. I try to look forward to sharing feedback with my manager and teammates — it's great to have a process, as well as regular, dedicated time to reflect on personal progress and performance, measured in a way that's meaningful to me.

Though not all review processes include the exact steps or methods I talk about below, I believe that general ideas (honesty, self-kindness, and specificity) still apply. I'm not going to talk about giving feedback to others (this post is long enough already 😂), but instead focus on self-evaluation, goal-setting, and making good use of the feedback you receive. Below are some tips that I've found useful as I've gone through this process over the years — what to include, where to look for salient information about your performance, and how to use feedback you're given in a valuable way.

At GA, our performance review cycle looks like this:

1. Employees write a self-review and a review of their manager
2. Coworkers review each other (anonymously)
3. Managers review their direct reports (along with writing their own self-review)
4. Managers and employees meet to discuss all this feedback and talk about next steps

Self Review

The dreaded self-review! 😱 Even with specific questions outlined for me to answer, this is the hardest part of the process for me. Rather than writing my responses as paragraphs, I generally create an outline of bullet points and fill in relevant supporting details as I go.

Calling out the good stuff

Like many developers, I deal with impostor syndrome on a daily basis. Initially, it was very difficult for me to call out my strengths and accomplishments without anxiety (or immediately diminishing them in the next sentence). I still struggle with the fear of coming off as arrogant or overconfident when I list the things I'm proud of doing. Some things that really helped me out were:

Find concrete records of your past work

• If you use a system like JIRA or Trello to track what you do, you can use this to reflect on your completed work. A lot can happen in six months - chances are there are some accomplishments you forgot about hiding in that list of tickets!

• About a year and a half ago, I started tracking my daily to-dos in a markdown file (I use Bear, but I've talked to folks who use Google Docs, the Apple Notes app, and Evernote to great success). I also use this file to track "shoulder-taps" (day-to-day requests for help or clarification), meetings, and other tasks along with the approximate time I spent on them. This kind of low-level detail is fun and useful for me to look back over when I'm thinking about what I spent the majority of my time doing (and is a good place to see patterns!).

• If you don't have a robust work tracking system, try looking through work-related emails and dated documents. Chances are there's enough there to jog your memory!

Review past work artifacts

• This is mostly applicable if you're involved in creating documentation or putting together proposals/project briefs, but can also apply to PRs you've created and features you've helped implement.

Look at new skills you've picked up

• Maybe you converted your project's front-end to React from jQuery or debugged a hairy database problem; maybe you started working on server logic for the first time. Anything you've done for the first time should be recorded as a win!

• Go beyond technical accomplishments. Anything that affects your performance and value as an employee is fair game — leading a project, giving a talk, participating in mentorship, or writing blog posts (😉) are all important to factor into your overall performance.

Being honest about areas that need growth

Looking at parts of yourself that need to change can be a painful and humbling experience, but is absolutely essential to your personal growth. It's vital to know what needs improvement so that you can best focus your efforts on moving to the next level (personally AND professionally). Dan Abramov's recent post "Things I Don't Know as of 2018" was a really cool example of an incredibly accomplished developer assessing gaps in his technical knowledge. With a concrete list of things you want to work on, choosing goals becomes a lot easier.

It's just as important not to dwell on your shortcomings. Like any bug, they should be acknowledged, triaged, and eventually a plan should be made to address them. Here are a few categories I've focused on in the past:

Technical skills

• Is there a part of the codebase you wish you knew more about? Maybe you're interested in your team's deployment setup, but only have a cursory knowledge of what goes on. Do you want to work on application architecture skills or feel you lack an understanding of the tools you use on a daily basis? Anything you want to level up in is a good choice here.
• Remember to be very specific — "I suck at Ruby" or "I want to get better at deploying things" are less valuable than "I want to improve my understanding of OOP at a high level and make better design decisions in practice (example here)" or "I want to understand how we automate deployments and the steps that go into pushing new code to production."

Workflow improvements

• Everyone (well, almost everyone) says they need to get better at "time management." Drill deeper and question if that's really the problem. Maybe it's actually a problem with distractions, how you track your time, or how you plan out your day.

• Think about parts of the development process where you frequently feel friction. For example, I struggled for some time to get my PRs reviewed and merged in a timely manner. I made a commitment to let no more than two days go by without movement on a PR, and am proud to say that I've gotten much braver about reminding my coworkers that I need their feedback and much better about taking action on that feedback quickly.

Leadership & mentorship

• If you're interested in leading teams or projects, consider bringing this up in your review. Taking on even a small leadership role can be a powerful way to learn from your peers and demonstrate competence. For example, I took on the task of starting and leading our bi-monthly JavaScript "council" meetings at work. I was intimidated and anxious at first, but after some format failures and experimentation, we managed to find our groove! I love knowing that these meetings have real value to my coworkers (which also serves as a huge motivator to keep them valuable).

• Mentorship is a very personal goal for me. If you're excited about education or want to help mentor folks who are newer to the field, you should definitely set a goal to do so. It doesn't need to be formal, either! I've learned a lot from "unofficial" mentoring and being mentored, and it can be very fulfilling to give back to the tech community.

Setting Goals

All this reflection (combined with the feedback you get from others) means nothing unless you do something with it! Once you've had some time to process (and look over, if applicable) any feedback you receive, talk with your manager about what your focus will be for the next six months. Set three to five concrete goals based on what you, your peers, and your manager laid out in the reviews. Good goals are:

• Specific. Vague goals are harder to complete than goals with concrete acceptance criteria (much like work tickets 🤔). Consider replacing "Get better at Python" (for example) with a step you want to take in that direction, like "Attend two Python meetups a month" or "Finish that advanced Python course I bought three months ago."

• Focused. Set yourself up for success rather than trying to improve every single thing you can think of. The saying that "If everything's important, nothing is important" is applicable here. Give the goals you choose to work on the importance they deserve by giving yourself enough bandwidth to work on each of them.

• Personally meaningful. Avoid choosing goals based solely on what your manager/another party thinks you should do — or what you think you're supposed to choose. If your goals aren't truly yours, your motivation to complete them will be lacking (and they'll be more likely to go undone because of it). Even worse, you're choosing to invest your time in something you might not care about instead of something you're really excited about. (One caveat here: if your manager tells you that you need to work on something, you should absolutely work on it — and work on understanding its importance to your daily work.)

• Out of your comfort zone. Don't be afraid to push yourself a little when setting goals. You might be surprised to find what you can accomplish in a single review period if you set ambitious goals! Do work with your manager to make sure they're attainable, though. For example, it might not be practical for you to give four talks in the next four months, or read ten new programming books (or maybe it is!). Just make sure you're got the time and support to achieve what you set out to do.

At the end of the day

Whatever your experience with performance reviews has been or what the process at your company looks like, I hope these tips are helpful to you. It's worth noting that this advice works best in organizations with a healthy, candid feedback culture. As with any bundle of advice, please use with caution and awareness of the environment you operate in.