Schwern

My blog has moved to blog.schwern.net.

Here's the short version: gender anonymity is protection, and in a male-dominated community many women prioritize safety. A machine parsible list of female CPAN authors threatens their anonymity even if they're not on it.

Here's the even shorter version: highlighting gender is advanced and should not be done lightly.

A module was recently uploaded to CPAN whose aim was to provide a big list of female CPAN authors. I believe the author had good intentions, or at least nothing more than "I was curious", and has been quite puzzled at the reaction that it's creepy and the requests for it to be deleted. Fortunately, he voluntarily removed the module when asked. Unfortunately, because the community is not well versed in gender politics, this sort of thing is likely to happen again. Here's an opportunity to talk about it so it doesn't.

This is a placeholder post to house links to further reading from my YAPC::NA 2012 keynote.

Test::Builder2 is now down to two issues.

1. The problem of using Mouse
2. The problem of backwards compatibility

The former is complicated, but suffice it to say TB2 cannot rely on Mouse or Moose or Moo. It's being solved by writing an OO compiler, something which will generate accessor methods and roles at build time rather than relying on a runtime compiler. This should also solve TB2's less than ideal startup time. It might be Mite or it might be Moo, but the problem is being taken care of.

The second is harder and is what I call "Test::Builder2 vs CPAN". Because Test::Builder has been around or so long, and so much depends on it indirectly, there's a lot of not entirely documented behavior being relied on. We've been using CPAN modules as a broad test suite right along for this reason. TB2 has the potential to seriously break a lot of module's test suites, so it's best to get it as right as possible before stable release.

Spotify is having a coding challenge to find "top-notch talent to join our NYC team". The challenge is to solve the most algorithmic puzzles in four hours... alone. "You may not cooperate with anyone, and you may not publish any discussion of solutions." What sort of developer will win this competition? Someone who is quick, dirty, has a mathematical mindset and lucky enough to write something that happens to work for the test data set. The "rockstar". Is this somebody you want on your team? Would you want to maintain their code?

Last year while on contract, the company in question was passing around their coding problem they used to test new hires. It was pretty typical stuff: give the data going in, the data they want out, and write a little program to do the transform. They even supplied most of the program, including a test; the prospective hire just needed to write one sort subroutine which could deal with "Low", "Medium" and "High" as well as numbers.

Predictably, this halted all coding in the office for a solid half day while everyone figured out the most clever way to sort the data. My opus was to observe that the input data was already sorted, so I redefined the shuffle() routine. The best one was from a co-worker who observed that "Low", "Medium" and "High" sort correctly by their last letter in reverse order. It was fun for us, but it wasn't very useful.

This is a pretty typical coding problem used to judge potential hires, and it sucks. All it tells you is the candidate is not completely incompetent. Why do we keep using them? They're easy. They're easy to think up, easy to judge and easy to administer. They're also the sort of clean, algorithmic problems a stereotypical programmer loves to solve. Do they have anything to do with detecting a good developer? No. Can we fix it? Yes!