Archive for June, 2010

Introducing Programmer Puzzlers

Thursday, June 17th, 2010

Just a quick note to let you know about the launch of Programmer Puzzlers, a new site with logic, coding and math puzzles designed for programmers.  Stretch your mind, have fun, challenge your friends or gear up for an interview.

The first puzzle, Burning Ropes, is already up, but a new puzzle is published every week.  So if you’re interested in solving puzzles, be sure to subscribe to Programmer Puzzlers via RSS or email.

You can also submit your own puzzler here.

256X Better than a Resume

Thursday, June 10th, 2010

Why do resumes suck for hiring programmers?

  • They emphasize short, buzzword-filled entries that work well for people full of business-speak (and the other kind of BS).  Is that really the kind of person you want floating to the top of your candidate pool?
  • Hiring managers reject candidates based on resumes, when a resume has absolutely no ability to demonstrate technical skill.
  • It rewards those who are willing to lie, without very little recourse for verification.  This is not something I think about very often as I don’t lie on mine, and when I read resumes, I assume they are not lying either.  However, occasionally I’ll hear a story about someone who did verify and found a blatant lie, and it reminds me that this probably happens more often than I’d like to think.

In a recent Inc magazine article, Jason Fried of 37Signals claims that you should “never read another resume”.  He doesn’t, but then again, his company is in a unique position of having a flood of great candidates after investing a great deal of time building their image.

It should be fairly easy to recognize technical skill, right? Thousands of currently-employed crappy programmers and millions of horrendous LOC are a testament that it doesn’t work that way.

What are alternatives to resumes that would factor in technical skill?

Open Source Contributions

This is the option used by 37Signals, and I have an entire article devoted to why open source is not a good way to evaluate potential programmers.  In short, there are plenty of great developers who don’t spend time on open source, as well as plenty of crappy ones who do.  This complete lack of relevance to technical skill makes it a useless and even harmful barrier to entry.

Certifications

This one is an oldie, but like Monthy Python, it’s not dead yet.  Certifications are granted by some body that claims to have authority, but they actually make money by people taking the tests, so it’s in their best interest to allow a reasonable percentage to pass.  By taking money from test-takers, they have ruined their objectiveness.  Plus, they rate developers in a pass/fail system: you are either a certified developer or not.  This is not a reasonable way to judge developers since their skills range quite widely.  And as soon as you’ve seen a couple of crappy developers who are “certified” their credibility is destroyed also.

Stack Overflow

The Joel on Software/Coding Horror camp described the problem perfectly, but the solution fell short.  Since your Stack Overflow score is based on your activity on their Q&A site, it promotes people who spend a lot of time on their site, instead of the best programmers.  That model certainly serves Stack Overflow well, by providing an incentive to spend time on the site, but doesn’t work so well for busy programmers or the companies that want to hire them.

Coding Tests

This one is really the best option for employers because it is the most accurate, but it’s also extremely time consuming for both parties.  Even if you require a coding test before you’ll interview someone it’s still very time consuming to check all of the submissions.  And many companies don’t want to require this: it turns off a lot of good programmers from bothering to apply (why should I spend an hour of my time just for the chance to speak with you?)

So what’s left … Code Anthem!  Coming soon to a browser near you.  Sign up for the beta now.

How much does it cost to hire a good programmer?

Tuesday, June 8th, 2010

Let’s say your a hiring manager and you need to hire a software developer for your team.

Well, most people start with a job posting:

  • Dice: $459
  • Monster: $395
  • Career Builder: $419
  • Joel on Software: $350
  • Signal vs Noise: $400

You may also want to browse existing resumes:

  • Dice: $895
  • Career Builder: $600 for 2 weeks
  • Stack Overflow: approx $500 per week

And if you’re having trouble you may need to use a recruiter:

  • At about 20% of your new hire’s annual salary, that’s $10,000 – $20,000 per hire

So now you have a giant pile of resumes, time to spend hours and days and weeks on:

  • Reading and sorting through resumes
  • Following up with candidates
  • Doing phone screens
  • Administering coding and technical tests
  • Doing technical interviews
  • Doing behavioral interviews
  • Doing management interviews
  • Considering a hiring manager’s salary, that is some serious $$$

If you don’t find anyone, you have to start over.

  • Losing money in opportunity cost as we wait weeks and months just to find the right person

If you do find someone, you may want to test the waters:

  • Hire them to do a project for you on the side: $5-15K
  • Hire them on contract for 3 or 6 months: $20K-40K

So, how much money does it cost to hire a good programmer?  A lot!

That doesn’t even take into account what happens when you get it wrong and hire a bad programmer.  You waste all that time on training them on your system and incorporating them into your company.  To top it off, crappy programmers actually mess up your system worse than when they started.

Imagine this.

5 programmers who can really write code at the level required.  You can test them all you want, but it’s not necessary, they’re already qualified and capable through and through.  They are all looking for jobs and geographically located near you (assuming you care).

You meet with them to determine mutual culture fit and pick the one that gels with your team.

How much would that be worth?

(Put your answer in the comments)

A Sip of the Agile KoolAid for Programmers

Monday, June 7th, 2010

There is a lot of mystique associated with being  “agile”.  Even for developers who are usually so tech-savvy, they talk about agile in odd terms – like my grandma might ask what the web is used for.

Like:

“I guess I’m a little a bit agile, but I really like to use use cases – does agile have use cases?”

Or,

“I woudn’t want to do scheduled releases like agile because I don’t want to send the customer half-finished features.”

They really just have no idea what agile is…

I get it.  I hate buzzwords and bandwagons, too.

The difference is that I’ve been on multiple agile teams that were so incredibly successful that I am sold.

  • I never have to feel that sinking feeling in the pit of my stomach just because my customer found a bug.
  • I don’t have to fight with my customer over whether something is a bug or a feature request.
  • No more working crazy overtime at releases.
  • No more holding your breath at the big, scheduled demos that it will actually work.

So what is this magic? In the effort to spread a little knowledge and good cheer, this post is just a small tasty sip of the agile KoolAid:

  1. Agile is a set of ideas, not a religion
  2. Agile is based on a set of ideas called the Agile Manifesto. For example, value “individuals and interactions over processes and code”. I have no idea why so many agile proponents try to indoctrinate everyone into their little cult, but that is the opposite of what agile is about.

    Agile doesn’t say you can’t use any process, agile doesn’t say you can’t use any up-front design, agile doesn’t say you can’t use your previous use cases!

    You don’t have to worry if agile is going to destroy some precious aspect of what you do, because by definition if it’s working well for you and the project then it’s agile.

  3. Agile doesn’t increase project risk, it reduces it
  4. Agile recognizes that feature creep and unexpected bugs are going to happen. Traditional project planning basically crosses your fingers and hopes it won’t happen, or punts it to some later date (I’ll deal with feature creep when it happens, We’ll handle all bug fixes at the end).

    Instead, agile puts the reins in the hands of the customer/client/PM/whatever. By allowing them to reorder the backlog however and how often they choose, we ensure that the programmers are always working on the most important thing at any given time.

    If you run out of time in an agile project, by definition you have already completed the most important things. If you run out of time on a “traditional” project, you most likely have something completely unusable, like a database and middle layer but no UI.

Listen, agile doesn’t make crappy programmers write good code and it doesn’t turn useless products into good ones.  All it does is allow programmers and PMs work together on the same side the table and focus on the things that matter, like getting to done.