My take on "the less code you write the better" isn't "try to do in 5 lines what should take 50", but rather to avoid writing certain code in the first place. For example, avoiding writing a function that an external dependency can do well (of course that brings up the issue of understandability and size of your program, not to mention maintenance - did someone say "trade-offs"?). A better example, I think, is not writing certain features, or even entire programs in the first place. Why add a feature to, say, a source code-searching program like ack if you can write a small program that takes ack's output and gets you the result you want? Why write a program, however small, to process data if you can whip up a shell oneliner to do that processing for you? Anyway, that's just my 2¢!
Hey Rob, thanks for the considered response. I can definitely see your point of view about not reinventing the wheel and building things which already exist. I think you raise a good point that these stereotypical opinions can be interpreted differently from developer to developer. I would agree that working smart (using existing resources) is a great way to save time on a project.
To follow on from your point - I would be interested to hear about what your own personal criteria for deciding whether an external resource/dependancy is trustworthy enough to include in your project? Do you favour package downloads/online reviews/github issues solved?
I consider a number of criteria when evaluating a library:
Reverse dependencies - who's already using this project? Perl's MetaCPAN shows this information readily, but you need to take it with a grain of salt, since it only shows code on CPAN that uses the library in question. So you'll naturally see fewer projects that depend on applications, or libraries that provide specialized services such as a Twitter API library.
How easy is it to use? This includes things like documentation, consistency, and bugs. A great example of the first two is Python's scikit-learn - it has phenomenal documentation and the API is very easy to fit in your head while offering a great breadth of features. As far as bugs go, a lot of the time you just have to run into these, but things like the issue tracker can provide hints, as you mentioned.
I often reach out to others in the community to get feedback on various contenders.
I will often read through some of the source code to get an idea of the quality of the code. Not just "wow, this code is bad, I can't rely on this" but also "will I be able to debug this when things break".
That's just a few examples, but that's the gist of how I approach external dependencies!
this is a great mental ticklist to go through - I have made a note to try this next time I am making a decision.
I particularly like your last point, it seems so obvious now you have said it but can honestly say I am guilty of not diving in and having a quick look.
Thanks for taking the time to answer!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My take on "the less code you write the better" isn't "try to do in 5 lines what should take 50", but rather to avoid writing certain code in the first place. For example, avoiding writing a function that an external dependency can do well (of course that brings up the issue of understandability and size of your program, not to mention maintenance - did someone say "trade-offs"?). A better example, I think, is not writing certain features, or even entire programs in the first place. Why add a feature to, say, a source code-searching program like ack if you can write a small program that takes ack's output and gets you the result you want? Why write a program, however small, to process data if you can whip up a shell oneliner to do that processing for you? Anyway, that's just my 2¢!
Hey Rob, thanks for the considered response. I can definitely see your point of view about not reinventing the wheel and building things which already exist. I think you raise a good point that these stereotypical opinions can be interpreted differently from developer to developer. I would agree that working smart (using existing resources) is a great way to save time on a project.
To follow on from your point - I would be interested to hear about what your own personal criteria for deciding whether an external resource/dependancy is trustworthy enough to include in your project? Do you favour package downloads/online reviews/github issues solved?
I consider a number of criteria when evaluating a library:
That's just a few examples, but that's the gist of how I approach external dependencies!
this is a great mental ticklist to go through - I have made a note to try this next time I am making a decision.
I particularly like your last point, it seems so obvious now you have said it but can honestly say I am guilty of not diving in and having a quick look.
Thanks for taking the time to answer!