Your Pace, Or Mine?

Matching pace of work is the toughest problem to be dealt with when working with a new teammate. In the last two days, I produced awesome output, but failed to match pace with my pair programming partners.

Bootcamp Day6

Paired up with a new teammate, Akshay. He is an experienced man, and not a fresh grad like most of us. He has worked with this firm for about a year, and most importantly, he has been using MacOS for about a year. Yeah, this matters, because I come from a background of Dell Inspiron laptop setup with Ubuntu 16.04 OS, which makes me novice to the various keyboard and touchpad shortcuts provided by MacOS. For every action I need to perform, I either look up to the cheatsheet, or follow the cursor menus, which of course slows me down. But, on the other hand, my superman partner could switch worlds within seconds, flash his super swift fingers over the keys and write hell of a code, save it, run it, and commit it before I could blink my eyes.

It was incredibly astounding to see him do this, but equally awful to give up on my pace and trying to match his.We inadvertently divided roles, I was to think over the code and the design and the names of specs and methods, while he was to type, test, run, save and commit it. I did a lot of thinking but could not type a single line of code.

Yeah, we completed whole of the exercise within this single day, but it pained a bit to not have typed a single method therein. We raced to the top, but I felt skeptical to owe a contribution in it, and probably this was the reason I was not ready to present it.

The following night, my fingers itched to code, and thus I was awake till late to redo whole of the project locally on my machine, and also the home work in ruby. Finally, it felt good, and complete. But probably this lined up another debacle for the next day.

Bootcamp Day7

I paired up with Koushik. Owing to the miraculous partner the day before, I was done with the project, but Koushik was yet to do things. I was the accelerated person this time. It felt so easy, and assertive to not let him think, and speak over all the specs and methods he was yet to think over.

The essence of pair programming died again in my watch today, and unquestionably, I was the one to be blamed for it this time. I kept giving him solutions to all the levels of the problem statement. Since no more thinking and discussion was left to be done, he chose to complete his java program, while simultaneously, instead of wasting time by watching him do so, I chose to work over the ruby part of the implementation. Whatever doubts he had, we discussed, referred my last day’s code, and solved them out within seconds.

Another day ended, and we both were finished with our respective codes. He completed the java version, while I was done with the ruby implementation. But none of us knew each other’s work precisely. There was no team. It was basically two individuals working besides each other. And it was my fault.

I can still feel the guilt. But the lesson learnt is perpetually precious. In a team, work like a team. Match the pace of every member. It is easy for fast ones to slow down, but too tough for the slow ones to raise their bar. Find a solution somewhere in the middle. But just don’t ever take over. Let everyone owe a contribution in the final output. It feels terrible either way, to accelerate or to be taken over. Work like a team.