Java Developer Performance Reviews

Despite years of promises to the contrary, I've found myself in the unfortunate situation of having to write performance reviews for my developers. For those other poor souls in this situation, I've collected my thoughts and present them here. This post is split into two parts. The first part I vent a bit, the second part has the useful content.

Before You Get Here

Warning: If you find yourself with a Technical Lead title and you would rather be doing technical things than dealing with politics, human resource issues, sitting in meetings discussing how to set up training programs or writing performance reviews, then keep your eyes open for how far you drift into management.

My experience has shown that nobody will understand that you aren't interested in pushing paper and you'd rather solve interesting problems. Find someone to take the management side of stuff off your plate yourself if you must.

The Technical Review

Since this review is for developers, I've focused my efforts on technical skills as super-smart developers tend to come with idiosyncrasies. Since those idiosyncrasies don't cause 3am phone calls about memory leaks, database deadlocks or network saturation, they're secondary to me. I wasn't given any guidance on how to do this, so if you've heard other ones, please comment!

Requirements

The start of most development processes involves gathering one, some, most or all of the requirements for whatever you're working on. Sometimes these are technical ("Make this code faster."), sometimes they're business oriented ("Add baseball support.").

I ask myself: How well do you handle vague or changing requirements? How well do you seek out the details you need? How much forethought do you have to determine potential problems and ask key questions to flush them out? How often do you misinterpret requirements? How good is your intuition or background reading on the task at hand?


Coding

The syntax, type usage, commenting, method names, scoping, etc of your code. Most senior developers will be naturally strong in this area, only sometimes suffering from a desire to use their own coding conventions or lacking documentation on more complex areas.

I ask myself: When others code against your APIs, how many problems do they have with documentation? When I read your code, how useful are the comments to me? Do you link to relevant other parts in the code? Do you leave waste in your code? Do you catch exceptions properly? Are your error messages useful? Do you (not) synchronize when you should(n't)?

Design

Beyond compilable code, there is an art to development.

I ask myself: How well does the code follow best practices (as they vary from year to year)? Do you use proper patterns when appropriate? Do you follow good OO design (encapsulation is a big one for me)? How well do you package your code? Is your code enjoyable to read? Are things intuitively in the right place? Do your classes do what you would expect (and nothing more)? Is your code testable, without he expense of it being usable?

Integration

Your code talks with other systems. How good is your "out of the JVM" skill? This includes networking, databases, security, message queues, mail servers, etc. Not everyone will have code that interacts with all other systems, so this section can be very specific to your environment.

I ask myself: Do you make proper use of the database? Do you cache query results? Do you try to use indexes when you can? Do you understand network concepts (ARP requests, DNS lookups, TCP / UDP, firewalling, NAT, latency, packet loss, TTLs, etc)? Do you handle database failures well? Do you consider what the effects of your code are on other components in the system? Do you understand (a)symmetric encryption and when to use both? PKI? Do you understand "be strict in what you send, forgiving in what you receive"?

Release

Not only does your code have to work and play nice, but it needs to make it out of the development sandbox and into the real world.

I ask myself: How often does your code gum up our load testing? How often does QA get stuck with your features? Do you forget to flag database updates for our release? Is your code backward compatible? Do you understand the effects of releasing your code in the real world? Is your code serviceable without hand editing web.xml and restarting our servers? Can it be monitored through our existing monitoring infrastructure? Would it make Michael Nygard happy?


Operational

Once your code is running in production, it may catch fire. If it does, this section deals with your ability to find the root cause and split your time coming up with a quick bandaid while ultimately fixing your bugs. If you don't have any code in production then I use this section on how well a developer finds and fixes bugs found by QA.

I ask myself: How quickly and accurately do you rule out red herrings? Do you have good troubleshooting toolset knowledge? Can you triage haystacks of log files to find the needle? Are you able to work around the issue creatively, or do you just rollback / reboot? When it's not your code, how quickly can you come up with a solution that doesn't involve a rewrite? Can you reverse engineer a cascading failure?


That's All

I hope this helps someone else out there that has been asked to do as I have. I'm curious to hear what others have done in the past. Oh, and of course, if this doesn't suit your needs, use something that does!