In large codebases with new developers it can take a while before people feel comfortable working on projects or tasks by themselves. Getting developers to this stage can take lots of time, but it's worth the effort when many developers can work in parallel. Here are some of the reasons why junior devs may be uncomfortable jumping into the deep end or asking for help soon enough, and ways that you may be able to mitigate these problems and have a more productive happy team.
Similar to writer's block, is coder's block. You know what you need to get done but you can't figure out the right way to get started. This is especially true for junior devs who may not understand the conventions or established patterns of your project very well yet.
Describe the problem together and write up an outline of all the parts that need to change, even going so far as to pseudo code in functions in the real code and let the junior flesh out the details. Make sure to have a good linter that allows the junior dev to get feedback on style automatically. Encourage them to start with TDD to get a smaller feedback loop to start with.
This one is similar to Coder's Block, but has a different cause. Sometimes junior devs will take more with a task than they can actually deal with. This can manifest as going days and days with little to no progress made on the task. It causes stress for the whole team because it can seem as if things should be getting done but they aren't, and the junior dev might be afraid to ask for help on the whole item.
If you can, try and split the task up into smaller sub-pieces and go through the pieces with them to make sure they understand what each of them means and if they have a clear path forward on the task. Regular check-ins on the progress of the item as a team are helpful to ensure that a person isn't stuck and will allow them to describe what help they may need to move forward.
High confidence and a lack of experience can cause excited new developers down a some weird paths to solutions that you might not have expected them to go down. Some of these paths will be fine, a few will be great, and others will be... not so great.
Spend time pair programming, and pair code reviewing. It's great to get insight about what the person was thinking, and why they made the choices they did. This will help not only their code, but will also surface ways that you can make the code easier to understand in the future.
Hopefully with these few tips you can help your new devs be happy and productive quickly.