This overlaps rather precisely with my own experience, which is more than 2 decades, the last 15 years in front end - except I studied laws instead of electronics.
Actually, the last point has an exact mirror twin that can be equally bad: "Invented here", which is what happens when you don't see yourself and your colleagues as professional enough to a) decide when it's better writing something in-house and/or b) doing so as good or better than any external dependency that one could otherwise use.
There are a few tell-tale signs of IH:
trying to adapt an external dependency to the issue,
using external dependencies for trivial tasks and
outsourcing complexity to external solutions (so the complexity can be solved by the external implementation instead of the developer thinking the issue through first and finding a less complex solution that can easily be solved without the external dependency).
Yes there are always exclusions and special cases and yes using dependencies for trivial stuff like trip/leftpad etc can lead to bigger issues. The balance between using dependencies and building in-house needs to be decided on a per team per project basis IMHO. My normal take is that use a dependency for non business solutions and for technical stuff. For example use a HTTP library for building APIs rather than building one your self, as the libraries are much more mature and better at those tasks. In such a case adapting your solution to the library is a good thing as you will be following industry standard. But for business solutions and special cases you could always build in-house solutions
This overlaps rather precisely with my own experience, which is more than 2 decades, the last 15 years in front end - except I studied laws instead of electronics.
Actually, the last point has an exact mirror twin that can be equally bad: "Invented here", which is what happens when you don't see yourself and your colleagues as professional enough to a) decide when it's better writing something in-house and/or b) doing so as good or better than any external dependency that one could otherwise use.
There are a few tell-tale signs of IH:
Yes there are always exclusions and special cases and yes using dependencies for trivial stuff like trip/leftpad etc can lead to bigger issues. The balance between using dependencies and building in-house needs to be decided on a per team per project basis IMHO. My normal take is that use a dependency for non business solutions and for technical stuff. For example use a HTTP library for building APIs rather than building one your self, as the libraries are much more mature and better at those tasks. In such a case adapting your solution to the library is a good thing as you will be following industry standard. But for business solutions and special cases you could always build in-house solutions
Maybe I should have rephrased that. The sign was meant to be "trying to adapt an external dependency that is not exactly solving the issue".
Absolutely true