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.

👁️🍾👍🦟

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.

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

👁️🍾👍🦟

What The Business Does To Earn Money

During the Dotcom bubble, the most likely answer would have been "looking for new investors while we desperately try to find someone who wants to buy us outright". SCNR

When a new developer is hired, you want to give them the best possible opportunity to become productive as soon as possible.

I agree. Within reason, there aren't "too many questions", as long as you can see that the new hire listens to your answers and tells you when they don't understand it. And the person does at least some research on their own into some of the basics.

Unfortunately, i've had too many candidates lately who always pretended to understand what i had said, giving me no feedback at all what (and if) they had learned so far.

Plus, it would be nice for a change for candidates actually having the skills they pretended to have on their CV. My last "junior developer" candidate with "basic experience in multiple programming languages", during a basic "let's test your skills" thing during the one week evaluation period didn't even come as far as reading in the text file. (Exercise: "Read in this CSV file. First column is a filename, second column is some text data. For each line, generate a QR code image (PNG format) with a library of your choice. Data is the second column. Write file to the filename given in the first column.").

In that last case, the candidate also asked too many questions, yes. "Too many", because those were questions that person should have already had the knowledge to answer them. When you want to get hired as a Perl developer for software running on Linux, questions like "How do i copy a file on the command line?" or "What is 'source code/version management'?" shouldn't pop up. It should have been basic knowledge before filling out the job application...

But, as long as the questions are on the appropriate knowledge level and the new developer can show that they actually listen to and learn from your answers, the problem of "too many questions" doesn't exist. The old carpenters motto could be shoehorned here: "Ask twice, code once".

Interviewing developers can be a tricky proposition. When I interviewed for a recent position, I was able to skip past any kind of developer test because of my specific background (leader of the local Perl Mongers group); I was delighted, because I do my worst work while someone watches every key stroke. A particularly abysmal screen-sharing session with GSG (long ago) comes to mind. Wow. So bad.

However, giving a developer an hour or two to write something simple should be enough to find out what level they're at during an interview. Getting them to debug an issue in some poorly written code would also be useful. For example. if the code's poorly written, do they use perltidy to clean it up a little? Do they use the debugger? When starting a new script, do they start with a comment about what they're attempting to do? Are the variable names sane?

Alex / talexb / Toronto

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

Most (if not all) generic onboarding methodologies are recipes for failure. Why do you hire a new person? Because a) the people you already have are insufficient b) they are sufficient but you are constrained by time/space in some way such that they cannot meet demand c) you do not have any people who do X (some technical skill). All three of these are important but they are, in fact, secondary to the current and reasonably identifiable future states of the entity.

Most canned technical onboarding systems are misaligned with organizational strengths/weaknesses and the overall technological roadmap that, to be effective, should be at least influenced by the company's industry. So if you work at an auto parts recycling business and your competitors are not investing in technology but instead in storage capacity for instance a heavy investment in technology at this time is likely the incorrect decision. You want to lower maintenance costs and focus on system stability/so-called future-proofing instead of new development. Hence, you hire someone well versed in doing just that with your existing systems.

The problem with onboarding is that it relies too heavily on technological people who do not spend enough time talking to other parts of the business to assess what is really needed today AND tomorrow. They like Java so they hire Java developers because they make them feel 'comfortable' without asking what phase their business and its industry is in -- growth, stability, or decline. High growth businesses need systems fast and your environment should be able to reduce critical errors while absorbing/minimizing the impact of minor ones. You'll need agile developers with modern programming skills and short memories. Here the emphasis is on speed -- you want to gain the foothold on whatever market you are moving into. This is a different focus than a large, established/stable market. If you hire the aforementioned developers in this case they will become dissatisfied and will try to push for new development when it is not the the business' best interests. In a declining market you need to focus on survival -- elimination of the highest costing lowest benefit producing systems for lower cost alternatives. Cut, cut, cut to the nub. People with heavy emotional ties to doing things in a certain way will find themselves on the out in this case.

So you see, hiring and onboarding must take a back seat to where the business is and where it is going. Once you have clarity in this regard how much/little you need to do things like onboarding become rudimentary.