I had to use a js library for something today. npm install downloaded 113 new packages. I'm not even a javascript programmer; I'm saddled with being "full-stack" I'm supposed to read all that every time I need a new library? Or write it myself, when I have absolutely no idea how to build something that complicated, if I had time, negating the whole point of OSS in the first place?
Nobody's just reading your code
51–60 of 188 posts
Re: Nobody's just reading your code
#52Earlier quoted context omitted.
> ... willingness to fearlessly dig into someone else's code. I've done this many times. The problem is that it takes a lot of time, and there's no way you can dig through more than a fraction of a large codebase. You gotta pick your battles.
Pragmatism wins the day, for sure. I'll happily read someone else's code (e.g., an open-source GitHub repository I rely on) if it's necessary to troubleshoot issues or implement a feature. There needs to be a reason (i.e., motivation) to read code.
1. Spend hours digging through layers and layers of crufty JS.
2. Find the issue (and the package responsible for the issue).
3. Find out there is a Github Issue for the issue.
4. Find out there is a pull request for the issue.
5. Find out the pull request is sitting in position #35 of #128 pull requests going back to 2015.
6. Go binge drinking.Re: Nobody's just reading your code
#53Earlier quoted context omitted.
Pragmatism wins the day, for sure. I'll happily read someone else's code (e.g., an open-source GitHub repository I rely on) if it's necessary to troubleshoot issues or implement a feature. There needs to be a reason (i.e., motivation) to read code.
On github and the node/JS ecosystem, the way this will play out: 1. Spend hours digging through layers and layers of crufty JS. 2. Find the issue (and the package responsible for the issue). 3. Find out there is a Github Issue for the issue. 4. Find out there is a pull request for the issue. 5. Find out the pull request is sitting in position #35 of #128 pull requests going back to 2015. 6. Go binge drinking.
8. (optional) Thank the creators and maintainers for the time and effort they put into it.
Re: Nobody's just reading your code
#54Earlier quoted context omitted.
On github and the node/JS ecosystem, the way this will play out: 1. Spend hours digging through layers and layers of crufty JS. 2. Find the issue (and the package responsible for the issue). 3. Find out there is a Github Issue for the issue. 4. Find out there is a pull request for the issue. 5. Find out the pull request is sitting in position #35 of #128 pull requests going back to 2015. 6. Go binge drinking.
7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.
Re: Nobody's just reading your code
#55You're oftening wondering who is gonna dig into this code of yours and think about your coding, esp. when you're not following the best practices and TDD.
Re: Nobody's just reading your code
#56Earlier quoted context omitted.
7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.
This is not always an optimal solution. Because by doing this you have essentially became a maintainer of a dependency you initially wanted to 'just' use.
After coding for almost 20 years now, full time, I have never regretted not using a dependency. But I have regretted using one multiple times.
(the regret is like a walk of shame during the "separation and cleanup" phase at the end, which makes me question the "got work done faster" phase at the beginning....)
Re: Nobody's just reading your code
#57Earlier quoted context omitted.
Pragmatism wins the day, for sure. I'll happily read someone else's code (e.g., an open-source GitHub repository I rely on) if it's necessary to troubleshoot issues or implement a feature. There needs to be a reason (i.e., motivation) to read code.
This is the only reason (at least for now) that makes me dig into a library code. And I always got some benefit from it. I think we often treat libraries as voodoo blackboxes, but they're more often thatn not created by normal people with great skills. Sometimes it's a great way to learn a way to code, or even better, to understand the behaviour of a library. I found myself doing it more often when the IDE itself dow…
Same here. It's about trivial inconveniences. I sometimes can be bothered to download and read through the codebase of a dependency, but most of the times I end up in third-party code happen when it's just a single jump-to-definition keypress away - the same keypress (M-.) which I use all the time for my code. That seamless browsing really blurs the difference.
Re: Nobody's just reading your code
#58Earlier quoted context omitted.
This is not always an optimal solution. Because by doing this you have essentially became a maintainer of a dependency you initially wanted to 'just' use.
This is sadly why I keep my dependencies to a minimum. After coding for almost 20 years now, full time, I have never regretted not using a dependency. But I have regretted using one multiple times. (the regret is like a walk of shame during the "separation and cleanup" phase at the end, which makes me question the "got work done faster" phase at the beginning....)
If you've ever switched out dependency X for dependency Y I suppose you regretted not using Y to begin with.
If you've ever stopped working on your own solution to a problem and instead used a solution provided in a library didn't you regret not just using the library from the beginning?
Re: Nobody's just reading your code
#59Peter Seibel, the author of the Coders at Work book mentioned in the post, actually discussed this in a blog post: http://www.gigamonkeys.com/code-reading/ It's not quite true that none of the programmers interviewed in the book routinely read code for fun. In his blog post, Seibel mentions the exceptions: > First, when I did my book of interviews with programmers, Coders at Work, I asked pretty much everyone about c…