Brendan Enrick

Daily Software Development

Two Minds Code Faster Than One

I’m not exactly silent in my belief that pair programming will help our industry, so it should come as no surprise that Steve Smith and I paired together on a Pluralsight course on Pair Programming. It only made sense to me that a course on pair programming would be created by two people. We shared the work on each module of the course, and we think it turned out well.

In the course, we cover the theory, practice, benefits, technique, and research of pair programming. From this, we’re trying to make sure that people both know how to pair program effectively and know why it could benefit their team. If you or someone you know has heard of pair programming, I’d recommend watching the course.

Given the choice of typing twice as fast or thinking twice as fast, I know I would choose the latter every time. That’s why I always choose to pair program when someone is available to. We accomplish far more together than we do separately. You’ll learn how and why when you watch Pair Programming.

StandingPairing

There is no “ego” in “Agile Team”

Programmers are talented, smart, skilled professionals. We put in lots of our own effort to educate ourselves and stay up on current technologies. We work hard and we feel great satisfaction in our achievements. We donate our time to charities when the opportunity arises. We give back to our local communities. All things considered, there are a lot of really great programmers in the world.

I lead a team of software developers. Does that mean I am the “best” programmer on the team? Certainly not. It just means that I lead the team. As the leader of the team, it is my job to: inspire, encourage, trail blaze, and motivate my team to be the best they can be. So who is the best programmer on my team? I don’t know, and I don’t care. There shouldn’t really be a “best” programmer on the team. Everyone on the team is great and working hard.

A team that really meshes and works well together doesn’t let egos get in the way. It doesn’t matter if you’re a rock star developer. When you’re on the team, you’re part of the team. You might be the JavaScript expert, the master of SQL queries, or the guy who can refactor anything. When you’re part of the team, you should try to use your strength, but don’t let that interfere with the team’s flow.

WP_000518Sometimes it makes sense for a more experience developer to work with a less experienced developer. A common first instinct is that the senior person is mentoring the junior person, but it’s actually going both ways.

Each of the two developers is bringing a lot to the table. Their different experiences and views allow them to each approach the problems differently, ask different questions, and apply different, existing knowledge.

If either person’s ego gets in the way, it would prevent the 2-way knowledge transfer in addition to creating friction between them.

WP_000541One Developer and one Junior Developer can pair on a task and share knowledge. Does one act like the other one is just along for the ride? No.

Your pair partner, is watching your back, guiding the team, and keeping the pair honest. Which one does that job? Both. If you had one person drive the whole time, you’re not going to see the benefits of pair programming.

If you let your ego get in the way, you might not let the junior developer write any of the code. They may not know every library, every design pattern, or even the intricacies of the language they’re using, but those guys can write some great code.

I don’t know how the Junior Developers are on your team, but ours write great code and show a high level of professionalism in their work.

RichAndEricAnd sometimes you get a Junior Developer pairing with the Developer Intern. How the pairs split up doesn’t really matter. Who is working with whom doesn’t really matter. Each and every member of the team is bringing something to the table, and it is this interaction that is making the team as effective as it is. These two are as productive a team as any other pairing that we’ve got.

Someone is probably reading this and thinking I am crazy for letting a Junior Developer and a Developer Intern pair together. They’re good though, and they really get great stuff done.

We can accomplish a lot of stuff when our team works individually, however, we can accomplish a lot more as a group. You might be the “best developer” on your team, but if you keep thinking and acting that way, you’ll be missing out on a lot. I learn a lot when I pair with any member of my team. It doesn’t matter how much experience the person has. Everyone knows something I don’t, and no one approaches the problems exactly the same way I would.

There is no “Ego” in “Agile Team”, so don’t bring yours to an agile team and expect good results.

Let Others Work on Your Code

Don’t be overprotective of your source code. Allow others to make modifications, improvements, refactorings, and even defects (as long as those get fixed immediately). I am talking about two different Extreme Programming practices here: collective code ownership and pair programming. A non-developer friend of mine has been reading about agile software development and asked me last week about pair programming, "do you guys do this 'pair programming' thing?"

I think even among developers the pair programming concept is one of the strangest aspects of extreme programming.

Yes, a lot of agile development teams use pair programming. We even equip our facilities to make pairing easier. Our computers have 2 large monitors, 2 keyboards, and 2 mice. Some teams pass the keyboard and mouse back and forth, and that works just as well.

What is Collective Code Ownership?

This is a great term that basically says that every member of a team should be able to work on any part of the system. If you’re usually working on the user experience you can still spend some time working with your application’s service layer, and if you’re the database guy you can work on some business logic.

Wouldn’t someone be able to do that job better? Yes, there probably is someone who knows each part of the application better than anyone else. You can work with that person if you want, and the two of you will be able to create some great code. What if that person who is better at that task is on vacation? Wouldn’t it be great if someone else knew the code.

Keeping the team familiar with the project means that the team can focus on certain parts of the system at a time and achieve great results. You don’t have to split your team based on layers or modules of your application. Let them intermingle. Fresh ideas and eyes can greatly improve things. They might come along and fix a defect or two for you later; saving you a great deal of work.

Why Pair Program?

Pair Programming The mind is the important part of programming, so why not have two? After all, programming is certainly not just typing. If you believed that how could you ever support pair programming?

If you pair program for every line of code in your application then you know that you’ve had at least two sets of eyes look at every line of code. This is a good deal of added security.

When you create some new piece of code that the whole team will need to work with, pair programming can be the solution to disseminating this information. You and the guy you created it with can split up and pair with another person each, and while working on the code you will each be showing your new partner how the new code should be used. This allows new information to spread quickly through the team.

Even the simplest things as learning keyboard shortcuts are improved by pair programming. When I use a cool keyboard shortcut, I can tell my partner what it is without breaking my train of thought. We can keep on typing, and when he has the keyboard in a minute or two, he can try it.

Pair Programming Computer Just like athletes, a programmer needs someone else there to help him keep the pace. You partner can help you avoid distractions, and most importantly he can keep you from taking shortcuts. When we write code we might say, “I can fix this later”. The partner will make a note of it and be sure you get it fixed later. If it can’t wait and you’re in the middle of something you can always pass it to another pair. Your partner can do that while you keep on coding. Remember that the other pair can work on any code because of the collective code ownership.

I am sure I missed plenty of reasons to pair program, but this list feels mostly adequate to get the point across.

Please let me know why you do or do not pair program. Is it work related? Are you an unbeliever?

Something to Avoid While Programming

Some activities and thoughts need to be avoided while programming. Sometimes we realize our mistakes and do them anyway. I admit that in my time developing software I’ve probably done this more times than I would like to admit. I make an effort to avoid making these types mistakes, and I attempt to encourage others to avoid the same pitfalls. While working with others I certainly tell them when they’re gravely mistaken about something.

The first thing I would like to emphasize is that this mistake is fairly common everywhere in life. It is of course procrastination, and I think I’ll rip off the classic line I’ve heard a million times. Don't put off until tomorrow what you could do today. Now I need to be careful how I say this, because I could get YAGNI people jumping at me for saying this. Obviously don’t do everything today just because you can. That is silly, but things that will assist greatly in maintenance should not be put off. Since I’ve been on a bit of a testing kick lately, I might as well focus this toward testing.

I am sure a lot of you have been in the situation where you really just don’t feel like writing your test before you write your code. Ha! Who am I kidding? Most developers don’t follow TDD anyway, so most of the people reading this wouldn’t have done that anyway. A large group of developers have started writing unit tests in general even if they’re not writing them first. However, this still applies as I am sure many of those developers want to wait until a full feature is “complete” before testing.

Your code is not complete until it is tested. Keep in mind that down the road you might forget the business rule you were coding, so it is important to create the tests at the same time as you’re writing the production code. Developers will try to say, “we will write the tests when we’re done” or “we’ll refactor this later”. Do not dare believe a word of that crap. Always assume you will not have time to come back later and refactor. There is a good chance you will not have that chance. Also if you don’t fix things now they’ll just bite you later.

One way to help keep yourself on track is to work with a partner. One very powerful aspect of pair programming is that the second person will nag you and force you to get to things now. That is part of the job description for both parties while pair programming. Don’t let the other person skip out on anything. Be careful though, because that other person will be just like Wimpy saying things like, “I’ll gladly test that Tuesday to continue coding today.”