Interview with Corey Haines, August 2011

Our first post is a voice interview I did with Corey Haines in Dulles, Virginia, on August 18, 2011.


After 12 years of coding for money, Corey Haines said enough and went on a year-long, journeyman pair-programming tour. Traveling the world, pair programming for room and board, he spent his time teaching, learning and just living as a knowledge-cross-pollinating, little, software craftsmanship bee. For the past three years, Corey has focused his attention on helping developers improve their fundamental software design skills through the use of focused-practice events, such as code retreats. 1

The Pairing Journey

In the first part of the interview Corey tells us about his inspiring and unconventional journey, which began with, of all things, being fired from his job. He immediately picked himself up and planned his next move. Thinking outside the box, he set out to teach and learn from his colleagues in the technical community, starting with David Chelimsky of RSpec fame. That is, he literally set out, visiting them for up to a week at a time, sleeping on couches, absorbing their wisdom, passing it on to the next people and offering some of his own. Corey is now an internationally known and respected member of the Ruby community, leading code retreats all over the world.

Corey’s Thoughts and Observations

In the second part Corey shares his observations about organizations, teams, and individuals in the workplace. Here are some of my favorite quotes from it:

“…most of the companies that I really admire, they don’t call it agile, they just call it software development, so for the techniques that XP has, they wouldn’t dream of not doing automated testing, because that’s irresponsible for your client. Now, they do it and they learn about it, they find pain points with it, and instead of abandoning it, they inspect it. Are we potentially doing it wrong, are we potentially doing it in an immature fashion, are we doing it in a way that we can fix, and so they’re constantly inspecting.”

“You can bring inexperienced people in, but don’t put them in a corner and have them sit there hacking out code. Bring inexperienced people in and treat them as equals, treat them as people that you’re mentoring, treat them with respect, and they’ll strive to do that, and if they don’t you cut them. If they’re not that kind, then you get rid of them and you bring in the people who are of that nature.”

“I think the most effective way [of collaborating], which does not mean it’s the only effective way is big open room, big huge monitors, live input devices for everybody, so two keyboards, two mice on a machine.”

“The companies that ate together that would either bring lunch in or people would go out and bring it back or they would go out in groups of six or something, but if you eat together, it just was wonderful because you got in in the morning and it was your family that you spent the day with…those places I loved. It just breeds that excitement about it, and it breeds responsibility, and the better you know your teammates, and the more affection you have for them, the less you want to let them down, and you’re willing to work on your own skills to that you don’t let them down.”

(Q: “In the places you’ve encountered that have been the most productive and successful, what are the leaders like?”) “I think they all seem to be very engaged, they all seem to like the people, they want the people to be happy, and they tend to be engaged in the day to day stuff. Either they’re actually sitting on the floor with people working, or they are in there a lot, or they are in the meetings a lot, but they tend to be very engaged, and have a good philosophy about both software and people.”

…and my favorite one:

“Software development is a very social activity.”

I hope you enjoy listening to this as much as I did.

Corey can be found on twitter as @coreyhaines or at Screencasts and articles about Corey’s programming tour are available at (check out the older posts).

- Keith Bennett,

Show Notes:

00:20 – The adventures of Corey Haines and traveling around the world

  • Spending time with people with different experience levels and personality types
  • Meeting people and building a network
  • Connecting people together

02:00 – Tendencies to work in a very insulated community

  • Working around others gives you a view of where you stand between them
  • These people are better than me/I’m better than those people
  • Self-realization in skills; what I’m good at/what I’m lacking

03:05 – Finding people and having them find you

  • Pairing for room and board
  • Video interviews with everybody he stayed with
  • People started noticing Corey
  • Acquired notoriety on Twitter
  • People started inviting him to come to them

12:30 – All of the above stemmed from a “negative event”: getting fired

  • Firing people who just don’t fit in is an effective company practice
  • Support after getting fired helped to lift him back up

16:25 – Establishing a reputation within the Agile community

  • Talking to people
  • Shaking hands
  • Attending conferences
  • Forced himself to meet people and overcome shyness
  • Became more able to hold a conversation

19:40 – Using Ruby

  • Previously using the Microsoft ecosystem
  • Professional programmer since 1996
  • First Ruby he ever wrote was in 2006

23:50 – Different ways of doing things/insights

  • Small teams work best
  • Internalizing extreme programming
  • Agile versus software development
  • Giving the most value to clients

28:07 – Hiring the best people for a job

  • You can bring inexperienced people in
  • Treat them as equals and mentor those who want to learn. Cut the ones who don’t
  • Software development is a very social activity

29:45 – Effective ways of collaborating

  • Big open room
  • Big huge monitors
  • Live input devices for everybody
  • Being co-located
  • Companies that eat together

32:15 – Who to pair with and when

  • It depends on an individual’s time cycle

33:35 – People who resist pair programming

  • Not an easy skill to learn
  • Resist because they’ve never had an effective pairing session

37:06 – Leadership

  • Engaged in day to day activity
  • Want to see people succeed
  • Participate in meetings
  • Good philosophies on software and people

38:08 – Learning new technology to do your job

  • Set aside time to focus on practicing it
  • Your company should not get paid by their clients to learn technology
  • Good companies want you to learn

44:40 – Where is Corey today (as of interview, August 2011)?

  • Lives in Chicago
  • Working on a start-up app with his girlfriend called Mercury App–an application to help individuals and teens make better decisions
  • Side projects
  • Internal training at companies and talking about taking time to practice
  • Code Retreats


  1. This paragraph copied from Corey’s bio with his permission.

Welcome to!


Human, nontechnical issues routinely make and break billions of dollars worth of software projects.  They also have a huge impact on the happiness or misery of software professionals.  Why is it, then, that so little is said about them? is a nontechnical blog for technical people.  We discuss maximizing project success and team happiness by:

  • exploiting individual diversity rather than treating developers as interchangeable parts
  • cultivating a sense of shared purpose so that a team *feels* like a team
  • encouraging developers to share expertise with each other and creating an environment of collaboration, not competition
  • making the workplace a place people look forward to being every day
  • getting to know colleagues better
  • supporting efforts to better learn the craft
  • ensuring that people feel valued, respected, and safe

This blog is primarily for developers, but managers, executives, and others are welcome too.

If you have any ideas, suggestions, or would like to help out, feel free to email me, or join the Tech Humans Google group at and post there.

I expect we’ll be posting articles, audio interviews, and videos. Our goal is to be entertaining and engaging in addition to being informative. Sometimes the best medium to accomplish this is story telling. If you have a story you’d like to share about the dramatic effect of human issues on a project or in an organization, we’d like to know about it.

Check out our podcasts here.

Thanks to Avdi Grimm whose WideTeams blog inspired me to start this one.

Keith Bennett
Reston, Virginia, USA
July 2012