3 ms·

This "reinventing the wheel" concept has to die. Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementa

This "reinventing the wheel" concept has to die. Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain). Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare. It's like I'm making a go-cart, and making some nice appropriately-sized matching wheels for it, and someone comes along insisting I don't "re-invent the wheel" and use these four mismatched truck wheels instead. Yes, I'll save time making the wheels. But the rest of the project is screwed.

DLA 6y ago
> Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain). So much agreement. We often will rewrite smaller sets functions or other code for the express purposes of trimming dependencies, understanding what the code does, and having the opportunity to adopt it into our codebase with a fresh re-look at implementation, adding comments, etc. > Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare. Again. Agree with you strongly. Just because something as been available in npm does not automatically mean battle tested. There's a ton of broken/poor code out there.