[rxhernandez]

I was lucky to learn this a decade ago when I was an intern; except it came from the electrical engineering side of the department (a department who produced products that were seen as the gold standard for that part of the medical device industry)

Manager (who was a world class electrical engineer): "why did you reuse this?"

Friend (who was also an intern): "I assumed ${staffEngineer} knew what they were doing and it would be fine to just place it in this design"

Manager: "never assume that anyone knows what they're doing here or at any other organization."

[lanstin]

Ha that last is the truest advice ever. I trust some people to end up at good decisions, but in the flux, there are many silly things tried, thought, and proposed. Don't even trust your past self too much.

[Ygg2]

That's a great way to have infinite Not Invented Here (NIH) syndrome.

[diffxx]

I think Not Invented Here syndrome is generally foolish and quite arrogant, but Not _Implemented_ Here syndrome can be a reasonable default. You rarely truly understand something unless you've implemented it yourself. You can draw inspiration from other sources of knowledge and in the process of implementation, you may decide that the source is better than what you would come up with. You might also discover that you can improve on the source, at least in some dimension. Your implementation could be as simple as a wrapper around the api of an existing library (or a DSL for using it). But after you've written the wrappers, you may find that it isn't too bad to just implement the darn thing yourself (probably don't do this with crypto!). I find it is generally a mistake to just bring in dependencies and directly build on top of them because then you become vulnerable to bit rot and vulnerabilities (or just needless complexity the use cases of other library users that are irrelevant to you) introduced upstream no matter how conscientious the upstream authors are.

[Ygg2]

> Not invented here (NIH) is the tendency to avoid using or buying products, research, standards, or knowledge from external origins.

It doesn't have to be actually invented, you can just build everything yourself.

Point is take that mindset ("Never assume anyone else in this organization knows anything"), quickly becomes never trust anyone else, and degenerates to - we'll need to rewrite the gluons (luckily people give up after they spend all their free time).

I prefer the Chesterton's fence. If you don't know what it does you can't remove it.

> I find it is generally a mistake to just bring in dependencies

I don't agree.

It's a pick your poison situation. Use dependency and have a centralized source of mistakes or distribute mistakes, e.g. billions of xml parsers suffering the same issue.

In my experience cautious use of dependencies is preferred, but I would take a well known devil. Over a homebrewed one.

[diffxx]

Every failed project I've ever been a part of has been a direct result of poor choice of dependencies. My experience is surely not universal, but nor is it rare.

[layer8]

Only if you’re unaware that “anyone” also includes yourself.

[Ygg2]

People always think they are the one exception.

[lamontcg]

That is more cargo cult behavior than NIH