Hacker News Reader

Transferring arcane project knowledge is the best use case of pair programming I think. That and bugsquashing a complex codebase. I could never imagine developing features with pair programming, but the prior two situations really do benefit from a bit of a mind melding.

They figured it out on their own in a month or two. You figured it out with 2 other developers in a few weeks. Meanwhile, those developers did not make progress on their tasks. This seems to only be an advantage for you as the newcomer to get ramped up quicker.

Another potential disadvantage is that you may have been influenced by their methods and not having looked at the code independently, your own insight and input may have be limited.

It was just me and the more experienced guy, and we finished what he was working on. The other guy was busy with other things, and never had a similar induction of his own. When I started to work with him after those 2 weeks, it was very apparent that I had caught up, and likely surpassed his ability with the system.

And given the highly unintuitive nature of that system and the rushed training, there was plenty of room left for insight and input without requiring the same initial period of confusion and frustration that caused him and the other devs to have such a negative and lasting view of the system.

And more generally, I'm not sure why you feel the need to poke holes and find potential negatives in what was a positive training experience. Especially when what you've said could apply to any kind of training, and disregards the situation as described.

Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.

Yeah I could never be on a video call for that long. There is a subprocess in my brain that starts running at 95% when I'm on a video call, like a kind of performance anxiety. I can deal with longer voice calls, but I can't really work during a call so it's only useful for syncing up. A call longer than an hour has probably become inefficient in some dimension.

Pair programming is quite intensive when done correctly. You build stamina with time. But even so, using the Pomodoro technique is the way forward. Someone driving for 20/25 minutes, then 5/10 rest, and switch the driver.

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, ...

At one time in my career I pair programmed pretty much all day, every day for the better part of four years, with the same person. We started with an existing codebase, but even from the start most of the work we did was on new features.

It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about various tools). Things that theoretically I could have learned on my own but in practice I probably never would have.

If I had it to do over again I would definitely choose to do it again.

> You basically can't/don't ever slack off.

I think this is the best part of PP, its a great way to avoid procrastination.

That's a good thing for the company. It's a horrible thing for the employee.

That’s what happens when someone looks over your shoulder.

Yep. If I have more than 2 hours of meetings in a day, I basically lose the entire day.

He was quite diligent about taking regular and appropriate breaks. Partly in response to having worked through too many lunches prior.

Brain sag still occurred though.

>The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.

Sounds like a real professional, you lucked out. The standard case is to just inherit that garbage and pray to god nothing breaks when you touch it.

Haha yea I did. Though he even acknowledged that if he wasn't quitting, I'd have had a grumpy coworker instead of any training.