3 ms·

Pairing 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

Pairing 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 ago
Yeah. 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 ago
  I 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 ago
    Oh yeah. I've been there multiple times. I meant the only realistically productive way.
    - jdbernard 5y ago
      Agreed. I'm just in one of the 0.01x situations now. Lampooning the situation helps me cope. :D
      - JohnBooty 5y ago
        Oh man. Best of luck. Nooooot fun.
  - newtwilly 5y ago
    I 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.
    - jdbernard 5y ago
      To be fair, in the cases I'm thinking of it's more just chucking a new guy into the mess without direction. I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.
    - JohnBooty 5y ago
      I feel like if I would've been sitting with him I would have wasted a lot of his time Yeah I think forcing devs to pair for no reason and simply hoping the magic happens... tends to waste time What you did is what makes sense to me. Be eager to pair and/or mentor "on demand" whenever it makes sense. Whenever I've written some weird/tricky code that doesn't explain itself, I make doubly sure to mentor the next coder(s) who work on it. I find it pays off handsomely. Off the top of my head, I would say that 1 hour of working together can easily replace 2-8 hours of another dev stumbling through things, trying to do code archaeology, and making mistakes that might have been avoided. Some folks would say "well, just document the code" or "write cleaner code" but sometimes that's simply not reality when racing deadlines, requirements are changed at the last minute, or you're working around bugs in external libraries or devices.
stjohnswarts 5y ago
The best way I found to onboard was what I called "half day onboarding". Half the day the mentor can help, the other half the new person has to be self sufficient. Otherwise people start using their mentor as a crutch. This is the way I brought on new people as team manager.

JohnBooty 5y ago

Yeah. 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 ago
I 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 ago
  Oh yeah. I've been there multiple times. I meant the only realistically productive way.
  - jdbernard 5y ago
    Agreed. I'm just in one of the 0.01x situations now. Lampooning the situation helps me cope. :D
    - JohnBooty 5y ago
      Oh man. Best of luck. Nooooot fun.
- newtwilly 5y ago
  I 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.
  - jdbernard 5y ago
    To be fair, in the cases I'm thinking of it's more just chucking a new guy into the mess without direction. I agree with you. When you do have decent documentation (more than just "here's how to npm install") and you've got a well curated backlog of defects this can be a good way to onboard new people and give them a starting point to tour the codebase.
  - JohnBooty 5y ago
    I feel like if I would've been sitting with him I would have wasted a lot of his time Yeah I think forcing devs to pair for no reason and simply hoping the magic happens... tends to waste time What you did is what makes sense to me. Be eager to pair and/or mentor "on demand" whenever it makes sense. Whenever I've written some weird/tricky code that doesn't explain itself, I make doubly sure to mentor the next coder(s) who work on it. I find it pays off handsomely. Off the top of my head, I would say that 1 hour of working together can easily replace 2-8 hours of another dev stumbling through things, trying to do code archaeology, and making mistakes that might have been avoided. Some folks would say "well, just document the code" or "write cleaner code" but sometimes that's simply not reality when racing deadlines, requirements are changed at the last minute, or you're working around bugs in external libraries or devices.

stjohnswarts 5y ago

The best way I found to onboard was what I called "half day onboarding". Half the day the mentor can help, the other half the new person has to be self sufficient. Otherwise people start using their mentor as a crutch. This is the way I brought on new people as team manager.