Read it, and use it to refresh your frame of thought on the issue. This is one of the most important parts of building anything.
Every tool has trade-offs. In the software world, that trade-off is usually related to how much it can do, compared to how much effort it takes to do it.
If you want a house, you could start with:
- Atoms. It’s possible, and they can certainly be combined to make yourself a house, but this is going to take wayyy too long.
- Raw materials. This is certainly reasonable, and strikes a balance. You can build the house you want without going too deep.
- Pre-fabbed frame. This is even faster and cheaper than raw lumber, but you’re losing control over what your house looks like.
- A house. Hey, nobody said you can’t just buy the house. Of course, you now have no say over the details of your house.
Software works in much the same way. If you want a website that does a specific thing, you could write your own webservers in assembly if you were insane. Likewise, you could just go out and buy a pre-written package that does what you want. The problem with innovative software, however, is that it doesn’t already exist, at least not your vision of it. This is the point where people say “Ok, well, what are the biggest pieces that exist for each part that I need? I’ll just stitch them together!” Stop. Seriously. Stop right there.
This sort of “greatest common factors” solution is often right, and can save you time. On the other hand, it can also lead you down a maze of problems that you may never return from. Every time you take on a 3rd party component, you become dependent upon their choices and design decisions. Depending upon the component, this can be good and bad. It could mean that you get free new features down the road as they are added. It could also mean that you have to manage through 12 layers of abstractions just to use the 5% of that component that you actually need.
Don’t re-invent the wheel, but also don’t go buy another wheel when all you needed was the spoke.