6 ms·

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 pre

by lkois 5y ago

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 developing some remaining features on his plate. It was an extremely effective knowledge transfer process. I learned plenty about this bizarre program and it's nonsensical logic, able to figure out future problems, and ended up as one of the main bits of glue keeping it all from collapsing. I also found it very rewarding to work that closely with a more senior developer, got a bunch of more general advice, had some interesting tangential discussions, and made a friend. Also got plenty of advice to leave the shitty company and it's terrible software asap. I dunno if I'd want pair programming day to day, but it was a great experience at the time, and made my entry to the role much smoother than anyone elses. 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.

rr808 5y ago
Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.
- MattGaiser 5y ago
  Yep. If I have more than 2 hours of meetings in a day, I basically lose the entire day.
- ehnto 5y ago
  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.
- MiyamotoAkira 5y ago
  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, ...
- usefulcat 5y ago
  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.
  - rr808 5y ago
    > 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.
    - calsy 5y ago
      That’s what happens when someone looks over your shoulder.
    - kentrado 5y ago
      That's a good thing for the company. It's a horrible thing for the employee.
- lkois 5y ago
  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.
ehnto 5y ago
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.
ramesh31 5y ago
>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.
- lkois 5y ago
  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.
cudgy 5y ago
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.
- lkois 5y ago
  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.

by lkois 5y ago

rr808 5y ago

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

MattGaiser 5y ago
Yep. If I have more than 2 hours of meetings in a day, I basically lose the entire day.
ehnto 5y ago
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.
MiyamotoAkira 5y ago
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, ...
usefulcat 5y ago
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.
- rr808 5y ago
  > 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.
  - calsy 5y ago
    That’s what happens when someone looks over your shoulder.
  - kentrado 5y ago
    That's a good thing for the company. It's a horrible thing for the employee.
lkois 5y ago
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.

ehnto 5y ago

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.

ramesh31 5y ago

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

lkois 5y ago
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.

cudgy 5y ago

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.

lkois 5y ago
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.