Christian Weiske wrote at 3/6/2012 2:47 am:So, what’s your definition of “passing the Joel test”? Full score? Good luck.
| « An XSS Vulnerability In The Making | The Mechanics Of Code » |
In my career as a software developer I’ve been lucky. I’ve been lucky that finding work has never been terribly difficult. The longest I’ve ever been out of work is a month and a half. Six weeks might seem like a long time, especially in software; in my case I was unfortunate enough to experience a two-week delay in my interviewing thanks to the Snowpocalypse of 2010 and the aftermath of that event. When I’ve actively looked for work I’ve been pretty fortunate to have a good resume, good skills, and most importantly, a strong job market for the particular field I’m in.
What I’ve often struggled with is finding the right job. There are lots of bad jobs out there; many developers are in them. I’ve been in them. You know the type: jobs that have managers who think that being salaried means they own your every waking moment. Jobs with non-compete clauses that would force you out of your profession if they were enforced. Jobs that advertise for “good under pressure” people or “detail oriented” individuals.
In programming, it appears avoiding bad jobs is harder than getting a job. How do we get the good ones?
Take The Joel Test
A long time ago I thought The Joel Test would save me from bad companies. As it turns out, plenty of bad companies pass The Joel Test, but it’s a great starting point for evaluating the quality of the team. Version control alone will not save you from working long hours on a death march, but it will save you from losing your work. A convoluted bug tracker install is better than no bug database, so long as the person responsible for running it isn’t insane. To this day I still start with The Joel Test as a starting point, because it provides some basic information. A company that doesn’t pass it is one I won’t work for.
Use Your Network
While there are probably thousands of people who write PHP code, chances are good that if you’re reading this blog you’re a part of the PHP community. This is excellent because it gives you a network. Most people in the PHP community know other people who work for, have worked for, or know of people who work for the company you’re interviewing with. Use this to your advantage! Find out from them what they think, how they feel, and what they know. It’s invaluable!
One of the companies I’ve worked with in the past also employed a friend of mine at a previous point in history. Had I availed myself of my network and asked about it in the first place, I would have saved myself a lot of heartache. Use your network! It will save you in the end.
Look For Red Flags
While it would be nice if something like The Joel Test could simply help us know if a company was a good one or not, this is simply impossible. It is possible to look for red flags, though, that can help us decide whether or not a company is one we’d enjoy working at.
I like to know a few things about a company that I’m applying to work at. Do I know their name from various conferences I’ve attended? What is their conference policy, both for attendance and for speaking? This is a good indicator about how willing the company is to invest in training and personal advancement. What is the company’s benefits package like? Believe it or not you can learn a lot by looking at a benefits package: companies that value the health and well-being of their employees often offer more generous vacation time and health benefits.
The questions you’re asked during an interview are just as important as your answers. Listen well. Are the questions technical? Are they standard HR questions? Who interviews you? There are red flags in certain question types: questions about how long you’re willing to work and whether you’re available on weekends. If anyone implies or says that the company has ever worked a weekend, think very carefully! You may find that working weekends is more normal than you first thought (Side note: my team has worked weekends and surely will again at some point. Working weekends isn’t necessarily the sign of a bad team, because my team is awesome. Teams that work weekends on death marches, however, have serious issues that need to be addressed).
Ask lots of questions. Get straight or complete answers where you can. Know where you’ll be working, how you’ll be working, and what you’ll be working on. Know what expectations are, and what opportunities there are for advancement. Know how specifications are written, and by whom (technical staff? non-technical staff?). While it’s best to ask questions about salary and benefits once an offer is secured, if you receive an offer make sure you ask! At that point they want you and you have every right to investigate if you feel the same way.
Look At The Code Before You Accept
Code can tell you a lot about a company. Some companies have huge legacy code bases that are full of code that was written, rewritten and held over from the PHP 3 days. Some have worked hard to clean up their technical debt and write their code in object oriented frameworks. Whatever state the code is in, it’s crucial that if you can, you take a look at the code before you take the job.
Bad code by itself isn’t a sign of a bad company, but it can be. For example, a company that has a team working on a product that’s heavily developed and critically important to their success, but is filled with bad code, it’s a sign that you will never have the time you need to write code of high quality. Code in varying styles of indentation or spacing shows a lack of consistency. Code without tests shows that they’re failing a critical piece of The Joel Test. Remember: this code is about to become your problem. You have every right to know what you’re getting into.
Some companies may be reluctant to give this kind of access to someone who isn’t a team member. This is understandable, and you should most certainly wait until an offer has been received to review the code. You may have to sign a non-disclosure agreement or agree to a read-only experience alongside one of their existing developers, in their office. Either way, since it’s about to become your job to work on the code, you should know as much as you can.
Imperfect List
This is by no means a perfect or complete list. And it won’t avoid every bad company out there. What it offers is some of the tried and true lessons I learned through The School of Hard Knocks. What are your tips for avoiding bad companies and finding the diamonds out there?
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 3/5/2012 at 5:14 pm
So, what’s your definition of “passing the Joel test”? Full score? Good luck.
Brandon Savage (@brandonsavage) wrote at 3/6/2012 9:12 am:
I define it as “meeting much of the criteria.” While some things are explicit dealbreakers (e.g. no source control) others are not. Mozilla is an open plan at the main office, for example, for everyone up to and including our CEO. Those conditions might not be seen as quiet by some, yet Mozilla is an awesome company to work for and I’ve been quite happy there. So it’s really a subjective call. There’s no magic bullets in this arena, but the Joel Test provides a great starting point to ask good questions.
Ben wrote at 3/9/2012 4:55 am:
I love my job, but my company would not pass this test. What to do? Quit? ;-)
The post is about finding a job, not about current job satisfaction. If you’re satisfied, no reason to leave.
Michal Ty wrote at 3/11/2012 8:06 am:
Same here about passing the Joel test :) When I apply it to our company the majority of his points are either not applicable or not realistic. The apps we create have short and hard deadlines, and are one-off things that run for a month or two and are never seen again, so we don’t do anything that can slow us down and code quality isn’t as important as being feature-complete on time.
If you develop an application that you sell as-is in a large company that has an office, in a language that requires compilation using expensive tools, I suppose Joel’s list makes sense. But how rare is that? :)
I think the most important thing is working with great people that you like and trust. I’d rather do something completely unexciting with great friends than travel the world with a bunch of dimwitted a**holes.
| « An XSS Vulnerability In The Making | The Mechanics Of Code » |