Why I Like Pair (or More) Programming…

As I prepare my apprentices for their interviews, I reminded them about the possibility of pair programming interviews.  While I wasn’t exposed to pair programming early in my career, once I finally was exposed to it, I was beyond thrilled!  These are some of the reasons why I enjoy pair programming.

Learning From Others

I really enjoy learning from others.  I never know for sure who I may end up pairing with, but I go into each pairing session with an open mind.  Whether we’re talking through the problem or writing the code, we may come in with different programming styles.  However, talking with each other and compromising along the way – I actually enjoy the whole process.  I am also open to pairing with developers of various skill levels – from novice/hobbyist to advanced.  In my past experiences, I have found that the communication and patience between the pair tends to determine what makes a pair successful, moreso than skill levels.  We come from different backgrounds, and I like watching how they come together.

Writing Better Code

With multiple eyes on the code, we can spot ways to improve each other’s code, or at least talk about the different approaches we would take.  In pairing, there has to be a lot of communication about the code, which means talking through complex issues and making sure not to approach a problem blindly.  By having these conversations and clearly conveying our thoughts, we have a better chance of writing better code than if we coded by ourselves separately.

More Than Two?

As the title suggests, I have been in programming situations where we’ve been a group bigger than 2.  My fondest memories go back to working on a team of 5 devs with 1 machine that happened to be remotely located.  Each one of us had different backgrounds – web developers, firmware/hardware/low-level developers, database developers, math genius, etc.  Quinting with those 4 devs taught me how to be a better backseat driver and how to play off of each others’ strengths and personalities.  Unfortunately, it didn’t break me of my inner editor – I still would point out missing semi-colons and mismatched curly braces.

Overall, I am thankful that I’ve had the pairing (and more!) experiences I’ve had so far.  So much learning, so many more avenues to think about while writing code, and so much desire to pair with others and have fun!

Special shoutout to my friends at LeanDog for giving me solid experience quinting with such an awesome team!


Lessons from the boat

Last week, I started working on my part-time contract with LeanDog. In the 3 days there, I’ve been privileged to work with a great team (Mike Lutton, Tim Conner, Bill Holmes, Huey Petersen, and Doc Norton). These are just some of the things I’ve observed so far.

Team Collaboration

As I mentioned above, I’m working with an awesome team. We have different backgrounds and can feed off of each other’s past experiences and strengths. It was great to feel a good chemistry with the team early on. But we’re not the only team on the boat. They have other teams for other projects, and it’s great to see those teams working together and bouncing off ideas as well. Yes, even though there are language differences (Python vs. Ruby vs. .NET vs. Java vs. others), we can still learn quite a bit from each other. Working on a boat surrounded by such diverse talent and collaborating with the groups – it’s been a great experience so far!

Pair {Anything}

This past week, I’ve been exposed to all sorts of experiences that weren’t afforded to me in other jobs. Since I’m still learning the ropes of the project and still the new kid, I’ve been able to pair with one of the guys in trying to work with some stuff. We’ve had pair testing, pair troubleshooting, and have decided that you can probably pair on any task.

But wait… our team knows no limits. While pairing works, sometimes, you need to solve a problem or learn a technology as a team effort. This is when Tim Conner’s “quinting” comes into play – 5 of us, 1 codebase, all figuring out the joys of Gherkin and SpecFlow.

New agile technique: quinting. Great Gherkin/Specflow session yesterday with @hueypetersen, @mlutton, @sadukie and @wch42 @leandog.less than a minute ago via web Favorite Retweet Reply

And now a pic of quinting (thanks to Mike Lutton!)…

Understanding TDD

In my past job, they talked of TDD as a goal, but never something that was really well-explained. Thankfully, most of my friends have been exposed to TDD, and I’ve actually listened to them, even at times when I would ask “Why should I write more code?”. If I’m asking “why”, I’m either not convinced of something or really am curious to know why to use something and will “why” my way to an explanation that makes sense. All of the things they’ve told me really made sense this week when I saw unit tests. Everything just clicked and made sense. There were even times when I looked at a test and realized “That shouldn’t be behaving like that.” Having been nervous about TDD and then just dropping into that environment – I’m very happy in this setting.

Feeling at Home

It’s nice to go into a place and feel at home, even as a contractor. In many places, I’ve seen contractors treated as outsiders, locked with more restrictions than the average employee. I’ve seen companies treat contractors as second-class citizens at times. And those are the companies I remember… so that I never contract with them. While working on board, I don’t feel like an outsider… I truly feel like a LeanDogger, and that helps me take pride in working for them even more.

Going Forward

I’ve known many of the guys at LeanDog for awhile, as they are well-known in Cleveland’s tech community. LeanDog hosts many user groups and is involved in a variety of the tech events here – including Ignite Cleveland and Cleveland GiveCamp. I’m looking forward to helping these guys and their clients out where I can. It’s good to finally be working alongside these guys!