I have a confession to make - I don't like to code. It's not like I don't know how to do it, but I simply don't enjoy it. And that is also not the full truth. I really like some aspects of coding. I love to try and figure out a solution to a problem in front of me. Drawing flow diagrams and creating classes and figuring out the overall logic is a super fun task to do. It is great mental exercise and I love to do it at every opportunity given.
But I don’t really like to translate this highly logical concept into language that a compiler will understand. Talking to computers has many rules and it gets messy for a human at times.
Sending an API call, I can do that easily. Writing a method that takes given inputs, processes them and gives you an output, I can do that, I guess. But connect those two, sprinkle in some weird language specific syntax, make me install a library to solve part of the problem and you are slowly starting to lose me. I want to learn new stuff all the time about how things work under the surface, all the questions that start with why and so I find these activities to be a little tedious for me.
Don’t get me wrong, I fully understand how somebody else might enjoy these activities above everything else. I don’t think they are any less than the work I like to do. I just personally don’t enjoy them. Well, hard luck, I guess. I am in a position where I am expected to (also) come up with automated checks. It is important that I get these tools going, whether I like them or not.
There isn’t another way around it. Or is there?
Developers have been pairing since the beginning of time. Two heads know more than one and so even though only 10 fingers are typing on the keyboard instead of 20, many times the code that is created this way is made faster and has better overall quality than if both devs wrote their own stuff.
But why are we limiting this practice only to developers then?
I have another confession to make - I fell in love with the whole pairing thing. Any time I can, I will pair with a developer. If I have an idea of what kind of checks I want to write, cooperating with devs makes me feel like magic exists. I have an idea of what needs to be written, but by the time I would have stumbled into my first obstacle and started to look for a solution online, the whole code is already written. You blink and it is there - as if it appeared out of thin air.
But it can work the other way as well. Dev finishes their work and needs to get it tested. In my book, they should be checking anyway that whatever they wrote is working. (I don't believe testers should fill the role of quality gatekeeper, but that is out of scope of this article and I will write about that some other day) So they call me in. I let them share their screen and I let them speak about what they wrote, what it is supposed to achieve and how it works. Even at this point, we are already pinging ideas back and forth and I am subtly driving the ideas in such a way that they form a solid testable hypothesis that will help to prove if their code works. We play around with the feature and I sometimes intervene to double check on interesting cases as they are happening (you know, exploratory testing, right? :)) In the end, I am sure the feature was tested to my standards, it took me half the time I would need if I did not pair with the dev, as they help me understand much faster what is going on. And the best part is that with some luck I am rooting some good habits and transferring some testing specific tacit knowledge that will help the dev to test their own code more easily in the future. I call that win-win.
So let the people on your team pair often. Stop insisting that everyone should be able to do everything. Not only that, nudge people towards paired work. Every one of us is good at different things, so simply let us use our strengths together and the outcome will be way better than anything we can achieve alone.
Comments