When I work on any project, I have a phrase in my mind that I confirmed in time "Learn to reinvent the wheel, but don't reinvent it". If I know how everything works under the hood, skip over spending time on this. If I don't know how to use it / make it, I'm going to make it for the first time from scratch. After this, if I have an opportunity to get over it, I'll use it.
"Reinvent the wheel" is a funny phrase when you consider just how many times we literally have had to reinvent the wheel (compare and contrast: stone wheel, bike wheel, car wheel, ATV wheel, airplane landing gear wheel....). We absolutely need to know how to reinvent the wheel, otherwise we'd all be rolling around Flintstones style still.
That said, we should only be reinventing the wheel if (a) existing wheels don't meet our current needs, and/or (b) we have a specific original improvement in mind that will make the wheel better in a given use case. That, of course, means we have to know a lot about the wheels that exist. Ergo, your reason for reading source.
Best to consider refactoring before considering rewriting/reinventing, IME.
Depends entirely on the code base. Rewriting is usually much quicker than refactoring someone else's spaghetti.
I'm advocating considering refactoring first, not saying it is always the answer.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.