Now, are you scared enough? Don't be, the problem there is with the hiring process.

Yes, there are lots of people who show up for programming positions and can't program. That's not unusual!

It's related to something I read by Joel Spolsky (amazingly, Jeff Atwood's partner in stackoverflow.com).

Suppose you are a company that tries to hire in the top 1% of programmers, and have an open position.

You get 100 applicants. Of those, 99 can't program. 1 can. You hire him.

Then the company next door needs to do the same thing. They may get 100 applicant. 99 can't program ... and probably 80 of them are the same the previous company rejected before!

So no, hiring the best 1 out of 100 is not a way to get a programmer in the top 1% at all, that's just statistics intuition getting the worse of you.

You don't want to hire in the top 1% of applicants, you want to hire in the top 1% of programmers. Different universes.

These two things are the two sides of the same coin. 99% of applicants are useless, that's why they are applicants, because they can't get a job and they can't get a job because they are useless as programmers.

So, judging programmers by the standard of the applicants you get is like judging quality of a restaurant by licking its dumpster.

But now, having taken care of this, how do you find a programmer that can actually program?

Easy! Find one that has programs he can show you!

I would never hire a programmer that can't show me code. There must be something wrong with him, because programmers write programs.

That's just what we do. If we didn't what kind of programmers would we be?

Let's see some obvious objections to my argument:

1. He wrote code for his previous employer and can't show it.

   So, he did. What else has he written? Some open source code? Maybe snippets in a blog? Answers in stackoverflow?

   Nothing? He has written nothing he was not paid to write? He is not who I want. He only programs for money, he lacks passion for programming, he doesn't enjoy it. He is probably not very good at it.

2. He is just finishing college, he has not written much code yet!

   Why? What stopped him? He has been learning to program for years, what has he done with the knowledge he has been receiving? Saving it for his 25th brthday party? He has not practiced his craft? Not the programmer I need.

But having him show you code is not enough, of course. It also has to be good code, if you are serious about hiring excellent programmers.

So here's some bonus criteria:

1. Check the languages he uses. If he codes COBOL for pleasure, he may or may not be what you want.
2. Open source == bonus points: it means he is not ashamed of his code, plus it makes his credentials trivial to verify.
3. If he leads a project with multiple contributors and does a good job he is half way to becoming a programmer/manager, so huge bonus points.
4. Projects with long commit histories show responsability and a level head.
5. Development mailing lists let you gauge his personality. Is he abrasive? Is he thin-skinned? Is he annoying?

Then there's the obvious stuff, references from previous employers, interviews, exercises, an such. But those are the least important filters, the most important thing is that he must be able to code. And showing you his code is the way to do it.

For those of you who don’t know, PiCloud is a cloud computing platform for Python that aims to simplify the task of running code in “the cloud.”

cw

And the other based on the Dharma logo, with a marshmallow peep as the Swan:

Yesterday MacHeist started offering pre public beta access to Tweetie 2 for Mac.   That caught my eye because Syrinx, my primary Twitter client has been a little slow at keeping up with Twitter features.   I didn’t really want to get the MacHeist bundle (don’t want to hassle with packages that I don’t want) just to get the private beta, but I mentioned on Twitter that I was thinking about it.   Several folks suggested that I try Echofon.   I gave it a whirl, found some things that I like and other that I didn’t.   I started keeping notes about Syrinx vs Echofon, and now it’s turned into a blog post.

My usage style / requirements

I follow a bunch of people, including many people who live in Europe who tweet while I am asleep.   I need a client that can remember unread tweets from overnight.    I’ve found very few clients that are able to do this.     My reading style tends to be bursty as well, so I want the client to do a good job of keeping track of what I’ve read and what I have not.    These two requirements are what has kept me on Syrinx – it can hold days worth of tweets without a problem.   Syrinx’s bookmark also gives me definite way of marking what has been read and what has not, and puts control of that mark directly in my hands.

The other major requirement is that I spend some time (probably too much) on airplanes, without net access.   I want a client (mostly on my iPhone) that can go back in fill in the gaps left by being in the air.   Tweetie 2 for the iPhone can do this, but the experience of switch back and forth between reading the stream on desktop Syrinx and iPhone Tweetie 2 is annoying.

A minor requirement is to be able to monitor a number of Twitter searches at once – that means opening a window for each search, something that Syrinx also does.

Now, let’s have a look at how Syrinx and Echofon stack up for me.

Syrinx

The obvious things that I like about Syrinx are that it can hold as many tweets as I want, as well as the bookmark.    I’ve also grown accustomed to the way that it displays time in absolute format, something which Tweetie 2 / iPhone also does.   One other nicety in Syrinx is that it can display real names in addition to Twitter handles, because sometimes handles and people are hard to match up.   When you have tons of tweets lying around in the? client, sometimes you want to go back to one, and Syrinx obliges with the ability to search all the tweets that it currently has in memory.

So what are the problems with Syrinx? It’s been occasionally unstable, but not in a show stopping fashion. It doesn’t have good support for lists, but I still haven’t made much use of lists. Syrinx does great on opening windows for searches, but it doesn’t remember what searches you have open, so you have to keep track of that yourself. Probably the biggest drawback of Syrinx is that its development is going slowly because its author has a day job.

Echofon

When I compare Echofon and Syrinx, I realize that a lot of the things that I prefer in Echofon are niceties. I like that it can open browser links in the background. I like the way that the drawer is used for dealing with Twitter users and profiles and for displaying conversations.   I just wish it could display more than one conversation at once – but that’s hard in the drawer model. The ability to colorize tweets matching keywords makes it easier to pick out tweets on high priority topics.    As a photographer, I appreciate the ability to display pictures without going all the way to the browser.    I do wish there was a way to get some kind of preview of those pictures right in the tweet stream.   Echofon does this clever thing where it combines “rapid-fire” tweets from the same person.   This seems to work really well, and the visual cue is definitely helpful.  

Looking at the tweet authoring side,  I love the “retweet with comment” option.   One reason that I stopped commenting on retweets was that it was annoying to do it.  No more.   Echofon can tab complete Twitter id’s when @replying or direct messaging.    I still wish for a direct message “rolodex” – there are some people who have hard to remember Twitter id’s.   bit.ly is my preferred URL shortener because of the analytics, but you have to be logged in to bit.ly in order for that to work well.   Fortunately Echofon is able to log into bit.ly accounts so that your analytics work.

In theory, I like the idea of an Echofon ecosystem that syncs the desktop and mobile clients.   I haven’t tried this yet because I have iPhone Twitter client fatigue, and because as much as I like Echofon, there are some issues that make it hard for me to switch over.

The first of these issues is that Echofon won’t hold all of the tweets that happen overnight.  It looks like Echofon will hold about 5 hours of tweets before it starts to drop them on the floor.  There go some of those European tweets.

The next big issue is that marking read/unread doesn’t work for me.  If I am scrolling up through my home tweets and I hit the top, everything gets marked read.   It’s easy to do that by accident.   Switching to the @, DM, or search tabs also marks my home tweets as all read, and that doesn’t work for me at all.

Compared to those two issues, everything else is just nits, but here goes, just to be complete.   Echofon doesn’t display absolute time or real names.    Also, Echofon doesn’t let you search your home tweets.

Wild and crazy wishes

Certain URL shortening services (su.pr and ow.ly come to mind) wrap the page in a header bar, which is annoying.  I’d love if my client would route through those services so that the URL that I got in the browser was the actual content.

Sometimes there are links that are retweeted a bunch.   I would love it if a client could compress all those retweets into a single entry which showed how many / which people I follow retweeted a link, along with an indication of whether or not I had already “read” an earlier retweeter (which would mean I had already read the link).

I guess I’ll have to do another version of this post when Tweetie 2 for Mac finally ships.   Or maybe it’s still early enough for some of these ideas to make the cut.

As of last week, I am now an employee of Mozilla! Thanks to everyone who helped me out during my job search.

I’ll be working both with the Mozilla Web Development (webdev) team, and Mozilla Labs.

The first thing I’ll be working on is deployment. In part because I’ve been thinking about deployment lately, in part because streamlining deployment is just generally enabling of other work (and a personal itch to be scratched), and because I think there is the possibility to fit this work into Mozilla’s general mission, specifically Empowering people to do new and unanticipated things on the web. I think the way I’m approaching deployment has real potential to combine the discipline and benefits of good development practices with an accessible process that is more democratic and less professionalized. This is some of what PHP has provided over the years (and I think it’s been a genuinely positive influence on the web as a result); I’d like to see the same kind of easy entry using other platforms. I’m hoping Silver Lining will fit both Mozilla’s application deployment needs, as well as serving a general purpose.

Once I finish deployment and can move on (oh fuck what am I getting myself into) I’ll also be working with the web development group who has adopted Python for many of their new projects (e.g., Zamboni, a rewrite of the addons.mozilla.org site), and with Mozilla Labs on Weave or some of their other projects.

In addition my own Python open source work is in line with Mozilla’s mission and I will be able to continue spending time on those projects, as well as entirely new projects.

I’m pretty excited about this — it feels like there’s a really good match with Mozilla and what I’m good at, and what I care about, and how I care about it.

Thanks again to everyone who attended! Please give me feedback on joind.in.