Reinventing the wheel can be very valuable. Even if you don't create a better wheel, you'll learn a lot about how it works, which can really help you out in the long term.

this is actually good advice

Exactly, I don't get why so many people are against that, it teaches you more than using what is already out there.

Agreed, but don't do that on a paid project though. Having to maintain a poorly written implementation of a common library is not a fun thing to do. Doing it on a toy project is fine

@hasselsoff that's exactly the point. Well said

Wait till you have to maintain a legacy code base where someone created their own DateTime library that must talk to backend vendors that use industry standard time_t or DateTime objects.

If you think managing time across time zones and various languages is bad, wait until you cannot even trust a seemingly regular time keeper algorithm.

Holy hell.

Glad I scrolled down, was going to say a similar thing. I learnt a lot by doing this in my early days.

@hasselsoff should probably have mentioned that in the OP. 😂

That's why I installed Arch Linux manually. It's complicated and unnecessary but it's an amazing learning experience.

People's against it because it adds more testing to something that may already be well tested. Imagine adding a way to secure your API for third parties to use it against other people's data. A whole lot of work. However, that's why Oauth2 almost a standard, and there are implementations for roughly ever language.

For study and pet projects, sure, reinvent the wheel. That's fine

@Berkmann18 you can easily miss edge cases that may cause a lot of problems later one. Chances are that a third party plugin/library has already taken care of that. Also while this isn't true for all of them, they could be more efficient that what you will write. If you are busy making a car, you wouldn't want to spend huge amount of time on the weel. Your design may not have spokes good enough to carry the load of the car or may not be able to spin at speeds you want with materials you used or how you used it and you don't have an easy way of testing it. The wheel produces meanwhile has all his focus on the wheels. He knows them in and out probably.
But that said only you know how you will use the wheel. You can design wheel that suits your requirements. Might be the commercial wheel is not good fit for your car. In that case shoehorning it in isnt the greatest idea either. if you are successful in making good wheel and work on it, you might become the next big wheel maker in market.

@flag0 I agree but not everyone wants to make a car while focusing on just a wheel you know.

Reinventing the wheel is one of the best practices for learning. 🙂
For projects with tight deadline and/or budget use existing wheels

Dry means don't repeat yourself but repeating or cloning others is a very good way to practice and learn new concepts. But once you get it, don't repeat it in real life projects with deadlines.

great advice.And to people against it, I guess we could use a middle ground here: there is a difference between real application and learning approach.A library is not going anywhere, you can just use it as it is in your professional work, however it won't hurt you to spend time on it analysing how it works in background

I feel so connected to this post that I wanna comment more. a few days back when I was an intern ,they asked me to handle things using Bluetooth. I knew nothing about it and The official docs were all messed up. Then I found a great library with a use case quite similar to my requirement.Was curious to dive into it, learned a hell lot of things,almost recreated the library But at the end used the library in their project.The project is now a strong one with lesser hassle and test-cases :)

Conclusion: reinvent the wheel, just don't use it in production.