A Story of Pair Programming 💻💻
Sep 17, 2021 7:01 pm
Hi there,
I was thinking this morning back to things I attribute to excellence in my career, and I found myself remembering a story about when I was pair-programming at a company that I thought I'd share.
The team I was with was regarded as the maintenance team and didn't have very much prestige. In fact, they were located away from the other groups, in a dark corner, near the drafty back-doors. There were other places they could be.
They mostly worked on secondary projects or maintained others, and for the most part were not factored into large plans or the like. Me being strangely competitive at work, I set to turn them into the best team in the company.
At some point, this included pair programming.
There I was pairing with someone and they did something that left me speechless. We were building some feature or other, and we realized we needed to create a new class. So where most folks would tell their editor to create a new file, he copied the one and then began to edit it into the final thing he wanted.
I watched him work and afterward showed him how I did things and he was speechless that I did things the way I did when I created a new file.
We got to talking about what we liked about our approaches, and there was something really interesting in that discussion.
You see, in almost every coding effort there's a certain amount of broiler plate, framework, or setup code required before you get into the task at hand. You can go years without really understanding what any of it does, because you just need to get it in there for things to work. This is more common than you'd think.
His approach to copy a file left him with a very different impression of what that broiler plate was used for and not, since he was fundamentally deleting things that weren't needed. My approach convinced me of a different meaning to the broilerplate since I was always adding it in.
Only by pairing did we expose each other to our approaches and their strengths. While there were more fruitful pairing experiences over the years, this one moment always stayed with me.
Remembering it helps me continually remember that in most teams of developers, nobody has any idea why their teammates do what they do because they work alone. Their strengths are invisible, and the merits of their methods are obfuscated. Pairing is what allowed us to share these strengths and merits.
If you've paired with someone I'd love to hear a perspective you got from that experience by seeing how someone else approaches a problem.
Here's my weekly update for September 17th, 2021...
🗒️ When Abandoning Code Reviews Leads to Better Results
The first time I was on a team that abandoned pull-requests and code reviews was back in 2011.I would keep pushing the groups I was in to do the same because the results were much better than the branch-based code reviews....
🗒️ Working in Public: Experiment in Failed Marketing
Tomorrow I’ll formally close on an experiment that I’m willing to call a failure a bit early.
Why share all of this?
Trying, looking at the results honestly, and moving on is a crucial aspect of building any product.
There are a lot of things to think about when choosing metrics, and most groups tend to get paralyzed debating measures and ultimately measure nothing.
Enjoy,
Ryan Latta