You read what others had done and you took the next step. You didn’t earn the knowledge for yourselves, so you don’t take any responsibility for it. You stood on the shoulders of geniuses to accomplish something as fast as you could, and before you even knew what you had, you patented it, and packaged it, and slapped it on a plastic lunchbox, and now…
When I’m writing code for clients, I like to be as efficient as possible. When faced with a new challenge, I’ll first check to see if anyone else has approached the issue and try to learn how they handled things.
Sometimes this takes the form of reading a tutorial on a blog. Other times it’s a call on Twitter for help. Yet others I’ll ask coworkers on HipChat.
There has rarely been a time I’ve been faced by an issue so exotic and unique that I need to build a solution entirely from scratch. Yet, I’ll often do just that.
If you never reinvent the wheel …
… then it becomes a mysterious piece of technology that never changes or improves. It becomes magic that’s included in all of your projects, but which is never fully understood by the developers using it.
One of the first tutorials I ever used when I started in web development was about building a JavaScript-powered drop-down navigation menu. It was a thorough discussion of the end objective and the desired UX, but the description of the code involved was incredibly superficial. More of a “copy this, I don’t understand it either, but it works” article.
I copied the code, used it everywhere, and moved merrily along.
It wasn’t until years later, when I really learned JavaScript, that I understood what was going on. The [cci]mm_[/cci] prefix on every function name was a proprietary prefix applied by MacroMedia – the original code snippet had been auto-generated by DreamWeaver, then copy-pasted into tutorial after tutorial until it found its way to me. I thought the prefix was a necessary piece of the code, and up to that moment had prefixed even my own functions with the magical [cci]mm_[/cci].
Did I feel stupid.
A Little Reinvention is a Good Thing
I don’t always build entire solutions from scratch – once I understand a library (like jQuery or Lo-Dash or Select2) I’ll use it where I can to speed development along. But often, I’ll take some time to rebuild a part of a library I use, just to be sure I understand how it works.
In some cases, I’ll find ways to actually improve the library itself. Some of these discoveries have led to commit props for me on different open source projects. Others have led to privately-maintained forks of libraries with my performance enhancements included.
The short point: reinventing the wheel is not always a waste of time.
For example, consider a literal reinvention of the wheel: Airtrax.
How often do you take something you’d otherwise take for granted back to the drawing board and start from scratch? In what ways will your projects benefit as a result?
