Pair Programming to the Rescue!

I just think that code that is easy to understand makes my (and not only my) work easier. I don’t have to spend a tremendous amount of time going over the code and seeking answers to my questions. I know that small additional effort during the introduction of something new into the code base will save a lot of time in the future, yet this would impossible if I’m the only person in the project with this great passion to writing self-descriptive code. There has to be teamwork.

So Many of Us Know How to Do It Well

Most developers I know would agree on what are the good practices regarding software development. Continuous refactoring, well-written tests, TDD, and code review to name just a few. During discussions over coffee, they talk a lot about benefits that come with following those practices. Then they’re back to their desks and somehow, they’re not refactoring the code. Why? Because “I was in the zone, man.” They’re not writing tests because “the deadline is too tight and I was in a rush.” Maybe you've also experienced this. Maybe you're shaking your head right now. Yet, it happens. I've seen it too many times. Maybe those great developers who are evangelizing others, they, well, forget what they’re saying when they’re writing the code? Or maybe they’re just so good those practices are not applicable to them anymore?

Don’t Do It?

Maybe it would be just as simple as stop repeating that TDD (and refactoring, code review, and other practices) is so great because writing code in this way helps us increase quality and readability of the code? Well, I proposed it a few times and I always hit the loud wall of objections. Well, when you are not doing something, stop convincing others to do it. It sounds reasonable, doesn’t it? No one ever agreed on that, though, which is, of course, good, because my intention when I shared my proposition was to wake up developers around me, not to get them to stop following those practices. That was good but didn’t solve the problem. So what can help?

Pair Programming to the Rescue!

I can understand people who prefer to do things in a way that is easier and more familiar for them. In a way, they already have some experience. The known is always better than the unknown. The known is easier than the unknown. If people don’t have experience in TDD, for example, they would prefer to write code in a different way. But are they not the same people who extol TDD?

The answer is yes, and this is what can serve as an advantage.

Pairing is the practice that may help developers gain some experience. Why can it work? Where no one is looking, it is easier to make an excuse. To convince yourself that would be better (faster and easier) to make it in old school way, not struggling with this fancy TDD.

I think that most of us tend to choose less effort whenever possible. As I already wrote, the known is simply easier. But is it better? This happens when we are left alone. It’s pretty easy to write code in this way when we don’t have to explain anyone why we are not following the practices we are so strongly recommending.

It changes when we sit together with another developer. We are no longer so willing to not adhere to recommended practices. Why? Because we would have to explain ourselves. We have to have an excuse. And not a paltry excuse but a solid one. And it’s hard to make such an excuse. So, we are choosing easier way. We are following those practices. 

We are improving the code. We are writing it in a good way from scratch. We are writing descriptive tests, and much more.

It’s good that we constantly try to minimize the effort needed to accomplish something. Let’s use it as an advantage!