I ran into this old post by Jeff Atwood, that makes a good point. Reinventing the wheel is most probably the best way to learn about “wheels”, and about the problems they designed to solve. There is no better way to learn about anything than actually implementing it.

However, consider a project that, say, 3 engineers are working on, and each one of them reinvents a different “wheel”? Here’s what will happen:

• Engineer #1 will write a HTTP server
• Engineer #2 will write a RoR like backend MVC framework
• Engineer #3 will write a jQuery like dom abstraction JS library

You see where this is getting… There are at least two main problems here:

1. This project will probably be buggy, will take forever to develop, and will be impossible to maintain.
2. The next engineer coming after you, is more likely to have experience with jQuery than in your home brewed fooQuery.js and will probably have more desire to gain expertise with jQuery over your amazing home brewed library.

Basically the more code we own, the more liability we have to maintain, test, debug, fix, improve, write documentation etc. Given the limited resources we all have, the last thing we need is to own more code.

This is especially true when all the above problems are already solved with efficient, fully tested, fully documented open source projects we can use. for free. with communities and all the other good stuff that comes with open source projects.

This is exactly the reason why engineers should own or participate in pet projects. A pet project is the perfect place where its not only okay to reinvent the wheel - it is desired — this is exactly the room to do crazy things, experiment, learn, and develop your professional skills.