Wholeheartedly agreed.

Moreover, one thing NIH syndrome handwavers miss is that developing a custom situation-specific solution allows you to expand your knowledge in that discipline, create a more tailored solution, and avoid supply chain vulnerabilities that can come with using third-party packages. In my experience a handbuilt solution to a problem is going to be much more efficient in most cases than OSS out there, except in spot instances where the scale of the task is not able to be achieved in a small amount of code (e.g. a versatile graphing library), although these are /very/ few and far between.

NiH is expensive

> 1. You can do it better, with better taste

You can, or you can just work around the existing tooling, which is quicker and assuming you choose wisely, has a wealth of googleable documentation. Its humbling, because you need to learn through _using_ rather than creating. It feels less productive, even though you're 90% of the way there with an existing tool

> 3. Building something yourself lets you become an expert in the domain and the tool you're building,

It might do, or it also might just drown you in complexities of the domain that you're building the tool for. Plus the assumptions you make when first designing the tool tend to be disproven as you learn more. Its good to question tools, but not blindly re-write them without studying _why_ they do that thing in that weird way.

> 4. More often than people realize, building something yourself ends up simply faster than first learning

Which means you are very likely make the same elementary mistakes as the previous generation tools. Plus its _always_ slower to start. mainly because naive re-writes have naive bugs. But you just don;t know it yet.

At the legions of VFX companies I've worked at, the number of people who look at the asset management system and go "Oh thats not hard, lets just re-write that to be x" is too damn high. 6 engineers and a year later, they still have a broken system, but in new and interesting ways.

Am I saying that you _shouldn't_ make tooling/software or custom things? no. I'm saying that you should really save yourself for something that critical to the company.

All projects have a limited number of innovation tokens. The more you use the slower your project will go. You should really only look to use 2 innovation tokens max.

I'd say the key insight that I see on #4 is that people do not consider libraries code. They consider it black box. It is the same urge that causes teams to label a code base they have taken over "legacy" and "in need of rewrite."

Sometimes, the answer is to dive in an seek to understand it. Now, that may end up meaning that you fork the tool or contribute back to it. It may mean that you choose to build anyway, and it may mean that you come back understanding it. However, if a library is not working for you, the slowest answer is often the one where you fiddle with it until it's working without taking the time to dive in.

Where i work, there is a lot of NIH wheel-reinvention. People make exactly these arguments for it. I think it's mostly nonsense.