Pairing and TDD changed how I work
The team I joined practices Extreme Programming, or XP. In practice, for me, that has mostly meant two things: pair programming and test-driven development. I had done neither in any serious way before. A few months in, both have changed how I work, and I have feelings about it.
Pairing, the hard parts first
I will start with the honest part. Pairing was exhausting at the beginning.
You sit with another person and write code together, one keyboard, two brains. There is no zoning out. There is no quietly googling something for ten minutes while you figure out what you are doing. You have to think out loud, constantly, and that is tiring when you are not used to it.
It also felt slow. Two people, one task, surely that is half the speed? That was my math at first.
And you cannot hide. If I do not understand something, my pair knows immediately, because I have to explain my reasoning as I go and it falls apart out loud. As the newer person on the team, that was uncomfortable. I wanted to look like I knew things.
Why I came around
A few things changed my mind.
It caught bugs early. Not in code review days later, but in the moment, before the bad idea even got typed. My pair would say “wait, what about an empty list?” and we would handle it right then.
It spread knowledge fast. I learned the codebase, the tools, the team’s habits, much faster than I would have alone. And it goes both ways, so I was not just taking.
And explaining my thinking out loud made me a clearer thinker. When you have to say why you are doing something, you notice when the why is weak. A lot of my bad ideas died the moment I tried to say them to another person.
It is still tiring. I just think the tiredness buys something now.
TDD
Test-driven development was the other shift. The loop is red, green, refactor: write a failing test, write the smallest code to make it pass, then clean it up.
Writing the test first felt backwards. How do I test something that does not exist yet? But that is sort of the point. Writing the test makes you decide what the thing should do before you build it. The test becomes a design tool, not just a check at the end.
The part I did not expect to value so much is the confidence to refactor. With a wall of tests behind me, I can rip apart a piece of code and rearrange it, and if I break something the tests tell me right away. Before, I was scared to touch working code. Now I am much less scared.
Mixed feelings, still
I do not want to make this sound like I converted and now I love everything. Pairing all day still drains me. Sometimes I miss working alone with my own thoughts. And TDD slows the start of a task, even if it speeds up the end.
But I write better code now, and I understand it better, and I trust it more. So I am not arguing with the method anymore. I am just learning to do it with less resistance.