we all know and love the
joel spolsky's quick quiz to determine the quality of a software team.
if you're searching for a job, it's a great idea to run potential
employers through the joel test.
problem with it, though. well, there are multiple problems. first, who
the hell cares about hallway usability testing? second, you're only
checking for the good qualities of a team. what about the horrendously
bad qualities that will eventually drive you towards both insanity and a
crippling dependency on cough syrup?
need something like the joel test to measure the potential crappiness
of a job, or else each of us might stumble into becoming milton waddams.
and gentlemen, i present to you the codypo test, aka 8 questions to
identify a lame programming job. if you are in an interview, you give
the company the codypo test, and the job scores more than a 1 or 2, you
need to pull the fire alarm and get the hell out of there.
1. would i be paid below market rates?
they're looking for 10 years of hardcore, multithreaded c++ experience
and they're offering 48k, these people have lost their minds. expect
this sort of delusional thinking to appear in everything they do.
2. would i always be on call?
one likes being on call, because as soon as you're on call, someone is
going to page you at 3 am on a sunday because the reset button on the
support portal is a different shade of blue than they're expecting.
occasional on call stints are both understandable and tolerable, but
24/7 is for doctors and exorcists.
3. am i the it staff?
you are a programmer. you make software. you are happy to support your software.
does not, however, mean you are a computational master of the universe,
and just the guy to ask why the receptionist's laptop got all weird
after she installed that garfield screensaver.
4. would i work with a single monitor?
no longer 1998. we don't have to stare at a single 17" boat anchor all
day while rocking out to smashmouth. you can buy huge, thin lcds for
$100 each. if doubling your productivity isn't worth $200 to this
company, then this company may just be a really elaborate practical joke
played by an eccentric billionaire.
5. will i be maintaining any ancient system, and what's it written in?
you dig deep, you may hear, "yeah, we're going to get into ruby on
rails, but first, we'll need you to bust out some vb 4." it is never,
ever that easy.
that vb 4 system will refuse to die, just like rasputin.
6. would my internet usage filtered or monitored?
solve problems, and to solve problems effectively, you need resources.
the internet is the single greatest usage available. any company that
refuses to accept that and blocks you from usenet/ google/stack
overflow/whatever is treating like you a child/deranged porn fiend.
7. would i be the only programmer?
than anything else, i have grown as a programmer thanks to my peers.
we answer each others' questions, we review each others' code, we
whiteboard together, and we come up with creative insults when somebody
breaks the build. if it's just you, you're not going to get any
technical feedback and you're not going to get any better. also, you'll
only be able to insult yourself when you break the build, which might
get you reported to hr.
8. am i expected to travel every week?
bit of travel is necessary from time to time, particularly for face to
face meetings with customers or offsite colleagues. however, expecting
you to leave your home every farging week is absurd. we have the
internet now; it allows us to communicate
. let's use that instead of me becoming bff with the night receptionist at the best western.
think those 8 questions constitute a good sanity test for a potential
job. sure, there are valid reasons for a job to score a 1 (eg, you
might be the it staff or on call all the time at a startup). however,
once you get past one yes to these questions, it's time to leave the
interview through any means necessary, including faking a heart attack.
matter how great the potential projects and teammates might be, i don't
think you can do truly meaningful work in an environment where you, the
developer, aren't empowered to succeed. if a company doesn't get that,
then they don't get software.