Programmers vs. Developers

I work for a marketing firm out of Utah County, here in the lovely Beehive State. Recently, upper management came to us and said, “We want to expand your team so that we can take on more projects. We need to hire three new programmers; here are a stack of resumes.” It took all of about four minutes to look through the stack, pick out which candidates I thought we should interview (all of them, actually, for reasons that I’ll explain in a sec), and realize that while we could probably give management what they asked for (three new programmers) pretty easily, it was going to be a little more difficult to hire what they meant to ask for: three new developers.

I elucidated the difference between the two one day in the same place that I come up with all my great ideas: in the bathroom, natch. I’m going to tell you, and then I’m going to explain it. Ready? Here goes:

> Programmers are people who write code to solve problems. Developers are people who solve problems, then write code to implement their solutions.

That’s it. Whoa, man, right? Let me explain. Let’s say that you are building a calendar solution for internal use, where users can have multiple calendars, and multiple users can share the same calendar (and you can assume that if your answer is “just use Google Calendars,” I will stomp on your toes and call you not-very-nice names). Not every user should be able to view every calendar, and some users shouldn’t be able to edit all the calendars that they can view (it just won’t do at all to have the janitor rescheduling the boss’s 2:30 tea-time without telling anyone).

If you ask a programmer to explain how they would implement such a system, they might tell you about the session-based authentication they will use to capture the user’s credentials, and how a user will be able to POST a form to create a new event on the calendar. Maybe they explain that they will use AJAX so that the user doesn’t even have to reload the page, reducing bandwidth usage on the server. They might get so far as to tell you that they will store a list of authorized user ids per calendar in a MySQL database.

Contrast that with a developer’s answer. Depending on which approach he decides is best, he might talk about grouping users by role or permission level, so that the right people have access all the time (so that your manager can tell who on his team has time to handle a bugfix that just came down the line, for example, or so the receptionist can add an event to your calendar letting you know that an important client is coming in for a presentation on Thursday). Then he might talk about using an access-control system to provide finer-grained permissions on a per-calendar, per-user basis. If he wants to keep going (not that he needs to; he just addressed your entire initial problem space), he might talk about recurring events, and allowing other users to RSVP to public events, or events to which they’ve been invited.

(I said “he” in that paragraph up there, but I’ve known many “she” who could code circles around me in their sleep. If you’re offended anyway, deal with it on your own time.)

Did you see the difference? The programmer talked about the code he would write. Even if he wasn’t intentionally loading his sentences with buzzwords to try and wow you into thinking he knows what he’s talking about, he was probably using enough technical language to put you to sleep if you’re not from a coding background. If you’re a pointy-head conducting an interview (because the actual development team is “too busy to be able to take time away from their projects”), you might hire him just to get him to shut up.

The developer, on the other hand, talked about the problems he would solve. Unless specifically asked, he wouldn’t even need to talk about a single line of code that would go into the project. It’s a principle in which I’ve become a firm believer: once you’ve found the right solution, implementing it becomes trivial. The code practically writes itself around the problems that you’ve already solved.

So how do you tell the difference? Talk to them. Have the people in the trenches do a technical interview. You can’t assume that just because the resume on your desk says that this guy knows a couple different languages and has a degree in a technology field that he’s going to be able to provide elegant and timely solutions to your problems. You have to sit down face-to-face with them and make them prove that they know their stuff.

That’s why I say that everyone deserves at least one interview. 85, 90 percent of the people, you’re going to know right away that it’s a waste of time. But every once in a while, you’ll find the one that makes it worth it. Because here’s the real kicker: not everyone that makes a great developer, makes a great programmer. At least not at first. Maybe they’re not familiar with the language your team writes in, or maybe they haven’t used this particular set of technologies before. That’s cool. Language syntax can be learned, technology stacks can be taught. You’re looking for a person who possesses two primary qualities:

  1. They’re smart
  2. They get stuff done

That’s it. It’s that simple. Everything else will come with time, but if they’re smart and get stuff done, they’ll be able to solve problems (the hard part) and figure out the code (the easy part) later. And then you’ll be able to pat yourself on the back and say, “Man, I’m really smart for hiring that guy!”

Or girl. Whatever.

Leave a Reply