You are not getting best practices....Looking at someones code you will get the good stuff mixed with the half drunk, or just a bad day.
Best practices are good, but reading code is its own education. Reading forces you to think and care about how the code communicates its own organization and intent. In turn, this spurs you to really think about what your own code means instead of just what it does. While books and articles on best practices can teach you a lot about code formatting, language-specific idioms, platform-specific techniques, design patterns, packaging/delivery, etc, they usually do so separately: you have to look at actual working code to see how all of these techniques work at once.
In my opinion, struggling to understand real code (with plenty of successes and failures--the failures are important too) steps you closer to learning the gestalt of style... you gain skills that help you critically evaluated someone's "best practice" and determine where it is and is not efficacious to use it.
But then you'll face grandparent's point:
3. You do not have a goal. You can't just look at a program and say I know how it works... You really need a goal to fix something, otherwise you are looking at stuff blindly.
It just doesn't make sense to just look and try to understand some code unless you have an angle to it. How do I add feature X? How do I fix bug Y? How do I refactor this to fewer lines of code? Etc. Scratching your own itches is possibly the best way to go. It gives you motivation, goals, and satisfaction.