Traveling Pair Programming with Software Journeyman Corey Haines

Derek Neighbors: Welcome to another episode of the “Scrumcast”. I’m Derek Neighbors.

Corey Haines: And I’m Corey Haines.

Getting Kids Involved In Programming

Derek: Corey, I wanted to talk a little bit…You’re pretty well known in the community, at least in the software developer side, also a little bit in Agile and the eXtreme Prgramming XP side. I find your story extremely fascinating on a number of levels.

One of the things that always intrigued me is that you started programming relatively young for the average programmer, I would say. I’m curious a little bit about how you got started, and I think people can find some of that online.

What would you tell parents who had kids that were interested in computers or programming? What would you tell them to encourage them to let their kids get into this kind of craft?

Corey: I think nowadays, like I got in by cheating at video games. We had all the source codes so we could go in and change the source to let us get past points that we couldn’t get past. Nowadays it’s a little bit more difficult to do that, with all the games are huge and compiled.

Now with the physical computing stuff that’s so pervasive and so easy to get into, like with the Raspberry Pi stuff that’s coming out and Arduinos, really grabbing the attention of the kids via physically doing stuff.

I’ve done a little bit of work with teaching kids. I taught a class last summer and we used Scratch for programming. It was just amazing to see kids pick it up. It’s a graphical programming environment so there’s a lot less of the frustration of syntax errors, things like that. I’d say get into, bring those sorts of things. There a lot programs going on now around that are sort of centered around teaching kids to program.

Derek: Absolutely, we run one here at our work space, so absolutely.

Corey: That’s neat.

What Would You Tell Your Younger Self?

Derek: What would you tell your younger self if you could go back in time to that 10‑year‑old Corey Haines, what would you tell yourself?

Corey: Don’t go into Microsoft technologies. Simply because of the fact that when I started spreading my eyes out a little bit and started looking beyond the .NET space and, even before that, the VB space, that’s when I really found this amazing community of learning and the community of not just one language but most people out there that I meet are some form of polyglots.

The open‑source community is very supportive. I got into VB, C#, doing a lot about it in the corporate environment for longer than I wish I had. It was about 2004 when I started looking outward mostly through the XP community. And I wish that I had started sooner.

Year Long Pair Programming Tour

Derek: I think that segues really well. You talked about being in the corporate community, and certainly, how you came on my radar was when you took your yearlong tour where you said, “You know what, I’m really kind of tired of this corporate thing, and I’m really interested in really becoming a master at what I do and really broadening my horizons and working with different people.”

As part of that, you took a yearlong tour so to speak to go work with a wide variety of people, a wide variety of projects, technologies, you name it. What inspired you to do that?

Corey: In 2008, I actually left my last corporate job, joined a startup for about seven months, got fired from that startup because it just was not a cultural fit for me. Then a friend of mine and a good mentor of mine, J.B. Rainsberger, he and I for quite a few years had been talking about how great it would be to do something like Paul Erdős who was a mathematician that would basically just go everywhere and do math with people.

We always have that idea of, “Man, would it be great to have the opportunity to just go program with people? No overhead. No expectations. Just go program, go code with them. See what they’re doing. Learn from them. Teach them.”

When I got fired, I had some money saved up and was just like, “Now is the time to do it.” There’s so much out there to learn. There’re so many people out there to learn from and teach. I set up a three‑week trip.

Then it snowballed into that. It was originally only intended to be about three weeks. But during those three weeks, it started to snowball, and I started setting my eyes outward a little bit and realized that there was a whole range of people out there, that I could go code with.

It was always anywhere from a day to five days. So there was…I would come in, the only rule was, I was doing it for room and boards. I needed a place to stay and I needed food and I was pairing with somebody the whole time. And that was sort of the only rule that went with it.

Self-Awareness Was Found

Derek: What was the best part about that experience?

Corey: There were a lot of really great parts. One of the big things that came out it that I had started with this idea and actually came to fruition was. I had a much, much, better sense sort of where I was, level‑wise.

I had good understanding. I’d worked with people, who’ve been programming longer than I’d been alive. I worked with people who’ve been programming for a few years. It really gave me an opportunity to reflect on just where I stood as a developer. I was about, 11 years into my professional career, may be 12 years in.

We often times get caught up in our own community and we have a sense of where we are relative to the other people in our community. But by going out and just working with as many people as I could, I got a better sense of that.

I learned something in one place and then the next day, I would be teaching it to the next people. That sort of helped me, really solidify a lot of my understanding of the, a lot of the core fundamental techniques, that I use when I program.

Putting Developers On Safari

Derek: I think that’s a huge, a huge deficit that this occupation has, is, it’s really hard to have a measuring stick where you are. Sometimes, if you think you are really great at something, may be you kind of pull back and you stop engaging, you stop learning.

One of the things that kind of excites me is, what if we get to a point where, companies start to put programmers out on loan, so to speak. What if it was a corporate culture to allow a little bit more polyglot behavior and allow developers to kind of meander between different corporations to help get some of that litmus test where they are at?

Corey: Actually in 2010 and 2011, there was a group of companies that were doing just that. There is a group of seven consulting companies, like Relevance and Optiva and [8th Light]](https://8thlight.com) and a few others around the world. They started swapping employees for a week here, two weeks there.

Derek: That’s great.

Corey: Yeah. It was really neat to see.

The Downside To Jumping Around

Derek: I suspect there is a ton of great experiences. What were some of the bad experiences? What was the worst part about being on the road and working with different pairs, different technologies, different thing, every week or every five days?

Corey: A lot of it was, this is kind of a weird answer, that the worst part was the fact that it was just so utterly exhausting. I look back and I’ve thought about it a lot and there weren’t a lot of moments where I was like, “Man, this kind of sucks” or “This is difficult.”

It was a wonderful experience, I was going around, I meet people, I pull my car into somebody’s house that I had never met before, just come in, sleep on their couch and then code with them all day. But it was incredibly exhausting and probably about the first five or six months, I was doing short, several weeks, may be month long trips. Then I spent the summer of 2009, 3 weeks or 3 months, continually on the road and drove 6,900 miles, went from Cleveland to Miami to Prince Edward Island back to Cleveland.

It really was incredibly exhausting, but that exhaustion was exhilarating because I was learning so much and I was meeting people and seeing things and so I think it was really just that exhaustion was the major negative part.

Software Craftsmanship

Derek: It is part of this kind of journey of learning, so to speak, we’ve really seen the software craftsmanship movements start to bubble up and the metaphor of going from apprentice to journeyman to master. I know that you’re a big part of the craftsmanship movement. Why do you identify with that, and why does that metaphor strike a chord for you in relationship to software development?

Corey: Well, I really like the craftsmanship movement, the craftsmanship community because it covers the gambit of how do we bring people in to software. How do we train them through the years? Along the way, how do we interact with our customers? How do we take pride and how do we treat our code? All of these things, specifically with the apprenticeship to journeyman and beyond.

I have a hard time bringing the master term in mostly because…The only place that I use it is when there’s somebody that I personally look up to and learn from as opposed to an external, “This person is considered a master.”

I have much more focus on the idea of apprenticeship, of coming into a trade and learning somebody else’s way. I look at it as, apprenticeship is when you are studying under somebody and learning the way that they develop software. You find somebody who is an effective, proven software developer, and you learn their methodology and their techniques and their practices.

Then there’s a point where you got those practices down, and you can sit there on your own and really take the effective atom. When you have that, it’s important, I think, to go out, cast your eyes out, look at the people around, find somebody and say, “Hey, they’re doing something completely different than I am” or “They develop software differently. They don’t use some of the practices that I use, but they’re being effective.”

Go look and learn from them as well. You’ll bring stuff to share with them. You’ll be able to learn somebody else’s style. When you do that, you then start to merge those two styles in yourself, and you start to learn, and you start to reflect over those techniques. That is something that I think really could further our understanding of software development that I really like to happen.

Criticisms Of The Craftmanship Movement

Derek: Absolutely. There’s a few folks in the agile community that are critical perhaps of the craftsmanship movement and really struggling with tying the concepts of software development as an art form opposed to more of a scientific form.

The biggest criticism that is universal between the detractors seem to be that when we move to the metaphor of craftsmanship, the fear is that we’re turning all of the focus into the actual act of the creation of the product opposed to the deliverable of the product or the output or the effects that the product has on whoever you’re building it for.

Some of the examples are ‑‑ if you’re more worried about the stylistic making of the table so to speak in which it would be used, you’re not focused then on how it would necessarily be used in the real world. So maybe you can answer some of those detractors.

Corey: I understand where that is coming from and where those fears are coming from. There are people who have written [indecipherable 14:18] . I have a tremendous amount of respect for and had a great conversation with them about this last fall.

The thing is that being in the software development community and being in the agile community and in the craftsmanship community, we spend most of our time developing software. The things we talked about tend to be around developing software and the screencast that we do tend to be about developing software.

But there’s a very important part of the Craftsmanship Manifesto, which is the Productive Partnerships, which is really about the way that we deal with our client, the way that we partner with them to deliver software to them that is fit for use. It’s exactly what they need. No more, no less.

A lot of the craftsmanship thoughts came out of a reaction towards just the general level of horrible code that’s out there. So a lot of the emphasis that we put is on learning some of these techniques. There’s no more question about whether or not automated unit test provide value the majority of the time, and that TDD is a valuable, value‑providing method for doing design of your system.

Is it always a hundred percent of the time the thing you should do? I was talking to Fred George…He had given a great talk at SCNA where he said that if it’s faster to rewrite your system, then you don’t need to do TDD. Well, that makes sense. If it’s fast, if you’re writing a script or if you’re writing just something that’s very quick to put out there, maybe you don’t do it.

But the majority of people aren’t at that point. The majority of developers out there were not to the point where we have the experience necessary to make those decisions. I very much tell people, “Always write tests.” It’s better to overwrite them and then to reflect on the problems that that caused than to have no test at all and not do any sort of test‑first development and suffer the consequences of that.

We’ve all been through those projects, and we know that doesn’t work. We have a set of practices that ‑‑ discussion’s over ‑‑ they do work. It’s just a matter of knowing how to apply them, and you learn how to apply them by practicing them.

We talk a lot about this. If you go to the conferences that we’ve had, if you talk to the people that are involved in the community, and you go look at some of the companies that consider themselves craftsmanship companies, like say 8th Light here in Chicago, their focus entirely is on satisfying what the client needs. It’s not about polishing it. It’s not about gold plating it.

They have a very active, incredibly successful apprenticeship program. They do [indecipherable 18:00] with their people. They do all of the things that we talk about that people say we’re overly focused on, but you can’t get better if you don’t practice. The state of the software industry is atrocious right now, where doing things and making mistakes that we should not be making on our day‑to‑day jobs, so that’s a long one to [indecipherable 18:25] , so I hope the kind of…

Community Coding (Code Retreat / Code & Coffee)

Derek: It’s great. When you get to the core of it, I think the community is addressing the symptom that we see on a regular basis, which is really bad code and really bad practices. You have to get through that to get to the good stuff.

Corey: Yeah.

Derek: Speaking of community, you do a ton of community work with Coderetreats and Code and Coffee. You’ve got a number of projects out there whether it’d be your CodeCast or How I Got Started Programming series, I definitely think people should check out and get engaged.

Do you have anything new that you’re working on that you want to share with people?

Corey: I just last December started a nonprofit sort of centered around the Coderetreat stuff. We had this Global Day of Coderetreat] last December where we had 94 cities, all doing Coderetreat on the same day. They were Skype calling back and forth, and it was just this wonderful day of bringing basically the whole globe together on a single day.

Out of that, I brought out a nonprofit called the Coderetreat Community Contribution Fund], which right now it’s operating as nonprofit. We’re under 501(c)(3) review, but the goal of that is to be sort of an umbrella organization for doing fund raising to support kids programming events as well as a small amount of the funds will go towards supporting adult practice oriented workshops of the Coderetreat nature, don’t have to be Coderetreat but just sort of practice oriented.

I’ve been working a lot on that lately, just sort of how do you fundraise. I just did a Coderetreat in January that raised $400 and turned that around and sponsored, in San Francisco, there’s an organization called Black Girls Code, which is focused on teaching underserved girls to program.

They’re doing a six week course on the national stem challenge for writing video games and stuff. We took the $400 we had and we paid for snacks and drinks and stuff for them.

The big thing that I’m really excited about now is that is sort of figuring out how to help these programs out there like KidsRuby, Hackety Hack, Black Girls Code, Code Now, and use some of the excitement that we built up around Coderetreat as a way of raising money to support that where we’re going to be doing Global Day of Coderetreat again this year in December, and the plan is for about 200 cities around the world to do it. My stretch goal is to have a Skype call with a space station.

Derek: There you go.

Corey: I figured if you’re going to have a stretch goal, it should stretch to outer space.

Derek: I’ll say if you’re listening to this, next year you need to participate in the Global Coderetreat. We’ve done it here at Gangplank a few times. We definitely participated last year in the global initiative, and it’s well worth everybody who participates time.

Corey, thank you so much for joining us today. I love the work you’re doing. I love what you’re doing to pay it forward, and you’re really a model for other developers out there to care about the code and really care about the community. Again, thank you for stopping by.

Corey: Well, I appreciate it, Derek.

Derek: Thank you.

Corey: Thanks a lot.