DEV Community

Aleksandra Rodionova
Aleksandra Rodionova

Posted on

Should I write my own lib for a work project?

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.

Discussion (21)

Collapse
lexlohr profile image
Alex Lohr

While I agree with the arguments brought up by the others, let me play the devil's advocate here.

There's oftentimes drawbacks to these external libraries and those are rarely on the board when it comes to comparing solutions:

  • the maintenance effort of external libraries' inclusion is almost always underestimated
  • external libraries often have a lot more functionality than you need and are not always tree-shakeable, so they could inflate your app's bundle-size
  • this extra functionality might be inviting to over-complicate solutions because the external library makes it easy to model complexity (e.g. rxjs)
  • fixing errors in external libraries can be a hassle that can take much more time than doing the same for an internal library
  • external libraries can become orphaned, at which point you either need to switch to a different one or take it over yourself – this can even happen to much-used packages like lerna (which was luckily picked up by the team who develops nx)
  • external libraries might pose security risks that you need to handle
  • external libraries license requirements are rarely handled by developers

In any case, you should make your decisions and reasons transparent and document them, just in case you have to answer the question why something now takes longer than expected - especially if you are driven by deadlines rather than finished features.

Collapse
arodionova profile image
Aleksandra Rodionova Author

Very good points, thanks Alex! I'd say it's wise to consider all of those when you choose a lib to use, and not just pick a random one.

Collapse
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

this extra functionality might be inviting to over-complicate solutions because the external library makes it easy to model complexity

This is a general problem these days. Our abstractions have become very good at hiding the complexities of the tasks but few developers have really kept up with keeping track of this.

This is primarily a performance issue, but it can also lead to (albeit less severe) over-complicated program design.

external libraries often have a lot more functionality than you need and are not always tree-shakeable, so they could inflate your app's bundle-size

Ideally, libraries wouldn't even need any DCE at all. In the case of JS, I think es6 modules are what will one day get us there.

Collapse
lexlohr profile image
Alex Lohr

I have seen production examples of abstraction overuse to hide unnecessary complexity, which became maintenance and performance hell rolled into one pandemonium. The key issue of unnecessary complexity is that it's hard to separate from necessary complexity.

Also, ES6 modules are really helpful, but to get all the way, we need libraries made up from composable primitives and wrappers and/or modifiers. I'm currently preparing a post about this exact topic, so stay tuned.

Thread Thread
darkwiiplayer profile image

Also, ES6 modules are really helpful, but to get all the way, we need libraries made up from composable primitives and wrappers and/or modifiers.

That will be a lot easier if and when decorators make it into the language.

Thread Thread
lexlohr profile image
Alex Lohr

Decorators will offer some semantic sugar for wrappers, but that shouldn't stop us from employing the pattern already in order to get better tree shaking results.

Thread Thread
eshimischi profile image
eshimischi

@darkwiiplayer decorators just reached Stage 3, reddit.com/r/javascript/comments/t... so we can you it already with babel, of course

Thread Thread
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

decorators just reached Stage 3

Yea, I already saw that the other day. They had to get rid of the whole metainformation thing and put that into a different proposal, but tbh. that's probably for the best. And from the transcript of the presentation, it seems like there's going to be a bit more feedback from the browser side in the future as well. Who knows, a first implementation in chrome might be right around the corner :D

Thread Thread
eshimischi profile image
eshimischi

Use Typescript if you want to work with decorators already

Thread Thread
lexlohr profile image
Alex Lohr

There is also a babel plugin if you don't want to use TS for whatever reasons.

In any case, decorators are just semantic sugar around the wrapper pattern.

Collapse
pengeszikra profile image
Peter Vivo

Write own external open source library is great idea, and worth in long term, because even when do not use anybody it is great piece of your resume. For example I created this one and it is work well under my job searching process: react-troll

Collapse
arodionova profile image
Aleksandra Rodionova Author

True! That can strengthen your portfolio and show your code style to potential employer, especially if you are a beginner and don't have a solid employment history yet

Collapse
efpage profile image
Eckehard

Starting an open source project is really hard work. The community is not waiting for you: "hey look: there is a new project on github...". Github is filled with millions of insufficiently maintained projects that somebody posted for some reason years ago. So it getΒ΄s harder and harder every year to gain some interest for your work - regardless how valuable it is. As long, as you are not google or facebook.

For a possible user it is even harder to find usefull tools in a pile of dirt, so it is maybe not the best idea to publish every line of code you did under an open source library.

Collapse
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

Very generally speaking:

For work: Only after thinking it over a lot and maybe consulting some coworkers for their opinions.

For private: Absolutely yes! Re-invent the wheel often enough and we'll eventually drive flying cars :D

Collapse
dannyengelman profile image
Danny Engelman • Edited on

Always boils down to a single question:

Do I have the time, skills and resources to make my own tomato soup?

Collapse
liviufromendtest profile image
Liviu Lupei

I don't want to be a buzzkill, but I think it's a good idea to look at this from multiple perspectives.

I would discuss this with the Manager/CTO to understand the potential ROI (Return On Investment) of that effort.

Building something doesn't cost you anything, but it's costing your company (since you do get paid).

I would also schedule a meeting with colleagues from other teams, to find out if they would use those components, or if they would like to build their own instead.

Maybe do a small POC and see if folks would actually use it or not?

Lots of developers are doing RΓ©sumΓ©-Driven Development, doing things that would look good on their CVs, but that are not actually helping their companies or colleagues in any way. Don't fall in that trap.

If I would be doing something for "pure fun", I wouldn't do it on company time.

Most of all those big companies that contribute to open-source projects are also doing it for Marketing purposes (and obviously, they wouldn't publicly admit that, they're not that dumb).

Collapse
juniordevforlife profile image
Jason F

"If you are in a rush to keep up with deadlines, it's always better to use a well-documented external library." 100 times this.

I'm in a situation where a previous developer developed internal libraries, including one for state management, then bounced. The stuff works, but it's a bit unconventional. I think we would've been better off from a DX standpoint of just using one of the many well documented, well tested state management libraries that exist.

Collapse
arodionova profile image
Aleksandra Rodionova Author

Oh, that's a "good" one, state management is not smth you can easily replace πŸ€¦πŸΌβ€β™€οΈ

I feel your pain: Nobody has an idea how it works, but we still dragging it around carefully not to break it, because we don't have time to cut it out 😒

Collapse
nitzanhen profile image
Nitzan Hen

Great post!
My personal greatest consideration when thinking about starting a new library (or any other side project, for that matter) is the time it takes to get something meaningful out of it versus how much free time I currently have - I often find myself willing to start something new when I don't even have a fraction of the time needed for it (and not surprisingly, my few attempts at those were not successful πŸ˜…).
It's also easy to underestimate the amount of work required, on the library itself and its peripherals (docs, tests, etc.).

That being said, there's a unique type of fun you get from working on your own ideas and bringing them to fruition. And even more so when other people start using it, e.g. in open-source libraries!

Finally, it's only semi related, but there's a methodology called InnerSource, the essence of which is bringing open-source ideas and best practices to inner organization tools. It's not always possible to affect the "working culture" of an organization by a lot to properly make use of it, but it's still a beautiful (and novel!) paradigm.

Collapse
arodionova profile image
Aleksandra Rodionova Author

Thanks, Nitzan! Timing indeed is very important, I rarely can finish a small side project if I don't do everything in one go πŸ˜‚ which is rarely the case. So yes, it's a grate idea to properly estimate it before you start!

InnerSourse seems like an interesting paradigm! Thanks for sharing πŸ™‚

Collapse
mrdulin profile image
official_dulin • Edited on

Don't use the company's project as your playground. For generic packages, don't reinvent the wheel unless you can maintain it for a long time. In more cases, based on the existing package, according to the company's business and development efficiency needs, we should encapsulate some business logic using the open source package . But sometimes this kind of encapsulation is unnecessary, and additional code will be introduced, which is not conducive to troubleshooting fundamental problems, and the granularity of open source package encapsulation is sufficient.