Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Adrian (66)


The hats I wear at work include: accessibility consultant; information architect; software developer (of the agile/XP/TDD breed - mostly in Perl); usability consultant; web site designer. I'm very dull:-) . []

Journal of Adrian (66)

Monday March 03, 2008
09:29 AM

Thank you Linpro

Thanks to Linpro for sponsoring my attendance of the Oslo QA Hackathon 2008.
Thursday May 17, 2007
02:03 AM

How not to write a job advert.

Aristotle recently suggested that an old perlmonks rant on how not to write a job advert deserved a wider audience.... so here it is.

My usual rant on recruitment goes something like this.

You're dealing with four groups of people:

  1. Qualified: the people who have the skills you need and would want to work for you
  2. Unqualified: honest folk who either don't have the skills or don't want to work for you
  3. Deluded: people who think they can do the job despite the fact their computing experience consists of knowing somebody whose cousin owns a Playstation
  4. Liars: people who know they can't do the job and will lie to get it anyway

So you want to:

  1. convince that first group that you have a wonderful job working for a competent company that's just right for them
  2. convince the others that they shouldn't waste everybody's time

Two big problems:

  1. Almost by definition the Qualified are in work. Why wouldn't they be? So you need to make sure that you're going to make something attractive enough for people to consider jumping ship for.
  2. It's a complete bugger to get rid of the Liars and the Deluded because... well... they're liars and deluded :-)

The good news is that the Unqualified are happy to exclude themselves if they're given enough info. They don't want to waste their own time applying to stuff they they know they're not going to get.

So - how do you find somebody decent?

Best way is personal recommendation. Network away and see if anybody you know and trust knows somebody who would be interested. Assuming you have vaguely sane friends this is almost guaranteed to exclude the Deluded and the Liars. Huzzah.

Second best way is to use a good recruiter. Unfortunately, in my experience anyway, good agents are rarer than gold dust in the IT industry. Unless you have a personal recommendation from somebody I'd steer clear.

The absolutely worst way to find somebody is a job advert - but sometimes we have no choice ;-)

So - how do you know if you have a decent job advert?

You know the sort of person you're looking for. Pretend you're that person sitting in a fairly comfortable job, with a reasonable salary, but feeling slightly bored with your current work. Remember you know nothing at all about your company and the work you do. Read your job advert. Do you want to apply?

If not you may want to consider my Patent Pending list of how not to write a job advert :-)

  1. Lie. Nothing attracts that ideal recruit more than showing up at the job interview to discover that the salary is ten grand less than was advertised and that they can't telecommute like the agent told them.
  2. Bad spelling and grammar. Would you trust a company that cannot even check the spelling on their job adverts?
  3. Bad technical terms. The Qualified are not going to apply for a position as a "PERL programmer with Central Gate Interface experience" :-)
  4. No company info. Put your company name and URL on the advert. Good candidates will want to google you and find out whether they want to work for you. Let them. That way you'll let the Unqualified filter themselves out. Does googling your company results in stuff that would make the brave run away screaming? If so fix that first :-)
  5. Bad job title. Treat the job title like the subject line of an e-mail. It should be informative. It should be an abstract of the job. It should not be "Programmer" or, even worse, "GREAT POSITION IN TOP COMPANY!!!". Something like "Perl/mod_perl e-commerce developer". The Qualified are only skimming the job ads to keep a weather eye on what's happening. Don't give them an excuse to skip over the ad. Being specific also makes it harder for the deluded to remain so.
  6. No salary. At the very least quote a range. The Qualified are probably working and need to know whether it's worth their while to jump ship. It's also a good indicator of what kind of role it is. This will let the Unqualified filter themselves out and reduce your pile of useless CVs.
  7. Over general terms. Don't say "Perl programmer" say "Perl programmer. Must have experience writing OO modules and unit/acceptance testing of web based applications". Make it easy for the Unqualified to filter themselves out. Make it harder for the Deluded to delude themselves.
  8. Not knowing the difference between a job requirement and "it would be nice if...". Make the difference obvious in your advert. Far too many ads are a shopping list of every possible thing that might be vaguely useful. Are you really going to reject the perfect candidate because they only have four rather than five years experience? Are the Qualified going to spend the time figuring out what the job actually involves? Nope - they have lives.
  9. Hiding the job requirements. By the time they've got to the third paragraph of market speak about how wonderful the company is the Qualified's eyes are glazing over. Job requirements should be front and centre.
  10. Not saying what the job is. For god's sake mention what they'll be developing. It's one of the things that attract the Qualified. At the very least mention the domain.
  11. Not mentioning the work environment. If you have a small agile development team using TDD then you don't want somebody who uses RUP in a group of forty, or somebody who will only telecommute. So let them filter themselves out by saying so.
  12. No location. People want to know where they'll be working.

Remember - you want the best person for the job, not the most desperate. The best people are going to be comfortable and happy to skip things. The desperate are going to read everything.

So, get the attractive stuff that will capture the best up front where they'll read it.

Thursday March 29, 2007
05:44 AM

Inconsistant metadata: Yet Another Reason to Hate MySQL

Compare and contrast:

-- schema A
CREATE TABLE products (
    vendor_id   INT UNSIGNED REFERENCES vendors (id),
    name        VARCHAR(255),
    UNIQUE      ( name ),
    INDEX       ( vendor_id )
) TYPE = InnoDB;

-- schema B
CREATE TABLE products (
    vendor_id   INT UNSIGNED,
    name        VARCHAR(255),
    UNIQUE      ( name ),
    INDEX       ( vendor_id ),
    FOREIGN KEY ( vendor_id ) REFERENCES vendors ( id )
) TYPE = InnoDB;

Schema B sets up the meta-data that Rose::DB::Object::Loader uses to figure out the relationships between tables automatically. Schema A does not.

Six.... fardling... hours.... wasted.

Many thanks to John Siracusa for pointing me to the solution.

You can almost see the bit of code that needs to be refactored.

Monday March 26, 2007
10:32 PM

Death threats...

I know I should no longer be surprised at the number of asshats in the world, but the abuse that Kathy Sierra has been recieving... yuk...
Friday March 09, 2007
07:17 AM

0000-00-00 vs NULL: Yet Another Reason to Hate MySQL

Just to join Ovid in his recent rants...

My co-worker and I have just spent the last forty five minutes with a bug that boils down to this "interesting" behaviour...

create temporary table the_dates (d date not null default '0000-00-00');
insert into the_dates values ('0000-00-00');

So far so normal.... but:

mysql> select count(*) from the_dates where d is null;
| count(*) |
|        1 |
1 row in set (0.00 sec)

mysql> select count(*) from the_dates where d is not null;
| count(*) |
|        1 |
1 row in set (0.00 sec)

.... sigh....

Wednesday March 07, 2007
08:20 AM

Resume tips #1

Do not misspell "design" three times in a row and then tell me you have attention to detail.
Friday February 23, 2007
08:10 AM

Somebody is actually using Test::Block!

I've just noticed on CPANTS that somebody (NKH) is actually using Test::Block in real code.

Good lord. Never expected that!

Tuesday February 20, 2007
04:41 AM

Playing with LinkedIn

If you vaguely know and are on LinkedIn I'm at

(Note: I keep contacts to people I vaguely know / exchange e-mails with. So please don't bother if I've never heard of you :-)

Monday February 19, 2007
07:47 AM

Alien conspiracy!

Am I the only one who read this headline and was immediately in X-Files territory?
Wednesday February 07, 2007
04:57 PM

Making agile development and design work

(a comment on whose overactive spam protection won't let me post :-)

There seems to be some confusion agile methods are purely a developmental process. That really doesn't gel with my experiences. For example I've found the Planning Game in XP is a very rich environment for doing exploratory design work.

For me agile is just as much about design as it is about implementation. Go read the agile manifesto again . Replace "software" by "product" and see how it reads.

It's true that if you don't have people with design skills involved in the team then you're less likely to get a decent product out the other end - but this is true of any process.

Agile development doesn't devastate design any more than any other process. In fact, I'd say that you're slightly more likely to get things right even without input from Design (in the UX/IxD sense) folk, because you're getting feedback far more frequently and can spot problem areas.

When the developers aren't separated from the stakeholders and users by N layers of management Chinese whispers it becomes a lot easier for them to do a good job.

As for agile only working 2-4 people - there are a /whole/ bunch of people who seem to be doing pretty darn well with considerably more than that :-) It's certainly easier to get a small team up and running in an agile manner. That doesn't mean that you can't get larger projects working that way.