The Joel Test: 12 Steps to Better Code

The Joel Test: 12 Steps to Better Code

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

– Joel Spolsky (obviously!)

OK. Let’s get serious a moment. This is hands down, bar none, the single best recruiting tool I have EVER used. It’s also damn near the easiest. The trick is to put a specific reference to it in your job requirement bullet points. (Let’s be honest, most of those are boilerplate crap anyway. Seriously.) I’ve also had good success putting it right in the “intro” paragraph where I’m trying to hook ’em. I’d wager that would work less well, now that Joel isn’t as doing as much writing as he used too. (So sad!)

If the interviewee spends just a tiny bit of effort following the reference, they get a significant positive payoff. It’s something which helps them better evaluate companies and says something really positive about your company’s opinion about quality. Need to be a touch careful with this because it’s a bit like stealing “social proof” if you don’t actually adhere to at least a majority of these points. It will totally blow up in your face if you don’t truly believe it.

Here’s how I would answer it for my current company:

  1. Source Control? Git Flow. We love it! (And yes, Git Flow is a nugget reference as well.)
  2. One step build? Yup.
  3. Daily builds? Yup.
  4. Bug database? We’ve finally standardized on one.
  5. Fix bugs before writing new code? Yup.
  6. Up-to-date schedule? Yes, but very loose. (See Peopleware as to why.)
  7. Spec? Yes.
  8. Quiet working conditions? Yes.
  9. Best tools money can buy? Yes.
  10. Testers? We have external beta testers which we use rarely. No internal resources.
  11. New candidates write code during their interview? Yes.
  12. Hallway usability testing? Yes, but with end-users not other developers.

It’s interesting, as I re-read PeopleWare (edition 3), I can trace many of these concepts (not just #8) to this list. I just love how pithy it is. Makes that part of the interview so damn snappy. Makes the interviewee feel great which is also a super bonus, even if they didn’t find this nugget themselves ahead of time.

In fact, now that I think about it, I’ve hired 100% of the people who did find the nugget themselves. Even better, they’ve all been awesome hires and, in some cases, friends.