5 ms·

I have only been coding for 1.5 years and this kind of comment is validating what I worry is a very bad habit. I hate using dependencies unless they have reache

by gt_ 9y ago

I have only been coding for 1.5 years and this kind of comment is validating what I worry is a very bad habit. I hate using dependencies unless they have reached a certain level of legend in the community.

FLUX-YOU 9y ago
This is a normal feeling. But one weakness of this approach for javascript is that it's easier to become popular because you have a much larger base of developers.
- gt_ 9y ago
  That makes sense. I use Python the for most part. I feel like I have seen this happen with old libraries where they used to be very popular and maintained then became abandoned a few years ago.
  - funkymike 9y ago
    That can be okay. Depending on the nature of the library it might legitimately be "done." Personally, I would rather see this than a bug fix being committed every week. That makes me question how many more bugs there are and how much I'm going to have to babysit updating the dependency.
    - gt_ 9y ago
      That's a great point. Hmmm... I wasn't considering that. Oops. I'm glad I mentioned it! Thanks!
RobertRoberts 9y ago
>...unless they have reached a certain level of legend That is a similar tactic I use now for anything core. I know I commented that we don't have any dependencies in our core systems, but as an afterthought, this isn't entirely accurate. We do, but as you said they are "legendary", and don't change a whole lot anymore. I think you are on the right track. :) Edit: Keep business practicality in mind, if using a 3rd party library means you feed your family or are productive for the business, you need to weigh these considerations carefully. It's likely you need to use a dependency to get your work done, and then later when you are more profitable, you can clean it out if need be. Maybe that is how I should have worded my first comment in retrospect.
- cottsak 9y ago
  Some of this conversation isn't as exclusive and the tone it has. Many of these dependancies are open source. Nothing prevents you from copy/pasting the code and then maintaining it yourself. Then you alleviate the "hard to change" problem and you can vet it thoroughly inside your own team.

by gt_ 9y ago

FLUX-YOU 9y ago

This is a normal feeling. But one weakness of this approach for javascript is that it's easier to become popular because you have a much larger base of developers.

gt_ 9y ago
That makes sense. I use Python the for most part. I feel like I have seen this happen with old libraries where they used to be very popular and maintained then became abandoned a few years ago.
- funkymike 9y ago
  That can be okay. Depending on the nature of the library it might legitimately be "done." Personally, I would rather see this than a bug fix being committed every week. That makes me question how many more bugs there are and how much I'm going to have to babysit updating the dependency.
  - gt_ 9y ago
    That's a great point. Hmmm... I wasn't considering that. Oops. I'm glad I mentioned it! Thanks!

RobertRoberts 9y ago

>...unless they have reached a certain level of legend That is a similar tactic I use now for anything core. I know I commented that we don't have any dependencies in our core systems, but as an afterthought, this isn't entirely accurate. We do, but as you said they are "legendary", and don't change a whole lot anymore. I think you are on the right track. :) Edit: Keep business practicality in mind, if using a 3rd party library means you feed your family or are productive for the business, you need to weigh these considerations carefully. It's likely you need to use a dependency to get your work done, and then later when you are more profitable, you can clean it out if need be. Maybe that is how I should have worded my first comment in retrospect.

cottsak 9y ago
Some of this conversation isn't as exclusive and the tone it has. Many of these dependancies are open source. Nothing prevents you from copy/pasting the code and then maintaining it yourself. Then you alleviate the "hard to change" problem and you can vet it thoroughly inside your own team.