People talk about "reinventing the wheel" as if it's some sort of curse. It's true: in this day and age, tons of libraries are already available for your picking. These libraries have a lot of people working on it, so you can be assured that all the bases have already been covered (as much as possible).
Why recreate something that's already been created? And more: why recreate something that has a very likely to be a worse version of what's already there?
If we were talking about utility, then the recreation has no point. But from the point of view of the craftsman, it means the world.
Caring for our Craft
Engineering has always been associated with logic. We work daily with equations, syntax, optimizations, and all of those nuts and bolts to make sure that our products are working as smoothly and as fast as they can. We decide -- through logic -- everything: from architecture all the way to the last semicolon.
But at the end of the day, it's our innovation, creativity, and ingenuity that drives all of these decisions. We won't have a project without an idea.
The paradoxical truth is that engineering is art more often than it is engineering.
And for any craft that works with art, care is a must.
A baker has to hand-pick ingredients, knead the dough properly, measure accurately, and understand the nuance of every decision in order to create the perfect batch of bread. Truly, bread created this way will be said to have been made with care.
On the other hand, if the baker uses stale ingredients, kneads the dough hastily, measure inaccurately, and just perform random decisions (possibly due to inexperience), the result would be stale and lifeless bread.
Only by creating, making mistakes, destroying, and once again recreating, will a baker be able to create bread with heart. That is, bread that's been cared for.
Reinvent the Wheel
Just like the baker in our story, us engineers would get by just fine by using bottled up solutions without truly understanding the nuances behind them. Our customers would most likely be none the wiser.
No. Reinventing the wheel is not for them.
Reinventing the wheel is for us. It's for the author of the code. It's for the readers of the code. It's for other engineers who want to master the craft, and learn how to be master craftsmen in the field.
Reinventing the wheel allows us to learn from what other engineers have experienced, and then make their experiences our own. It allows us to understand every decision, why a function was broken down, and why a variable was named as it was.
Reinventing the wheel is the most efficient way for engineers to assimilate knowledge from those who've already walked our paths.
We do this not for any clout, or to please anyone else. We do this for the love of the craft.
So reinvent the wheel, and display it as a trophy. Be proud of the art you've created.
Top comments (13)
I think you raise quite a good point here Adrian, it's drilled into us not to reinvent the wheel, and then beginners are stuck with no projects to take on to show their skills.
Reinvent. Do it your own way, and as Adrian says - display it as a trophy.
If you decide you want to develop your own Linter just for fun, or build a web app that already exists just for the challenge - do it and be proud of your accomplishments!
Glad we're on the same page, Val!
Absolutely! And as an ex-Head Baker, that analogy was very relevant haha!
Existing implementations get outdated. Especially on the web.
Many libraries aim for completeness: too many features, may still lack a feature you need, and not enough minimalism. There is no point to add in features you don't use, and code splitting does not always remove all of the parts you don't use.
I think it is almost always better to write a custom solution fit perfectly for the need and keep your dependencies at a minimum, too. You'll get tons of deps even when you try to avoid them, because there is always stuff that is pointless to make yourself. And you can find minimalistic utilities that do exactly what you need, and do some hard stuff that makes no sense to spend your own time (if you're limited in time as we easily are).
Keeping code focused makes it easier to change it later and you have less to throw away.
I think this is one of the best routes to take for smaller teams. It gets more difficult when you work at scale. Working with proprietary tech increases onboarding time since it's harder to just find engineers who "know how to do the job".
Great points, I totally agree with you!
I also feel that reinventing the wheel makes you appreciate the technology that's out there already. For example, I'm rebuilding my blog and I realized there's a lot that goes into a CMS. I definitely take things like this for granted when it's a one click deploy for a headless CMS.
Good point, Jonathan! I know of bicyclists who tear down their own bikes just to recreate it (exactly the same way) again. It's not just a matter of "what works". Appreciating the craftsmanship that's put into a piece of work is (I would argue) more important!
This is such a cool post. Great advice!
Glad you liked it, Michael!
Ever decided to use someone else's wheel, then spend hours trying to figure out how to put the wheel in?
Sometimes it's just necessary to reinvent the wheel and make it a better wheel.
Exactly. Sometimes the shoe just doesn't fit.
Great post! What do you think is a good Wheel to reinvent ? 😂😂
I work with AI, and one of the most fun I've had is implementing linear regression from scratch!