in reply to What is the right amount of onboarding?

What is the right amount of onboarding?

I feel this depends on the size of the company, the nature of their business, and the experience of the new hire.

In one large company I worked for, with a graduate recruiting program, the newly hired graduate spent a week or two in second-level and third-level support before starting in a dev team. I felt that worked well because it allowed the new hire to focus just on learning the product from the user point of view, without having to worry about the code, and with the added benefit of seeing common customer issues first-hand.

Fully understanding the product then allowed them to focus on the code when they finally joined a dev team. Another (unexpected) benefit was they were often able to use the personal contacts they had formed in support to assist their new dev team. :)

If you have a code-base of thousands of files and no documentation, are you surprised there are questions?

No, I'm just surprised. :) Interested to learn the history of that one! I would say that is a serious failure of management.

I feel that to be sustainable in the long term software should be developed in teams, not by lone wolf developers. And asking questions within the team should be encouraged, especially from new hires. Pair programming can also work well to bring new hires up to speed fast. 

👁️🍾👍🦟
  • Comment on Re: What is the right amount of onboarding?

Replies are listed 'Best First'.
Re^2: What is the right amount of onboarding?
by talexb (Chancellor) on Dec 20, 2023 at 15:32 UTC
      In one large company I worked for, with a graduate recruiting program, the newly hired graduate spent a week or two in second-level and third-level support before starting in a dev team.

    This is an excellent practice, because it gives the newbie exposure to what the customer is trying to do with the organization's service/product, and shows where people are having problems. That experience puts them in the right headspace to look at the code behind the current system.

      ".. thousands of files and no documentation" .. Interested to learn the history of that one!

    I'm not really sure about the history .. this was code that had been in place for some time. It was what I thought of at the time as a Super Application because it did so much stuff. Unfortunately, most of the POD was still the original boilerplate, and I can remember the test script for one of the modules was

      use_ok ( ModuleName );
ok ( 1 );

done_testing;

      [download]

    I think it was 2-3K lines of code.

      Pair programming can also work well to bring new hires up to speed fast.

    Sure, I'm a fan of that for getting people started. I got a little pair programming at a recent job -- I watched, while this ace developer zoomed through a solution at blistering speed, both in his typing and his speech. I got most of it, but I certainly would have benefited from a slower presentation, just because it was like trying to drink from a firehose.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

[reply]
[d/l]

      I got a little pair programming at a recent job -- I watched, while this ace developer zoomed through a solution at blistering speed, both in his typing and his speech. I got most of it, but I certainly would have benefited from a slower presentation, just because it was like trying to drink from a firehose

      Ha ha, I've also had a few of those drink from a firehose experiences. When new developers were introduced into my teams, we had an informal pair programming rule that for the first week or so the newbie developer should mostly be the driver, with the experienced pro relegated to a back-seat driver role. While I felt that brought the team newbie up to speed faster, you could sometimes see some amusing body language from the top-gun developer in the back-seat driver role, obviously itching to take over the reins. :) 

      👁️🍾👍🦟
[reply]

In Section Meditations