It’s a scenario that plays out in countless offices and home offices every day: a software developer stares at a tricky problem, cracks their knuckles, and begins architecting a solution in their mind. They envision the modules, the APIs, and the elegant lines of code that will slay the dragon. Days, or even weeks, later they emerge with a working solution, proud of their creation, only to discover (or have a colleague point out) that an open-source library or internal tool already does the exact same thing.
Sometimes the existing tool is even better than what the developer built.
This phenomenon is the source of a well-worn joke in the industry: “Every time a developer encounters a problem, they start building a solution, completely missing that it already exists.” While it’s funny, the reality behind it is a costly and frustrating cycle of duplicated effort. It’s a multifaceted issue rooted in psychology, corporate culture, and sometimes a lack of training. It’s often summarized by the pejorative term “Not Invented Here” (NIH) syndrome.
The Case for “Proudly Found Elsewhere”
The cost of this duplication is staggering. It’s not just wasted development hours. It’s the compounded cost of maintaining multiple, slightly different implementations of the same thing. Every bug fix has to be applied in multiple places. Every new developer has to learn multiple systems. Over time, the software ecosystem becomes bloated and brittle.
This is why a cultural shift toward “Proudly Found Elsewhere” is so important. It’s a mindset that prioritizes solving the business problem over the personal satisfaction of writing every line of code. It recognizes that standing on the shoulders of giants, whether they are open-source maintainers or a team in the next building, leads to faster delivery, higher quality, and more sustainable software.
How to Build a “Proudly Found Elsewhere” Culture
Moving past NIH syndrome requires a conscious effort from both individuals and organizations.
For organizations: Build a marketplace, not a black hole.
If you want code to be reused, you have to make it easy to find and easy to use. This means investing in internal component marketplaces where teams can publish their libraries with clear documentation, usage examples, and versioning. It also means fostering a culture of collaboration where teams are encouraged to talk to each other about their technical challenges and share solutions.
For organizations: Incentivize reuse.
Change the metrics. Reward engineers who contribute to internal libraries and those who choose to reuse them. If a project is delivered faster and with fewer bugs because it leveraged existing components, that should be celebrated as a win, not dismissed as “not doing real work.”
For developers: Ask “Why not?” before “How?”
Before writing a single line of code for a common problem like logging, authentication, or data validation, make it a habit to search for existing solutions. Ask your teammates. Check the company wiki. Look for open-source libraries. Assume the solution already exists until you can prove that it doesn’t.
For developers: Contribute, don’t fork.
If you find an existing library that covers 80% of what you need, don’t immediately decide to build the remaining 20% from scratch. Consider contributing the missing feature back to the original project. Another option is extending it with a plugin. Improving an existing tool is almost always better than creating a new one that will have to be maintained forever.
The Nuance: When Reinvention Is the Right Choice
It’s important to acknowledge that reinventing the wheel isn’t always a bad thing. Sometimes it leads to innovation. As developer Lea Verou has argued, using a massive, bloated library for a tiny fraction of its features can introduce significant performance overhead and long-term maintenance costs. If you only need 5% of a library’s functionality, writing a small, purpose-built function might actually be the smarter choice.
For example, parsing a few lines of simple Markdown for bold text and links doesn’t necessarily require a 1,700-line library. A small custom function might do the job more efficiently and with far less complexity.
The key is intentionality. The goal is to stop the accidental or arrogant reinvention of wheels, the kind that happens because a developer didn’t look, didn’t ask, or didn’t care. By shifting our focus from the pride of creation to the satisfaction of solving real problems efficiently, we can escape this costly cycle.
We should celebrate finding the perfect existing solution just as much as we celebrate building a new one from scratch.
Top comments (0)