Problem with programming - a solution always looks easier when it is already done. Even when a programmer solves a problem, he/she looks at the problem and the solution and thinks: "I have no idea why it took me whole day, it should've taken maybe an hour.". Also, sometimes it's dangerous to leave a programmer alone with the problem - you don't know what they are doing until it's too late.

That is why even the best soloists should try pair/mob programming from time to time. And it is essential to increase visibility in the teams where people work solo/distributed teams. It's okay to shout out in a public chat, group email, etc. of what you're doing, what approach you're going to try, things that unclear to you, what's left, how you'd like to improve it, etc. Don't be afraid to look stupid. It's better than trying to come up with excuses later. Post diagrams drawn on the napkin. Ask your teammates what would they think if you add a library, or remove one. Delayed feature for unknown and speculative reasons never looks good, delayed feature backed-up with your publicly shared notes is always better. Better for you, better for the team.

The best teams operate that way and if a manager cannot create a culture of complete transparency, they'd loose the ability to trust their peers.