I'm a chronic wheel reinventor. If you're trying to make money off of your project, your mileage may vary. However, I've found that there are plenty of good rea

I'm a chronic wheel reinventor. If you're trying to make money off of your project, your mileage may vary. However, I've found that there are plenty of good reasons to reinvent the wheel. Although I'd very rarely reinvent the wheel when I'm doing something for pay as that implies issues like deadlines and maintainability, I do it all the time for personal projects. Professionally, I'll write only the code that I feel comfortable that I understand and can maintain. Otherwise, I'll look to third party open source code. Unfortunately, I have been bitten a few times recently by popular and well-maintained but poorly designed or tested libraries that include frustrating bugs. In my personal projects, I like to challenge myself. I will choose to write any and all code that isn't provided by the language's standard library even if trustworthy open source libraries exist that I would use in a professional situation. I like to think of it as "desert island programming". If nothing else, it has taught me interesting things about all sorts of domains I wouldn't have otherwise sought to learn about. And that knowledge is worth the struggle when making it to market as fast as possible isn't the goal. There are other reasons for reinventing the wheel besides supplementing your personal understanding. Sometimes the licenses of the alternatives are inadequate. Of course, that's a somewhat personal assessment. Sometimes the alternatives are poorly maintained, poorly designed, or have fundamental flaws or bugs. Sometimes it's not that the existing software is bad per se. Oftentimes writing software involves trade-offs and perhaps the trade-offs the major library's authors have chosen are different from what you might choose. Recreating it yourself can clue you in to these trade-offs and gives you the opportunity to explore different paths.