121–130 of 180 posts
I rewrote the firmware of a product with a college in two weeks that had taken years to do.
I think the project would have failed without it.
But it’s very tiring, you get rapidly exhausted at that level of concentration, there is a need to take breaks and to recharge by doing simpler task alone between sprints.
But if the problem "clicked" already and I know what I need to do and where I need to go, it's just a waste of another person's time, and my own when I suddenly start making unusual mistakes because someone is looking over my shoulder.
An experienced blacksmith can hammer out a fine knife in his sleep, but sometimes you're making armor for the King.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
> Pair programming can pick up mistakes before they propagate, which increases velocity.
Notice how it's "reduce bugs" twice with some other hand-waving qualities thrown in. Even if you have some solo developer write code with a bug, having another developer go through and fix it is a time saver over PP for all the code that was not error prone. Then we have the metric mixing issue of measuring developer code quality, over time, when mixing more than 1 person in a task.
> And this is better, because...?
Because you can avoid paying for idle time. The most common quality of pair programming team (considered productive or not) is watching one member waiting to see the other write out the function and functionality that was already agreed upon. Developers already do this when they have a tough problem. They invite others to talk and look through the code, ad hoc.
Pair programming has already been tried by a multitude of teams across decades and it does not produce results that have driven it's widespread adoption. End of story.
Earlier quoted context omitted.
Just to tag along (I was going to quote and write just about all the same things), but with two developers, the HUGE value-add is codebase knowledge. If two people on a team regularly contribute to a repo, one person likes to work on feature A, and the other feature B, and all of a sudden, the feature B person leaves and never comes back, that will kill velocity. Even if feature A person has been doing code reviews,…
I'll tag along as well. (But I happen to think pair programming is a beautiful thing.) Code reviews in real time, in situ. "White board discussions" in real time, in situ. Learning how someone else codes/debugs. These are all worth the price of pairing up engineers in my mind. If we're talking agile development, I would love it if all engineers could get paired up for at least one sprint a year. Especially less exper…
That's kind of subjective and I don't think I could prove its usefulness on graph paper to someone who isn't convinced, but I think it's real and significant. (and hence I'm curious if people who have mobbed a lot agree)
I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls devel…
Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.
Even so, I will still not do it 8 hours a day. Probably 6, to give you time to do other stuff, like investigations, admin, ...
Earlier quoted context omitted.
Yeah it would be weird to me if programming is some unique task where two people solving a complex problem together is a bad thing. I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about i…
What's weird and unique about work that one person can do better than two? Novel writing is complex, chess is complex, art is complex. Individuals do these things all the time.
When it comes to novels and art though, there's a focus on producing one persons imagined work, edited and helped by others. When it comes to programming, particularly in a company, there's a problem to solve.
Is it common in other fields of engineering to say that only one engineer can work on a problem at once?
> Individuals do these things all the time.
Individuals code alone all the time too. What I'm commenting on is the idea that programming together with someone is terrible.
The best pair programming was when I arrived on a new project and I paired on a big subproject with someone with domain experience. He could have done it way faster and I coul’ve worked on something easier. But in the end, I gained a lot of domain knowledge extremely fast, faster than any documentation would have allowed me to.
That’s what pair programming is about.
Earlier quoted context omitted.
What's weird and unique about work that one person can do better than two? Novel writing is complex, chess is complex, art is complex. Individuals do these things all the time.
Chess seems like an odd addition there, would two people who are able to discuss strategy and reason about the next move be worse than one? For writing, workshopping jokes or scenes happens a lot doesn't it? Particularly with scripts. When it comes to novels and art though, there's a focus on producing one persons imagined work, edited and helped by others. When it comes to programming, particularly in a company, the…
I think it's like having a navigator in a rally car. Your pairing partner is both giving you timely input as you drive and looking ahead for upcoming issues. Also they literally or virtually sit beside you, not behind.
If you are pairing for 2x output, you are doing it wrong. I think we SHOULD discuss if it's the best way to improve design, quality and share understanding and skill, but we can't do that from the position the author has staked out.