5 ms·
I’ve had incredible experiences pairing. There were whiteboards, snacks, rating each other’s themes, and jokes. What worked very well was to pair for concepti
by gherkinnn 5y ago
I’ve had incredible experiences pairing.
There were whiteboards, snacks, rating each other’s themes, and jokes.
What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code.
We’d then break away and work at our own speed and in our own style using the common foundation.
Come together to integrate and discuss.
Pairing is also worth it’s weight in gold for debugging. It’s like a rubber duck, but doesn’t feel wrong.
It is of course of utmost importance that both parties enjoy it. Else it’s pain and a waste of everybody’s time. I had a colleague who hated it like the plague. In which case short code/review cycles worked best.
A good tool, if employed correctly. Like most things, really. And fuck management if they force it down on me.
- cableshaft 5y agoI like pairing for debugging a problem or discussing a design solution. You get stuck, bring someone in and discuss it, let them look at the code, point something out that sets your brain on the right track, or a solution pops in your head from something random they said or from the process of you explaining thing. Many, many issues have been solved that way. But I hate it in all other circumstances, especially when it comes to actual coding.
- stjohnswarts 5y agoThis works and I think is the natural way of things for human beings to bounce things off one another but for it to be a constant; no way!
- thomascgalvin 5y agoPairing is also, bar none, the best way I've seen to onboard a new hire. There is no better way to learn a codebase than to work closely with someone who knows that codebase, on a real-world, production problem.
- JohnBooty 5y agoYeah. I almost want to say it's the only realistic way to onboard. Depending on the codebase, I feel it's literally 10-50x more productive.
- jdbernard 5y agoI know for a painful fact that "here's our documentation, here's our bug backlog, have fun," is also realistic. For comparison, the productivity multiplier is something like 0.01x against the baseline...
- JohnBooty 5y agoOh yeah. I've been there multiple times. I meant the only realistically productive way.
- newtwilly 5y agoI actually felt like I learned a lot this way, although I had access to a highly competent person who knew nearly everything about the code base, and I would discuss with him like 4-5 times a day sometimes. It felt like close collaboration, but I feel like if I would've been sitting with him I would have wasted a lot of his time and would have felt pressured to try to learn things faster than was reasonable. But I never tried it, so I don't know.
- 5y ago
- stjohnswarts 5y agoI assume you are an extroverted person? Talking that much with another human being outside of someone I care dearly about just does not work for me, it just makes me anxious af. I'm glad it works for you and may you always another fellow extrovert to work. I left a job because they demanded pair programming as the new company paradigm. And yeah I gave it a shot for 3 months, and the other person was about as easy as anyone I could imagine anyone to be, but honestly I got tired of staring at his stupid face (although he was actually quite smart and capable, I just didn't want to see/communicate with him 8-10 hours a day)
- gherkinnn 5y agoNot at all. Excessive pairing makes me tired. And I, as many, loose my ability to type when someone is watching. All in all, the actual pairing can be limited to 1h every few days. Done well it’s enough. Demanding a work mode is stupid. Be it forced TDD, forced pairing, or forced welding when all you need is some glue.