I mentioned that I hadn’t been updating this blog, and that wasn’t just a matter of there being nothing to talk about.

Back in July I got laid off by DeviantArt. Since that was their second layoffs round of 2015, I think it’s fair to say that they’re having some problems.

This was non-ideal for me. In retrospect, I should probably have started looking around for a new job after the first layoffs round, but I’ll count that as a learning experience.

Fortunately, I then spent a month on downtime and relaxing, because I’d been terrible at taking vacation time at DeviantArt and they thus had to pay out a lot of vacation hours to lay me off.

Now I’m part of the Visual Editor team at the Wikimedia Foundation. I help people edit Wikipedia, essentially.

in Uncategorized | 135 Words | Comment


My employer has long used Skype as a team communication tool. This has some drawbacks, as I found myself complaining about way back in 2011, mostly that Skype is very much not optimized for big long-running rooms, particularly on mobile devices.

Given this, why have we stuck with it?

  • If we switch, everyone in the company needs to change their workflow to use some new tool, and most people don’t want to do this very much.
  • As such, we want to be really sure that whatever we switch to is sufficiently better than Skype that we won’t have to switch again anytime soon, because it’ll be an even harder sell to do so.
  • …but Skype really is fantastic at the “call a bunch of people” and chat, without having to care about network settings use-case. So we either need something else that’s fantastic at it, or something which’ll make it easy to keep using Skype to call a group of people you’re chatting with.
  • We have existing tools set up around Skype. We wrote a bot that announces stuff we care about in our chats, which we’re all very used to having around.

That last point gives us some incentive to make a switch now, as Skype decided to discontinue important parts of its API back in late 2013. This means that our existing integration is slowly falling apart, as the old version of Skype it has to work with becomes unable to interact with newer clients. It recently reached the point now where it cannot send messages in rooms created by newer clients, which makes it effectively useless for new projects.

So. We’re kind of looking at Slack, and part of working out if we like it is getting our bot in there, so we can see how it feels with our normal workflow. However, our bot is just a thin wrapper about Skype4Py, and porting it to use the Slack API would effectively mean rewriting it in full… which seems to be potentially wasted effort.

Enter the Hubot

Hubot is a chat bot framework, with adaptors for approximately everything. It’s fairly popular amongst the hip tech-company crowd, which our company is entirely too long to consider itself a part of.

So I decided to port our custom stuff to hubot scripts. This turned out to be pretty easy, so long as I kept the CoffeeScript reference open in a browser tab.

I’ve written:

  • A subscribe-to-deviantart-events script, which lets users/rooms sign up to be notified of the events our existing skype-bot was already announcing.
  • A Zendesk script, which can be set up as a “target” on Zendesk so we can feed tickets into the aforementioned notifier. As a bonus, I gave our helpdesk a new system they’d been requesting for ages, which announces if we’ve receieved more than X tickets over the last Y hours, as a warning that there might be a serious issue.
  • A Phabricator integration to expand references to Phabricator objects (tickets, code-reviews, commits, etc). This one I’ve actually stuck up on github for general use, since I think it has nothing DA-specific in it.

Slack seems nice, so hopefully we’ll settle on it. But if we don’t, at least I’ve invested my time in something transferable.

in Uncategorized | 541 Words | Comment

Hiring developers

It turns out to be quite difficult to hire good developers. I’m involved in the hiring process at deviantART, and it has opened my eyes to just how unqualified the majority of applicants to these jobs are.

To give an example of this, I estimate that we hire perhaps 0.2% of the people who apply for a job with us. I haven’t gone back and tallied this up, so all figures in this example are ballpark at best… but I’ve tried to err on the generous side.

First, we collect resumes. We advertise on all sorts of job sites, we post things to Hacker News, and generally we try to get the word out. Filtering the resumes eliminates about 95% of them, depending on where we’ve been advertising. This is simultaneously the step where unqualified applicants are most expected, and the step that’s most likely to be rejecting perfectly qualified people because of some random quirk of their resume.

Then we ask promising applicants to do a simple exercise. This one, in fact. It really is fairly simple… not FizzBuzz, but still trivial. This gets reviewed by the entire hiring team. Passing it is somewhat subjective; there’s a list of things we look for, along with an ineffable “code style” component. This weeds out about 90% of submissions.

Next comes a phone interview with those who passed the test. Again, with the entire hiring team on the line. Since you’ve made it this far we’re pretty positive about you, and strongly suspect that you can code competently, but we’ll still try to dig into your past experiences and quiz you on the reasons for things you did on our exercise. Ideally you’ll have left a small bug in the exercise that we can get you to debug while we’re on the call. It’s not uncommon for us to be underwhelmed here, and we tend to turn down maybe 60% of candidates on this step.

Finally comes a three month trial period. Which we take seriously. I’d worked places with a trial period before, but it was always just a matter of not showing up to work drunk and you’d make it. We evaluate performance, work style, and general team fit… and we seem to lose perhaps 20% of hires here.

Adding all that up, P(we hire you) would seem to be 0.0016. Or 0.16% if you prefer.

The step that seems the most telling is the exercise, because it goes out to people who are generally already making a living as a developer. And, like I said, it’s not difficult. So we get to see how many professional developers apparently can’t perform their job function. For that matter, a hefty chunk of the people who fail that step just plain didn’t complete the listed requirements.

Despite all that, feel free to apply! 😀

UPDATE 2011-10-01: Some people have mentioned that PHP is keeping them from applying. Can’t blame them there; it’s not cool and modern, and it has some ugly warts. But we’re an old website (11 years now), and back in the day it’s what was picked. Rewriting into something cool and modern is technically possible, but would also be a genuinely ridiculous amount of work.

UPDATE 2011-10-02: It was pointed out to me that I may not have conveyed my point correctly. I mean to say “hiring good people is hard”, not “we are too awesome for you”. The numbers are intended to indicate our low success rate more than our exclusivity.

Disadvantages to a Hollywood office

Yesterday when leaving work I stepped out the back door of our building and almost blundered through someone filming a scene for something.

The back doors of our building had been made over into a hospital entrance, and someone who was the very embodiment of The Wise Old Bum was dispensing advice to people in scrubs, while some sort of faux-homeless band played on the bridge crossing the alley to the parking garage.