May 2006 Archives

File a bug report

| 2 Comments

Vani and I both started using Life Balance for our todo lists in the last week or two. It's great so far.

One of the items I added was a occasionally recurring "File a bug report" task.

Writing a good bug report is a relatively quick and easy way to help the authors and maintainers of the software you use make it better.

I was working a bit with Xen on Fedora Core 5 some days ago and found out that the default scripts don't deal nicely with anything but the most basic net configuration. Hello bugzilla.

MySQL is one of the nicest projects to file bug reports for, because they are very nice about following up and actually fixing things (even if sometimes the fix is just to change the documentation to say that doesn't work ;-) )

Ovid wrote a short article giving a glimpse of Perl 6

If that was too dry and technical for you, then instead go read about how he he caught two idiots using his credit card last year.

A couple of weeks ago I posted to jobs.perl.org again. A few things I quickly remembered.

My posting says "PDF or Text formats only!", but yet I get Word documents. I know it's been getting easier and easier again to find interesting work over the last year or two, but come on. If you don't care to read what I wrote, I am not going to care what you wrote either.

I ask for code samples and anyone reasonably interested sends them. But it's incredibly hard to get something useful out of. I am not really sure what to do about it, because it's by far the best way to evaluate someone without an actual interview. For relatively short-term telecommuting it's often the only practical way.

The code samples are rarely interesting. Either they are too brain-dead simple or they are too complex to scan in a couple of minutes. Either way, it takes a relatively large amount of effort to review.

I have a hard time discarding the candidates who sent bad code. "But their resume looked interesting".

And I keep thinking what would I send if I had to send a code sample? It's hard1.

So again and again I find myself looking for tests included in the code sample. I start looking because it'd be a sign of good coding practices, but what it really gives me is a much faster way to evaluate the code.

I love tests in the code samples. They give all sorts of benefits to the resume/candidate reviewer. For instance

  1. Tests lets me figure out quickly what the rest of the code is supposed to do.
  2. Tests demonstrate the APIs. perltidy can fix your messy indentation, but you have to know what you are doing to make the interfaces to your code decent.
  3. Tests are short and to the point. Even in Perl code there's always a fair amount of setup and teardown noise. In tests all that is pared down to the essentials.
  4. Code = Not particularly useful. Code + Tests = Useful.

How do you like to get code samples? How do you evaluate them?

1 The 20 line Geo::Coder::Yahoo? An early version of qpsmtpd? (The versions from the last few years wouldn't really work as a code sample unless you wanted to hire a particular dozen of people to write a mail server in Perl :-) ) Maybe I'd send the code for some of the perl.org things I've made, but would I want to be judged on that? Those things are surely not my finest work. The more interesting work is often encumbered by being owned by $client or $employer and by having lots of "yes, they really wanted it do that" things.

About this Archive

This page is an archive of entries from May 2006 listed from newest to oldest.

April 2006 is the previous archive.

June 2006 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 4.3-en