When it comes to using external libraries, sometimes you can't find exactly what you need, and there comes a question: should I write my own lib? I can outsource it later, it will be helpful, and I'll be valuable to the community. Well, that's not always the case.

Through the years, there were several times we've had to deal with some small libs injected deeply into the project, linked to a GitHub of a developer who left a company long ago. And that was painful.

When you start your little side project, it seems like a good idea to cover all the cases your project needs, but that might be why others will never use it because now it's too specific to what you need. And eventually, most developers move to other projects or companies and stop supporting the tool they've introduced.

Does it mean you should not start a new lib? - Of course not.
Just think of the reasons you do it in the first place.

Do it for pure fun.

We all enjoy coding, and it could be just a side project. Yes, you might have got an idea from the real issue you are facing at work, but don't be in a hurry to import it into a big project right away. (That's precisely the reason everything crushes in the end). So have fun, make it like you don't have a deadline, and you can actually work on a better well-developed solution. Enjoy the run.

Open-source it.

When you have your tool ready and tested, open-source it, write a good annotation and provide clear documentation. Tell your colleagues and friends, collect feedback, and share with the community. And keep collaborating and accept others' ideas, it will help you build smth strong and valuable. Let it grow and prove itself. Let others contribute and make it independent, so even if you lose passion for it, you'll still have the community to maintain it. It's unlikely you'll write a tool completely autonomous from other libs. Even if you are not going to bring new features, there's still a lot of work to keep up with dependencies upgrades to make it stable and useful for future generations.

Collaborate with colleagues

Another approach would be to bring your initiative to your colleagues company-wide and see if anybody else will benefit from realising your idea. If you work in a big company and maintain a couple of projects, you might want to share some code, so creating a lib seems reasonable. But don't get stuck on specifics only you need. If you're going to share functionality between two projects, there's a significant chance your colleagues from other teams have the same issue and want to do the same.

A good example here is a company-wide UI kit. I've been working in Revolut for several years, and in the beginning, our internal, retail and business applications all had different UI. And therefore, all teams worked on their own UI kit with limited functionality, which fit satisfactorily in one domain. But each new app created raised the question, "which UI kit" should I use? And the winner usually was the one with broader functionality and better support. In the end, we have moved to one well-maintained UI kit supported by a dedicated team. Everybody migrated to it, and everybody is interested in bringing new features and keeping top quality.

So share your idea with other teams. It could be a good start for a shared tool everybody would benefit from.

Be professional.

Think of your situation first. If you are in a rush to keep up with deadlines, it's always better to use a well-documented external library. If it does not precisely fit your needs, it might be better to negotiate the requirements instead of inventing the wheel within the night. Consider how it's going to be supported later.

Have fun!

It doesn't always have to be about your job. So don't hesitate to create a new lib for your own enjoyment, and don't store it just on your machine. Share it with the community. And who knows, it could become a useful and valuable tool.