When trying to understand a bug, taking up a new framework, or anything with learning: don't read too fast. Read slowly and make sure you understand it. Read the stack trace. If you're 100% sure the documentation is lacking, read the source code, search through the issues, and ping the maintainer. Make a pull request while you're at it. It's okay to spend 1 day debugging by learning the foundations of a framework, rather than 1 day copy-pasting every StackOverflow answer you come across. That approach wastes your time without learning properly in the process.
6-10 years ago we didn't have all these frameworks and libraries. Junior devs are now faced with a mountain of these things that they can easily copy-paste without understanding what's underneath the hood. Make sure they keep the hacker ethos and try to open up those boxes from time to time, so that they'll understand the foundations of certain pieces of software.
It's definitely worth the time to point out edge cases, bugs, and documentation issues. 1 hour of your time to file a good issue might save you 10 hours in a month when the project maintainers resolve it, and everyone else in the community benefits from it.
It also gives you a chance to take your mind off the day to day grind, and perhaps do things the right way (like including stack traces and example code usage in the bug report). I find the process of contributing to open source projects very fulfilling, and it really brings out the craftsmanship in my work which is sometimes suppressed in the day-to-day.
Comments
When trying to understand a bug, taking up a new framework, or anything with learning: don't read too fast. Read slowly and make sure you understand it. Read the stack trace. If you're 100% sure the documentation is lacking, read the source code, search through the issues, and ping the maintainer. Make a pull request while you're at it. It's okay to spend 1 day debugging by learning the foundations of a framework, rather than 1 day copy-pasting every StackOverflow answer you come across. That approach wastes your time without learning properly in the process.
6-10 years ago we didn't have all these frameworks and libraries. Junior devs are now faced with a mountain of these things that they can easily copy-paste without understanding what's underneath the hood. Make sure they keep the hacker ethos and try to open up those boxes from time to time, so that they'll understand the foundations of certain pieces of software.
Seconded!
It's definitely worth the time to point out edge cases, bugs, and documentation issues. 1 hour of your time to file a good issue might save you 10 hours in a month when the project maintainers resolve it, and everyone else in the community benefits from it.
It also gives you a chance to take your mind off the day to day grind, and perhaps do things the right way (like including stack traces and example code usage in the bug report). I find the process of contributing to open source projects very fulfilling, and it really brings out the craftsmanship in my work which is sometimes suppressed in the day-to-day.