Category: Community

Our Pair Programming Experience – or, the first time we nerded out together and learned a ton

Our Pair Programming Experience – or, the first time we nerded out together and learned a ton

Pair Programming – What is?

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. (Wikipedia)

Why explain our experience?

At the end of 2017, we were both OpenShift Architects at our last employer. We were working on integrating the new-to-us platform with the existing processes of the organization – especially the build, deployment, and release processes. Most of the applications on OpenShift would be Java applications, and all Java builds were done with Jenkins. There was a release management tool that was written in-house serving as a middle layer to control deployments and releases.

Build and deployment when we started, mostly to WebSphere on a mainframe or WebSphere on distributed VM’s.

We (the organization) were also in the middle of transitioning from enterprise Jenkins + templates to open source Jenkins + pipelines. There were only a handful of people in the very large IT division who even knew how to write a pipeline – and we took on writing the pipelines (and shared libraries) that would prove out a default implementation of building and releasing to OpenShift. We knew this would be a huge challenge – if done properly, the entire company could run their OpenShift deploys on this pipeline, and it could be improved and grown as more people contributed to it via the internal open source culture that we were building.

While we figured out what to do, the pipeline just went straight from (the new, open source version of) Jenkins to OpenShift. POC FTW!

We ended up doing this via pair programming – because we work really well together, mostly. However, because we’re both technology nerds and also people/culture nerds, and because pair programming has some push-back from more traditional organizations, we wrote down the benefits we saw.

I know some stuff, and you know some stuff, but basically we’re both noobs…

We were BOTH the little turtle…

The team Laine was assigned to was the team that oversaw Jenkins administration and the build process, along with the in-house release management tool – but she’d only been on that team for about 4 months. She knew more about Jenkins than Josh, but….not by much.

Josh was the one who spearheaded bringing OpenShift into the company, and so he knew a lot of the theory of automating OpenShift deploys and had a rough idea of what the process as a whole should look like.

…basically, neither of us really knew how to do what we set out to do, and actually we didn’t intend to do something that fell into the realm of pair programming. We just already relied on each other for many things, including understanding and processing information, and we both deeply loved OpenShift and saw its potential for the company we also loved. We were determined to do as much as we possibly could to help it be successful.

What We Actually Did

Mostly our plan was to just…try stuff. We followed the definition of pair programming above some of the time – we took turns writing while the other focused more on review, catching problems, and planning the next steps. This was awesome, because we caught problems early just by keeping an eye on each other’s work – like, “uhh, you spelled ‘deploy’ D-E-P-L-Y, that’s not gonna’ work…”

Taking turns doing the actual coding also allowed us to churn through research while still doing development. We’re both top-down thinkers, which means that we understood the steps that needed to happen without knowing quite how we would implement each step. With one of us researching while the other was coding, as soon as one coding task was complete, we could more or less start right away on the next. Given the amount of research we had to do, this was huge in speeding us up. It also allowed us to switch up what we were each doing, and not get bogged down in either research or implementation.

Why is Heath Ledger Joker on this? IDK, who cares?? <3

In addition to taking turns coding vs overseeing, we also did a lot of what might be called parallel programming – we worked closely on different aspects of the same problem at the same time. This was also highly effective, but it required us to be very much on the same page about what we were doing. We did this mostly off-hours, via Slack communication, so…it wasn’t always a given that we actually were on the same page.

Despite the communication hijinks, or maybe because of them (it was really funny…), this was probably the most efficient of all of the coding work we did. If we got stuck or didn’t know how to solve a problem, the other could easily figure out how to help because we were already in the code. We also bounced questions and implementation ideas off of each other (efficiently, because we didn’t need to explain the entire project!), so…something like pair solution design.

And again, up there in overall efficiency, was some pair debugging. We could put our heads together to talk through what was broken (aside from typos…), figure out why it was broken, and land more quickly at the right solution to fix it. (See also: Rubber Duck Debugging)

This is where we landed after we did our part. We advised on tweaking the process, helped implement updates where we could, and…got out of the way and let the very talented and enthusiastic contributing developers take over.

Why it was Awesome

(Quotes in this section are from Strengthening the Case for Pair Programming.)

More Efficient

Two heads are better than one. Often, the part of development that takes the longest or is the most complicated isn’t writing the code  it’s figuring out what to do, and then figuring out what you did to break it and how to fix it.

Having a person there who understands the project as well as you do can speed up…well, literally all of that.

Higher Quality

…virtually all the surveyed professional programmers stated that they were more confident in their solutions when they pair programmed.

Pair programming provides better quality, hands down. We talked about this some already – a pair programmer can catch bugs before compiling or unit tests can, and they can catch bugs all the way from a typo to an architecture or design problem. Pair programming also requires by its very nature discussing all decisions – both design and implementation, at least at a high level.

…basically, you end up with an application where there’s been a design and code review for literally every aspect of the application.

Resilient Programming FTW (or, You Can Still Make Progress Even when Your Computer Dies)

We both had some laptop issues in all of this – Laine had some battery issues, and Josh had his laptop start a virus scan (slowing his computer to the point of being unusable) while he was trying to code. We got on Slack and helped the one who still had a working laptop, rather than that time just…being wasted.

Relationships, and Joy

…more than 90% stated that they enjoyed collaborative programming more than solo programming.

Best nerd celebration emoji.

Laughing at mistakes, getting encouragement (or trolling) when we did dumb stuff, nerd emoji celebration when something went well – all of these were better because we were working together.

It was just…fun. There was joy in all of it, in both the successes and the failures. And there was joy in the shared purpose of setting something that we loved up for success.

When making a pair…

There are a few things we learned that were vital to pair programming going well for us. We think that the following pieces are the most important to a successful pairing:

Trust

Without trust, you lose some of the benefit of pointing out mistakes and instead spend the time you’d gain making sure that feelings aren’t hurt. Based on our experience, we actually think that this one is the most important key to success.

Temperament

You’ll want to find someone with approximately the same temperament and, uh…bossy-ness. We went with Bossy-ness Level: Maximum, but you do you. We both push for what we think is the right solution, and we kind of enjoy arguing with each other to figure out whose solution really is right. If either of us had paired with someone who was uncomfortable with conflict, chances are it…wouldn’t have gone well.

Technical Level/Skill/Experience

Pair programming probably isn’t going to work very well with a brand new associate paired up with someone who’s been in the industry for 10 years. That’s a lot of context to explain, so while this set up is amazing for training purposes, it isn’t the most effective for software delivery.

Lack of Knowledge

Look for someone who knows something you don’t about what you’re trying to accomplish. Laine knew Jenkins and is a Google savant, and Josh knew the OpenShift theory and reads constantly – when automating releases to OpenShift, it was a good combination.

And Finally

Pair programming provides a ton of value. It speeds up development, catches bugs sooner, and aids dramatically in design and implementation. It’s also fun, which is important and sometimes forgotten about in the just deliver more world of IT.

We loved working together on this, which led to much joy in learning the deep knowledge necessary to build a pipeline the whole company could use. And, even better, it worked – teams that joined OpenShift used and improved upon what we did, and those teams implemented continuous delivery on OpenShift. We’re both very sure that we never have been that successful if we hadn’t paired up on it.

It Doesn’t Have to Be Perfect

It Doesn’t Have to Be Perfect

In a previous post, we talked about how important kitty typing and determination are to technical execution. An important addendum to this is that whatever you do doesn’t have to be perfect.

Now, the first response to that is most likely to be an objection:

You: But…Laine and Josh, quality is so important to companies! It’s like, job #1: don’t mess it up. How can you say that it doesn’t have to be perfect?

Read More Read More

There are No Maps in Leadership

There are No Maps in Leadership

We were talking the other day about our leadership style, and what worked (through trial and error) for us. We came up with four points that we thought were critical.

Josh and Laine’s Plan for World Domination Leadership:

  1. There is no map
  2. Don’t be a jerk (unless necessary)
  3. Be good
  4. Find a partner/community

Read More Read More

Idols and Alone and Rest for Your Soul

Idols and Alone and Rest for Your Soul

People Seem Safer than God

 Come, all you weary.
Come, gather ’round near me,
find rest for your soul. 
Thrice, Come All You Weary

“Come to Me, all of you who are weary and burdened, and I will give you rest. All of you, take up My yoke and learn from Me, because I am gentle and humble in heart, and you will find rest for yourselves. For My yoke is easy and My burden is light.”
Matthew 11:28-30

Read More Read More

Choice-Based Relationships

Choice-Based Relationships

Relationships and Control

We’ve talked in the past about how control is an illusion – we can’t control the world around us, and all we really have are the choices we make.

We’ve also talked about how manipulating people only works when you’re the smartest person in the room.

One of the things that’s been a struggle for both of us, individually and as friends, is how do we make sure people will stick around? We all, at our core, don’t want to be alone. We want to be known, and appreciated, and maybe truly loved, but that…sure seems like a lot to ask. Most of us only manage to shoot for being a little bit known and sort of vaguely liked. And that’s actually pretty great, if it happens.

Read More Read More

Laptop Stickers: These are My Nerd Gang Signs

Laptop Stickers: These are My Nerd Gang Signs

I seeeee you!

One of our favorite things to do is to observe people. You can learn a ton about people by watching them (uh…in a non-creepy way, ideally) and seeing what they display as valuable. With nerds, one of the best ways to do this is to look at their laptops – make and model and operating system, sure, but actually the best source of information is to look at their stickers. A laptop is very important among nerds. It is the tool with which they fulfill their purpose, and so it has inherent value. It’s also only so big, so real estate given to stickers is important. You can learn a ton about a nerd by the tech and things they choose to affiliate with.

Read More Read More

Trust: What is?

Trust: What is?

Fun fact – the Building Reliability blog post was originally called “Building Trust.” It was old content – some day we’ll tell the story of everything that happened between when it was originally published and when we published it here, but suffice it to say that a lot changed okay.

Because of what changed, Laine was immediately and thoroughly triggered by defining trust in some part as “doing what people expect of you.” Some number of arguments later, we agreed that what’s described in that post is reliability – which is in fact different from trust. And…then we started trying to define and explain trust. Turns out, it really isn’t easy. After a lot of paying attention to where we stumble in trusting other people (spoiler alert: we’re both awful at it, actually…), this post was born. Finally.

We’re going to explain in more detail, but here is the basic definition:

Trust: believing that the other person loves you enough to figure it out – whatever it is.

Read More Read More

Plan Replace Me

Plan Replace Me

One of the greatest things about being a leader, for us, is building deep, enduring relationships with the people and teams we work with.

One of the hardest things, for us, about being a leader is leaving the relationships we’ve built. This is a sad, painful process. We love people a lot, and we keep leaving, maybe because there are always more dragons to teach people how to slay.

Read More Read More

Awesome Permission

Awesome Permission

One of the things we’ve noticed while mentoring is that some people suddenly take off like a rocket – they accept responsibility for more than they previously took on, and then they seek out more. They also handle this increase in responsibility very well, and they impress people who previously were at best neutral – along with people who were previously disappointed.

We’ve seen it happen, and we’ve been trying to figure out how to describe what the pieces are, because if a cool thing happens, you should explain how to reproduce it.

So, we began to think of it in terms of the process, the ingredients, and the result.

If a cool thing happens, you should try to figure out how to reproduce it.

Read More Read More

Technical Leadership Progression, part 2

Technical Leadership Progression, part 2

In Technical Leadership, part 1,  we talked about how someone grows into a technical leader aware of their team. In this post, we’ll continue on to describing a Tech Lead who takes ownership of their teams’ success, and then moves into the higher levels.

Read More Read More