My thoughts on NIH
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.
On a side note, many will say that it's fine to make your own things, if you don't use it in production. I'm not entirely sure what the argument is supposed to be, I suspect something with security and optimization, which are both bollocks. Computers are unreasonably powerful these days. Even if you need to optimize because your program is suffering, you likely will have to redo the implementations of anything else as is. Likewise, most security vulnerabilities are going to crop up no matter what. It's impossible to have the perfect program, even a hello world file will have some sort of security vulnerability. Even if, say, a library has perfect security, the mass majority of applications probably aren't being used on a massive scale, and if they are, on average these applications aren't seeing networked use. Additionally, many security flaws can be solved by simply sanitizing input, which is something you should probably pick up even if you are using this "perfectly secure library."
Besides, destandardizing security sounds like a better idea, as it would mean hackers would have to figure out a new standard for every hack they want to do. I can see why this would be completely unrealistic however. Imagine a web browser having to support 2,800 security standards and somehow having to discern them.
The only decent argument I can think of is that using a NIH library may confuse other developers who were not given good documentation, or were not introduced to the library prior. This is a fair and reasonable complaint. Though this can be mitigated, especially in corporations where little is not documented and almost everyone working on the project knows about these libraries, it can still easily come up if, say, external contractors are brought in, or a new team is assigned to the code.
Finally, on the personal side of things, you may just not like the implementation of something. For example, I don't like GNU make. It just never appealed to me, and though I know it's user error, I have never successfully gotten something to compile from a makefile. So, I have a completely different implementation I like to go with, where my entire project can be compiled from starting with one file. Infact, I made a Batch specifically for this. It does the things I want it to do. I drag, I drop, it compiles after asking me a question on which compiler option, and then immediately executes it.
It doesn't matter what you don't like about it, I personally think that if you don't like it, you're more than welcome to make your own replacement, no matter what it is. We arguably would not have any of Chris Sawyer's many games if someone didn't go out of their way to do their own implementation of something they didn't like.
There's also a sense of accomplishment just not found if you use a premade program or library. It's indescriable to stare at something and go "I made that happen. I did all of that." Sure, getting SDL2 running is great, but knowing that EVERYTHING underneath is yours, and that you made a concerted effort to improve gives you a satisifcation unlike any other.
If there's anything you can take from this, I'd take that you should go out and make your own small scale project, completely from scratch. It'll give you a lot of insight, and also help you determine if it's worth the satisfaction, or if you'd rather just stick to what's already made. There isn't a wrong answer here, so long as you try.
This post devolved the moment I started writing it. I could use an servant whose sole purpose is to remind me not to do late night blogposts.