If you’re a hardcore software developer, kicking ass in your current gig but wondering just how far you could go, how do you pick your next gig?
For the past ten years, one of the most quoted and referenced sources on this question has been a post by Joel Spolsky of “Joel on Software” fame – The Joel Test: 12 Steps to Better Code.
When he first posted the test, Joel called it a “highly irresponsible, sloppy test to rate the quality of a software team,” and yet it’s been cited as gospel by programmers, investors and reporters – it’s even earned its own Wikipedia entry, acknowledging its usefulness as a due diligence tool
If you’re shopping for a new job, the Joel Test won’t tell you everything about the dev team you’re looking to work with, but it’s still a good, quick way to gauge some essentials.
As we’re on a major hiring push right now (and, note: we are always hiring great developers even when we’re not on a push), we figured it was high time we took the Joel Test ourselves – so you know what to expect if you want to work here. In typical Freshbooks style, we figured the test needed some freshening up – it is ten years old, after all.
So – here’s our updated version of the Joel Test. Twelve original questions, with FreshBooks answers, plus a few key questions you should ask before you join a dev team in 2010.
1. Do you use source control?
2. Can you make a build in one step?
Damn skippy. You have to be able to do this if you’re going to handle question three the way we do.
Rolling frequent code updates and hotfixes for a web app makes it even more critical that this is a simple, seamless process. Check!
3. Do you make daily builds?
Daily? How very Twentieth Century. Build and run unit tests on every commit. Build early, build often.
4. Do you have a bug database?
Of course. See Q1. We’ve just switched from Trac to Redmine, since we wanted to be able to track multiple projects, but still aggregate issues for releases. Redmine’s sub-projects features let us do that.
5. Do you fix bugs before writing new code?
Mostly, but it depends on all kinds of things. This answer can’t be binary. What you’re really looking for here is reassurance that there’s pressure to fix bugs. But a large-scale application is just going to find itself with bugs that literally aren’t worth fixing. So a better question here is: “Is there a credible champion for fixing bugs?” And at FreshBooks, the answer is: “Yes!”
6. Do you have an up-to-date schedule?
Mostly, Keeping a schedule up-to-date given the pace of change we maintain is a challenge. We manage two. There’s a high-level “roadmap” that outlines our top business priorities and in what order we mean to tackle them, and then we break down work into two-week chunks and plough through it, updating everyone’s expectations as we go.
7. Do you have a spec?
”Yes, but…” A spec doesn’t have to be a document. But there has to be a shared understanding of what’s to be built. At FreshBooks this is more likely to happen via conversation, prototyping and testing than by pain-staking maintenance of a rapidly-changing document.
8. Do programmers have quiet working conditions?
Not so much. FreshBooks thrives on collaboration and spontaneous contributions. This works well for some, not for others – so we’re figuring out some new options for the team members who work best in quiet solitude. In fact, we’ve just rented a chunk of new space that will be connected to the existing office. It’s large enough for the whole team and will be separated by glass from the current space. People will be able to choose between zen-like calm and frenzied activity.
9. Do you use the best tools money can buy?
Without question. We make monthly Amazon purchases to keep our bookshelves well-stocked with the latest thinking, and developers are welcome to select any sort of machine they want for their work. We even use the best tools money can’t buy – there are a ton of incredible free resources out there too.
10. Do you have testers?
Check. And they’re awesome. Doesn’t matter how hard core you are or how beautiful your code is, everyone misses stuff. Everyone. If your core dev team are testing their own code, they’re going to churn out crappy code. They’re “too close to the coalface” to see the problems. The FreshBooks dev team naturally take pride in sending really tight, solid code to QA. But it’s also key that they also have a killer QA team to trap stuff they might have missed.
11. Do new candidates write code during their interview?
We’d rather assess your natural talent than your knowledge of a specific language. A red hot coder can usually learn a new language pretty fast, so because we aren’t so picky about particular technologies, we don’t always get into code writing in interviews. Instead, we get developers to design systems for us, so we can appreciate both their technical design chops and how they go about framing and sharing their thoughts.
12. Do you do hallway usability testing?
Um… we don’t really have any hallways, but we do kitchen and foosball-table usability testing. And in meeting rooms. And at people’s desk sides.
OK, so that’s the original Joel Test. But if you’re hunting for a new code shop gig these days, what else should you ask?
Here are some more thoughts:
13. How much of your code is covered by unit tests? How do you measure that?
If you’re thinking of joining a shop that doesn’t take unit testing and code coverage seriously, prepare for a world of pain. Nothing makes it easier to change and refactor code than serious unit testing. But unit testing without formal code coverage inspection is only half the battle — you need to know, without guessing, how much of your code is covered, and whether or not that coverage is increasing over time.
14. Do developers TALK to users on a regular basis?
Why would you even want to build software if you never get to talk to the people who use it every day? A company that hides its developers and builds a wall between them and users is no place to feel good about the work you do.
15. Are developers able to contribute to open source projects?
Pretty much every company these days benefits from open source technology, one way or another. If you’re getting; you gotta be giving. Make sure prospective employers are serious about their relationship with open source — it’ll tell you a great deal about how they view their relationships in general. If their approach is just to take without giving back to the open source world, what does that tell you about their mindset and culture?
Now that you know how we do things around here, why would you ever want to work anywhere else?