[facorreia]

Many times I've relied on new hires, and even specifically asked them to, for improving the documentation and/or onboarding guides. Once someone has been in the team for a few months, they'll picked up "tribal knowledge" and they'll mentally fill in the blanks in any documentation (or obscure code). Those few initial weeks of someone with fresh eyes are precious for that.

[relkor]

This is absolutely the way to go. Another great feature of getting a new hire on your time is that the goals of your team were already allocated with the old bucket of developer hours. Because the new hire was not planned for, they are relatively free to work on any of the nice to have but not critical parts of the codebase.

We always have new developers start by writing unit tests and documentation for the most used components of our codebase as determined by profiling. This way we are always improving our most important code, and at the same time teaching the largest percentage of our code to the new dev at the same time. With core components that are used everywhere, the new dev can literally ask anyone else on the team for help. This can help the new dev by allowing him/her to spread out what he/she thinks are dumb questions without feeling as embarrassed. Then by the time the next planning session has accounted for the larger bucket of dev capability, we have some great bugfixes, and the new dev is more confident and ready to specialize more.