Meaningful Certification is Hard

When I read Raganwald's post on certification a while back, I was impressed by what laid underneath the surface. What he's looking to certify out of the gate is a first-pass cut to weed out the scrubs and find people with a shared set of values that is not up for discussion - no matter what you're doing or how you're doing it, if you can't prove that you're doing it correctly and safely, it hasn't been done. I like the idea because it implicitly weeds out the people who can't program all that well in the first place; if getting it to compile is a chore, tacking on unit tests and being able to talk coherently about why injection attacks are rendered irrelevant is certainly going to be beyond your means. If it's a certification done on a small scale, you're going to be finding an exclusive group of developers and you're going to have a high degree of confidence in any of them and as such, you've pretty much rendered the cover letter+resume then let's small talk thing moot - you're hired.Of course, this ignores a harsh reality. If there's an economic incentive to having that certification, there will invariably be ways to game the certification. I've interviewed (and worked with) enough incompetent but acronym-accredited developers (IBAADs, copyright MEEEEEEEE) to pay certifications little mind at all. They're not bad, but all that's being certified is that the person's achieved some encylopediac familiarity with the terms of the field rather than a true understanding of how and when to apply them... more on that later.

More recently, Joel's posted about just how lame undergraduate programming courses are. Did you know that people come out of school patently unprepared to do development work? This is, frankly, SHOCKING. That last sentence was, frankly, sarcastic.But don't despair people - software is hardly the only profession where this sort of thing is endemic.

I'm friends with some lawyers and I generally hear the same thing - going to law school and passing the bar is tough, but all it does is certify that you've achieved a base level of competence; they come out of the process thinking that they're ready to take on the world and are pretty immediately humbled when they realize just how unfit they are to do any lawyering. It takes 18-24 months for a freshly bar'd lawyer to be able to do much of anything beyond researching case law, being mentored by more experienced lawyers most of the time. Doesn't this sound familiar?

I can't help but see the similarity with getting my degree in information systems - I graduated with good grades (cum laude, what!) and was sure that there wasn't anything I couldn't do. I look back on my first few jobs/years of professional work and shudder at how awful of a developer I was. I look back on code I wrote a year ago and shudder at that too. At this point I don't think that any amount of education could fulfill all values of "rigorous and practical", let alone most of them. This isn't to give JavaSchools a free pass or whatever, because I've interviewed people from them and their abject lack of passion for the craft is a ferocious turn-off for me.

In that regard, I'm with Joel. I don't expect that people are going to step out of school ready to do it all (not gonna happen) but I do hope that they'll have been exposed to more than one way of doing things. In my time, I brushed up (and a few hours a week for a couple of months is about all that I got in most cases) against x86 assembly, C, C++, COBOL and, yes, Java in my four years of college. I'd like to think that I took a little something away from each of these languages about how you can make software work and the lack of LISP or some other functional language is the reason I'm learning Haskell and going through The Structure and Interpretation of Computer Programs these days.

Lawyers go through as much college as I did and then 3 more years on top of that and then a certification on top of THAT and at that point, they're still so green that they require a year or two of more or less intensive mentoring to become productive. Word on the street has it that doctors do all that, except that they're putting in hundred hour weeks while they're mentoring to boot.

I understand Joel and Raganwald - I wish that there was some way to certify that the developers have a shared set of values, a shared passion and a capability to rise to the task that's put in front of them, but looking for this to come from schooling or certification is, or so it would seem to me, praying for a magic bullet.

And even those JavaSchools that churn out mediocre developers serve their purpose - we can't all be superstars. A great certification or four years of a great school won't turn mediocrity into a hacker god, and not every piddly project needs a superstar developer. Certifications and education are both fine signifiers, but it'll take something more rigorous than either to signify what we're all after.

Code Smells - Developer Literacy

Continuing on the subject of interviews, if I could give one piece of advice to people job-hunting, it's this - proofread your resume. It isn't hard, honest. If I could give another piece of advice to developers actively writing code, it's this - proofread it.

When hiring time comes around, I have no trouble whittling down the candidate pool. A middle-of-the-road candidate is getting tossed if their resume has misspellings or glaring grammar errors. My grammar's awful enough that I wouldn't know a dangling participle if it hit me in the face (I know that they're bad, do I win a cookie?) but I do know to avoid tense shifts and other obvious biffs.

But developers write in code, not in English! Surely this is a case of the narcissism of minor differences!

I think it goes beyond that. Misspellings are a code smell for me - if a developer can't be bothered to learn and properly apply the language that they've been speaking for 30 or 40 years, how much faith do I have in their ability to learn and properly apply a language that they've only been "speaking" for 5 or 10 years? So, if I may retort...

If you don't proofread your resume/e-mail, how much faith should I have that you proofread your code?

If you don't proofread your code, how confident do you expect me to be in the fact that you've debugged it?

If you can't be bothered to crack open a dictionary, chances are you won't bother cracking open Google when you encounter a problem. I imagine that you'll instead choose to boldly and blindly rush head-first go into the same tar pit that so many arrogant developers before you have.

I won't go so far as to say that you should go out and get an editor (but the man is on to something), but I will say that you're not showing a whole lot of regard for the person on the other end if you can't spell right. If the person on the other end is me then you're not instilling a whole lot of confidence in the quality and professionalism of your work either.

If the person on the other end of your typo'd code is you (and it probably will be) then why don't you love yourself enough? You need a hug.

If I wrote the typo or awkward grammar, Word was broken and my internet's tubes were completely full of kittens that day so you have to forgive me (and not point it out). After all, I'm just a developer. You must understand - we write in code, not English.

Rethinking FizzBuzz - Function Z

The notion that a program as simple as FizzBuzz was over the heads of a non-trivial number of developer candidates caused a stir for the sort that reads programmer blogs.
I was as astounded as everyone else was - here's a program that's a tiny step above HELLO WORLD in terms of its complexity and one can actually use it to weed people who call themselves developers (and have the experience on their resumes to back it up) out? Really? But at the same time, guy's got a point - why don't we have prospective developers prove that they can really write code?
In the mad dash to whip it out and measure their programming prowess, people missed out on pondering another fundamental need from candidates - reading code.
Nobody wants to cop to being a lowly maintenance programmer. The digs aren't hard to find - "cut and paste programmer", "they just cobbled the code together", "Java is the new COBOL", etc.
But when you get down to it, how much of your code is really "new"? Do you refactor relentlessly (or ever)? Have you ever found a bug in your own code and fixed it? Have requirements changed, leaving you to modify your classes to get things working as they should today?
Congratulations, you're a maintenance programmer. As a maintenance programmer, you had to do something that I imagine manages to elude even more so-called developers than writing FizzBuzz - reading (and more importantly, understanding) code.
My tweak on the FizzBuzz script is the following snippet. Along with it, I pose the (very hopefully hypothetical) question - "I found this function in the code base the other day and 'z' obviously isn't very meaningful. Could you walk me through how you'd go about figuring out what to rename it?"

public static void z(int[] x)
{
   for(int i = x.Length - 1; i > 0; i--)
   {
       for(int j = 0; j < i; j++)
       {
           if(x[j] > x[j + 1])
           {
               int t = x[j];
               x[j] = x[j + 1];
               x[j+ 1] = t;
           }
       }
   }
}

To get it out of the way, yes, it's a bubble sort written in a C-like language. At this point, let me just state for the record, I think you're all better than me.</Seinfeld>
So why is this so much better than having someone write FizzBuzz? Think about it - if they can't write FizzBuzz, they can't read it either. If they blow either question, interview over. If they get FizzBuzz right, where do you go from there? It's a binary question (only right or wrong) and those aren't useful for interviews where you're trying to get a feel for the person.
With Function Z, you're weeding out the FizzBuzz failures (and more of them), plus you're getting some lightweight insight into their thought processes, plus bonus insights once they've figured out that it's a sort function.
For example...

• Are they the prosaic type, questioning whether or not the language provided a native Sort() method on the integer array and why it wasn't used?
  
• Are they a Not Invented Here cowpoke, quick to point out that you should rewrite it as a quick sort and speed things up (I can see how this feels like a trick question for an interview, but I get nervous about people who make changes with that little context (on the other hand, encapsulation and wow I wouldn't even hire myself, would I?))?
• Are they the type that wants to leave everything better than they found it, cleaning up the variable names as they go along?
• Do they ask for the unit tests to accompany it?!?!??!?
  

I can see how either FizzBuzz or Function Z can spin into the ugly territory of "monstrous interview question I ask to make them feel like a dick", so I implore you to keep your hypothetical functions short and sweet.
So who else has some deceptively simple interview techniques?