My thoughts on NIH
Current mood:  amused

A bit of a ramble-y blogpost, mostly because it's fairly late as of writing this. Hopefully, that's okay.
Many will shun the Not Invented Here mindset. It's not hard to see why. Many corporations will spend hours upon hours of creating their own implementation of something that has one or more publicly available implementations. It's often compared to reinventing the wheel. It's seen as an outdated and closed minded mindset, something that should be disposed of along with the rest of the 20th century's many interesting quirks, such as 70s retrofuturism or cathode ray tubes. Hopefully obviously, not everyone thinks this way, and there are valid criticisms towards NIH. This is just a rough generalization of remarks made towards NIH that I've found. It's also a fairly closed-minded view of NIH. Let me explain why.
Perhaps the weakest argument I have is that it's sometimes necessary to go with a NIH approach. While it's nice to know we have so many libraries these days that can do everything for you, such as FLTK, Node.js, and SDL2, there are times you will come across something you need to implement, but cannot. Often times, this is because the implementation, whether it's the best or not, is copyrighted or simply not for public use. Adobe is infamous for copyrighting many of the implementations they made themselves for their products, such as Photoshop. While this is perfectly fine, and I have no problem with them profiting from their hard work, it does put you into a tricky situation when you want to implement a similar feature in your own product. Therefore, your only option is to invent it again, yourself. This, to many, doesn't qualify as NIH, however it does to me, as it fulfills the requirement of "we won't use it because it was not invented here."
A stronger argument can be made for practice and training. While using someone else's implementation can be incredibly expedient, writing your own implementation not only gives you a deeper understanding of the lower levels of what you are using, but also can act as a way to teach yourself new concepts. When you go to implement something, you typically start at writing a general description of what you'd need. Once you've written this down, you go into researching what the math would be behind it. This engages you to learn the mechanics behind what you are implementing, and lets you find clever new solutions, or be Mr. Carmack and simply look up the best equations once you have a grasp of what you need. However, you still need to transfer the math to the programming language. As with most cases when looking to do something new, you will likely begin to look through the documentation of your language, and this will cause you to absorb new knowledge and have new concepts click. Doing this is especially useful during company training, as it promotes learning and understanding the language that you will be using.