3 ms·
Absolutely, understanding the source of libraries that we're using is great, but the reason most folks might elect to use a framework is "to save time". And re
by trey-jones 6y ago
Absolutely, understanding the source of libraries that we're using is great, but the reason most folks might elect to use a framework is "to save time". And reading (and understanding) code takes time. For probably my first 5 years in this industry I found reading code in other peoples' libraries extremely tedious. Don't get me wrong - I think reading code from a better programmer is one of the best ways to get better. But I found it very difficult at first.
You can even see it in a lot of the comments on this topic. Things like: "I like rolling my own code so I don't have to learn someone else's API." I think that's typical of a less experienced dev that already feels overwhelmed by all the other technologies that they have to learn. Dunning-Kruger and all that.
Better tools, and some practice and experience have made it easier, but when I ask a less experienced dev to read someone else's code I do try to keep in mind how it was for me early on.
- jt2190 6y ago> [T]he reason most folks might elect to use a framework is "to save time". Cool! So now we’re expressing something we value, and we can evaluate third party code and our own against that value. > Understanding the source of libraries we’re using is great... Again, we may value that, we may not. “Treat it like it’s yours to understand and maintain” does not mean eagerly read all of the source. It means that you should act like you’re also responsible for the code’s maintenance, whatever that is and to the best of your abilities. Because it is a part of your app when you use it.