For those of you who are into development or programming of any type and if you read any type of blogs or long form articles that provide tutorials for how to achieve a certain type of task, then you’ve no doubt seen comments that say something along the lines of:
Or you could just use [this library] to solve the problem rather than writing it yourself.
Or maybe you’ll see something like:
There’s no need to do anything like this because XYZ solution already does it.
And it’s not that those types of statements aren’t true or even useful resources, but given in the improper context, I think they can seriously put a damper on the motivation people have for writing tutorials and/or reading tutorials because they tend to say that there’s no point in understanding how to do it in a given way when something else already does it.
It’s as if everything is reduced to reinventing the wheel – but it’s not.
For those of us who are genuinely interested in programming, isn’t part of the reason that we got into the field was not only to build things, but because we have an insatiable curiosity for how things work?
Programming: A Professional Hobby
To be fair, I recognize that – just as in any field – there are what I call 9-to-5 programmers. That is, they see their job as a strict 9-to-5 and they have hobbies outside of work on which they like to spend their time.
I’m not saying there’s anything wrong with that (because there’s not).
What I am saying, though, is that there are a high number of programmers who got into computing and writing code as hobby at an early age and just happened to be fortunate enough to be able to turn the hobby into a career.
To that end, there are many of us – again, not all – who have pet projects outside of our normal job on which we like to work, share, contribute, or whatever else.
For some, this includes writing articles and tutorials on how to achieve a certain task in a given language or set of languages, and for some this includes reading said to tutorials so that we can actually pick up another aspect of our trade.
When it comes to programming, the truth is that there are a lot of things that have been done before, and we’re reinventing the wheel in yet-another-way.
Starting from the basics…
- How many string libraries have been written over and over again for different languages?
- How many times have you had to write the same programs in different languages to get a feel for the syntax?
- How many dependency managers are currently available?
- How many XML parsers are available for download?
- How many platforms are available for publishing content to the web using a database-backed web applications?
- How many design patterns exist and how long have they existed?
The list can go on, obviously, but the point is that although it’s great to create new, innovative, and useful tools, it’s also important to understand how to achieve certain tasks – to understand how something works – in order to help get a better understanding of the thought process and engineering that went into the architecture of the solution.
Reinventing the Wheel
If you’re someone who finds yourself leaving more comments about why a certain article or tutorial appears needless, consider the fact that the point may not be to showcase how to do something for the case of ding it.
And if you’re someone who finds yourself discouraged by sharing an article, tutorial, or project for which another similar utility, tool, or program already exists, don’t sweat it. The knowledge gained in building that application transcends that single project and can be carried into future work.
Sometimes the point of sharing the what, but it’s the how.