4 ms·
I just spent two weeks trying to figure out code at work that required 8 dev dependencies from npm locked down to certain version numbers not specified in the p
by austincheney 7y ago
I just spent two weeks trying to figure out code at work that required 8 dev dependencies from npm locked down to certain version numbers not specified in the package.json.
That ends up being hundreds of total dependencies to run two build steps and 1 http service. What a waste of time and code.
How did we get so drug addicted to shitty outside code? Had I not been completely new to the team I could written a better solution in about an hour directly with Node.
- vbezhenar 7y agoYou need one function so you add library. But that library contains dozens of functions and uses other libraries to implement those functions. So now you have all those dependencies even if you don't use them.
- austincheney 7y agoDo you really need that one external function though? At what point is it better to simply write it yourself?
- juangacovas 7y agoIt's a matter of balance, always. A thin line. And dogmas that people on teams follow (we all do in some way). Not invented here syndrome, always create a class, always put a class in its own file, premature optimization blablah, don't use goto, this and that is bad practice in that language, don't optimize until you need it (but you later don't have time to profile, or don't really want to...)
- majewsky 7y agoNever-invent-here syndrome is just as bad as not-invented-here syndrome, though.
- armitron 7y agoNo, never-invent-here (aka extensive 3rd party library reuse) is orders of magnitude worse. NIH means you retain full control of your codebase. It's really determinism that leads to you being able to make reliability/robustness, availability and security guarantees. Never-invent-here is a disaster waiting to happen.
- lonelappde 7y agoExternal code is better than internal code because you can reduce it to internal code just by forking it. If it is even minkscully useful, that's a win.
- agumonkey 7y agoMy main point is that if it's something you cannot write exhaustive tests yourself in a few minutes then forget it and use something that has been in the field.
- austincheney 7y agoThat is not a compelling argument. Yes, tests are important. However tests also require maintenance, so they are debt just your like dependencies. If writing my own build and HTTP service requires a few tests I would happily take that over failing for weeks with hundreds of megs of extraneous code that doesn't work. Honestly, I think people justify this nonsense to themselves because they are scared to write original code, even if its incredibly tiny. The primary purpose of writing software is automation, if you aren't automating things with everything you write you are probably just an expense center. This is the financial way to say that your misplaced objectives make you unproductive and/or unreliable. It doesn't have to be that way.
- lonelappde 7y agoYou don't need hundreds of megs. Use a stripper to strip put the parts you don't need.
- austincheney 7y agoI don't govern the mega corp.
- vbezhenar 7y agoIMO it's a bad state of modularity. There should never be desire to write function yourself because of fear to bring unused code to the project. Imagine world where you can import a single function and it'll bring only required dependencies, no more. But, yeah, currently you have to weight whether it's better to write the code yourself or bring external libraries with some burdens.
- deleted 7y ago[deleted]
- thisguyuknow 7y agoIMO, you get NPM when you get venture capital pouring money at script kiddies and tech evangelists. No worries, it will all burn down eventually.
- dgoog 7y agoThis a thousand times. Software engineering has been hijacked by a bunch of no talent assholes propped up by clueless vc. We need to kick these jerks out.