You learn so much by looking at how mature succesful software looks under the hood, which you will have to do as a condition for writing a good PR.
But, sure, don't send PR's for things that don't matter just to send PR's, that's just annoying.
But if you send a 3-line PR to fix a bug, that required 15 hours of study of the code to diagnose and figure out the right 3-lines, that is HUGELY educational.
Working on immature or even poorly written software can be super educational too, nothing wrong with that too.
But if you only ever look at hacky not-yet-mature not-yet-proven software, how would you ever learn to write high-quality software, or even know the difference? You have to study known good code. The way programmers study something with a natural goal instead of just artificially, is in the course of trying to alter it "correctly", the study you must do to figure that out.
(I know some programmers who have literally never worked on anything but over-engineered architecture-switched-every-month-for-years barely-holding-together technical debt bankrupt software... and I think sometimes some of them literally don't know anything else is possible! Looking at mature respected code is crucial, if you don't even know what it looks like how could you possibly try to get there?)
One of my best contributions was a 1 line fix in one of Microsoft's repos. It took me a day or two to understand the code and what it was doing but it was well worth it.
But, sure, don't send PR's for things that don't matter just to send PR's, that's just annoying.
But if you send a 3-line PR to fix a bug, that required 15 hours of study of the code to diagnose and figure out the right 3-lines, that is HUGELY educational.
Working on immature or even poorly written software can be super educational too, nothing wrong with that too.
But if you only ever look at hacky not-yet-mature not-yet-proven software, how would you ever learn to write high-quality software, or even know the difference? You have to study known good code. The way programmers study something with a natural goal instead of just artificially, is in the course of trying to alter it "correctly", the study you must do to figure that out.
(I know some programmers who have literally never worked on anything but over-engineered architecture-switched-every-month-for-years barely-holding-together technical debt bankrupt software... and I think sometimes some of them literally don't know anything else is possible! Looking at mature respected code is crucial, if you don't even know what it looks like how could you possibly try to get there?)