Here’s an interesting quote from Kent Beck. He says:

The product of software development is two-fold:

• The behavior of the system
• The options for extending and modifying that behavior in the future.

That second point summarizes what good software design is about. Each feature we build in our code gets us closer to release. But the way we build each feature can set us on different paths. If we don’t care how it works, as long as it works, then our launch may come and go without a problem. But when it’s time to return to that feature and make a change or an improvement, we’ll likely find ourselves wading through a tangle of spaghetti.

We want to take the other path, where each coding decision carries a question with it: What will I think of this code when I need to change it in six months? Will I understand it? Will changing this break other things, or will the change be isolated? This habit, to the extent that we can keep it up, allows us to keep improving our apps instead of getting stuck in spaghetti.

How do you hire a programmer if you’re not one yourself? Some things to look for…

1. How opinionated are they?

Ask them about a juicy programming topic (e.g. Ruby or Python?). The tone and reasoning of the answer will reveal a lot. In our recent podcast on programming, Jeff said, “When people have strong opinions about things — when they can talk at length about something — it’s a good indication that they’re passionate about it.”

2. How much do they contribute to open source projects?

Look at their contributions. Though you may not be a coder, you’ll be able to tell if there’s some code there. And the fact that somebody is contributing something is a good start. “The fact that somebody is contributing at all means they’re using the tool,” said Jamis. “It means they’re scratching an itch, like they ran into something that they thought should be improved, or ran into a bug and they fixed it themselves. That level of participation is a good discriminator.”

3. How much do they enjoy programming?

They don’t have to spend every second of their free time hacking, but you do want to see some level of passion. Jamis said, “It’s not so much that coding in your free time is the important thing so much as it is that you’re showing you’re passionate about it and that you have opinions.”

4. Do they actually ship?

Find out how they manage their work. Software often slips — find out how they avoid this. Find out when they shipped something on time and ask why that project was successful. Or find out lessons learned from a delayed project. “The ability to ship software is critical,” according to Jeremy. “How they manage the very task oriented part of actually needing to get something done and finished by a certain time.”

5. What have they mastered?

Randy Nelson of Pixar argues that mastery in anything is a really good predictor of mastering something else. So look for someone who’s mastered something. Is the candidate a great chef? Or mountain biker? Or something else? That’s a sign they can be a master on your project too. “That sense of I’m going to get to the top of that mountain separates them from all of the other candidates almost instantly,” says Nelson. “There’s very little chance that someone’s going to achieve mastery on the job if they didn’t get there before coming to your workplace.”

6. How well do they communicate?

The less you understand about programming, the more you’re going to rely on this person to translate what’s going on to you. That’s why hiring great writers, regardless of the position, is a good idea. For example, here’s Jeff explaining a Basecamp API update to the rest of the team inside the project site:

I just pushed an update to Basecamp’s People and Companies APIs.

We now allow client and firm employees to see people and companies that they have access to through projects. Prior to this update, firm and client employees could only see people using a specific project ID. There was no way for them to see all people (i.e., colleagues) that they are involved with across projects.

For example, if the API user making the request is on one project with Bob and another with Jill, /people.xml will return Bob and Jill. If the requesting user is an administrator, all people in the account will be returned.

The same is true for companies.

When programmers can both code and speak a language that non-programmers understand, things are a lot less likely to go wrong.

The transcript from Episode #22: Programming roundtable (Part 3 of 3) of the 37signals Podcast is now available. Here’s an excerpt.

Question from SvN reader: “How do you keep up your interest in a project or product? Generally I get bored with projects after a few months.”

Jamis: Our team structure, I think, really helps that because we aren’t stuck on anything for more than about two months…Generally we work on small things, quick iterations, two or three weeks maybe for a single feature and then you move on to another product even to add something there. There’s not a lot of opportunity now for getting bored with what you’re working on.

Jeff: Even before the team structure, we sort of naturally would do things in small chunks. If you’re getting bored then you’re not doing good work, you’re not motivated. And none of us want that. So, we sort of have this built in desire to keep things small and achievable so that we can move on to something more exciting. So, I don’t really give myself much of a chance to get bored. If I find myself starting to get bored, it means that I’ve got to stop and be like: “What can I ship now and how can I go on to the next thing that feels new?”

Jeremy: I think that that feeling of being bored, there’s a little bit of self-entitlement…If you’re bored, you’re boring. You need to think about what you’re doing and find excitement in it. It takes motivation, it takes energy and you’ve got to pour it in. And if you’re not feeling it, you’re not feeling motivated, the answer probably isn’t in the product you’re working on or the code you’re working on. It’s in your approach to it, how you think about it, and how you think about your life.

Read the full transcript.

Time: 25:28 | 10/11/2010 | Download MP3

Summary
Part three of the roundtable talk with three members of the 37signals programming team — Jeffrey Hardy, Jamis Buck, and Jeremy Kemper. They answer more questions from SvN readers.

More episodes
Subscribe to the podcast via iTunes or RSS. Related links and previous episodes available at 37signals.com/podcast.

It took me some twenty-plus years to really learn how to program. It wasn’t for a lack of trying either, it was just that I was trying the wrong way. I tried to learn to program by following tutorials that created programs I didn’t have the slightest interest in keeping. I was trying to learn for the sake of learning.

Now I’m sure that works for some people. Intellectually curious for the sake of it. I envy you. But that’s not how it worked for me and I know that’s not how it works for a lot of other people.

What made it click for me was programming in anger. Programming because I needed to. Programming because I gave a damn about what I was writing and I wanted it done sooner rather than later.

That’s how I learned to program Ruby. By making it my mission to write Basecamp in it. When you’re learning on a mission, the order of things come really naturally. So what exactly do I have to do to get this messages section working in Ruby? Oh, I’ll need to do a loop here. Oh, I’ll need to get something from the database there.

Before you know it, you’re half-way done with your idea and you’ve accidentally learned how to do it too.

In short, you start with little bit of something real and make it tick. Then you make it tock.

Time: 20:14 | 09/15/2010 | Download MP3

Summary
Part two of the roundtable talk with three members of the 37signals programming team — Jeffrey Hardy, Jamis Buck, and Jeremy Kemper. They answer questions from readers of SvN.

More episodes
Subscribe to the podcast via iTunes or RSS. Related links and previous episodes available at 37signals.com/podcast.

Time: 19:38 | 09/02/2010 | Download MP3

Summary
Three members of the 37signals programming team — Jeffrey Hardy, Jamis Buck, and Jeremy Kemper — answer questions from readers of Signal vs. Noise. Topics include Rails, Git, Mocha, Vim, nginx, Passenger, and more.

More episodes
Subscribe to the podcast via iTunes or RSS. Related links and previous episodes available at 37signals.com/podcast.