Dustin IngramWriting — Speaking — Github — Twitter
On Doing It YourselfFebruary 21 2013
My initial attempt to solve this problem would be this:
- Find a couple existing libraries that were created to solve this problem;
- Check out a few examples, read some documentation for each, and generally get a feel for how each is implemented;
- Maybe try a proof-of-concept for one or two, and then settle on one.
To me, the amount of time I would need to invest to create something even remotely comparable would outweigh the amount of time it would take to find an existing solution, modify it to suit my needs, or even scrap an existing solution for another one. It seemed ludicrous to me do anything else.
A realization #
The more I thought about this, though, the more I realized the value in doing it his way. Aside from the intrinsic knowledge gained by re-implementing a system (which has been shown over and over again), the real benefit is this:
If no one ever builds anything new, we never get anything new.
We see this all the time. Take Bootstrap, for example. Did we need another front-end framework? Most would say we didn’t. Is it the best we’ve got now? Definitely – can you even name any of it’s predecessors? What about Netflix? It seems as if nearly every service they create is homebrewed specifically for their purposes. Could they have become what they are just by using commercial, off-the-shelf options? Maybe, but I would argue probably not.
The problem #
Here’s the problem with all of this. Take a look at this article recently featured on HN titled “The best programmers are the quickest to Google”. The focus is basically that all the relevant, most granular pieces of whatever project you’re building have already been written, and all you have to do is search Google for it. Here’s an excerpt:
If you need to implement something in code and it’s not cutting edge technology, Google it first. If someone else hasn’t already done it yet, you’re either Googling it wrong or way off in what you’re trying to accomplish.
The issue here is the thought that “We’ll always be good with what we’ve got.” If this mindset permeates us as developers (some might say it already has), we’re just rearranging deck chairs on the Titanic. Everything is a remix. Nobody will create anything new, ever.
Fortunately, there are some of us that reject this, that realize that the long term educational benefit, and net creativity this fosters within our community, outweighs the costs of doing it the hard way. These are the people that will change the game. These are the people which will create the tools of the future.