[cjcenizal]

You're doing great! Many of the commenters here are saying this is normal and you shouldn't be worried. They're right. Relax. You're asking questions and learning... don't worry about not learning fast enough. No matter how quickly you learn, it will never be "fast enough"!

Here's some advice which may help. Focus on smaller problems. If you need to solve a problem with an internal tool with poor docs, tell yourself you're not going to solve the problem right now. Right now, you're just going to improve the docs. So dive into the tool and focus on one method at a time. Read the source, the tests (if they exist), and update the docs with the knowledge you gain. Stay focused on each individual aspect of the tool until you're an expert on it before moving on.

This way you'll be in a position of ever-expanding authority, you'll inevitably arrive in a position where you can solve the original problem easily using the internal tool, and you'll have created some docs which will be useful to other people on the team!

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