As developers, especially when we learn, we’re often told to “not reinvent the wheel”. Believing that it almost always stems from a good intention, let’s understand what it means… and why you shouldn’t lose too much sleep over this sentence, and whatever it implies.

Why the wheel? Who invented the wheel? And who cares who did?

This expression is relatively recent in English, it seems, and although it has traveled far and wide, especially in the world of new technology, its implications remain quite obvious no matter how it’s phrased: “don’t do something that was obviously done before you, by someone smarter than you”.

You see, the focus here should be the wheel. We use a rather basic principle to state that “what was done doesn’t necessarily need to be done again”. The wheel is “perfect” as is and doesn’t need you (or pretty much anyone else) to get better.

The problem with this picture is that not much in our lifves is a wheel, something obvious and clear and, most importantly, stated in time with a beginning and an end that will never, ever be put into questions. And if you think about it, this principle is fairly against human nature too: if the human race has improved, it’s not because we were afraid to invent… or reinvent. Even basis things. Even things we thought were true.

So who invented the wheel? Well, it wasn’t me, for one thing. Beyond that, I can’t tell for sure. It’s true that inventions usually have a date and a name on each of them. But when we dive deeper, things often turn more complicated. Someone had the idea, someone else made it true. Or, say, someone had an idea, talked to someone else who talked to someone who made it happen. Or yet again: someone had the idea, made it true, and sold the idea, if ideas can be sold, so that someone else’s name is on the idea now.

Ideas. A fascinating topic that has cost much ink in the past, and will probably do so again in the future. Who are idea owners anyway? Can someone say that no one else had a given idea before? It’s true that, when I try something, I like to think no one else thought about it before. It’s gratifying to invent something. Which brings us back to the wheel… and why you shouldn’t be afraid to reinvent it.

The problem with the wheel… I mean the expression

The wheel is fine. Thanks for asking. In fact it has been around for a long time and it keeps on chugging. Wheeling around. Sometimes fast, sometimes slow, sometimes with companions, sometimes alone. People imagined ways for it to effectively bounce too, can you imagine? No, really, I saw something about it. Whoever invented the wheel may have anticipated some usage of it, but did he think about training wheels? And training wheels are a fantastic invention!

Why, let’s remain serious five minutes. The point is, this comparison to “reinventing the wheel” is pretty flawed as it is. And I’m not just talking about the expression. It would seem ridiculous to reinvent the wheel, after all. And yet, does it really? People have built on the concept of the wheel for a long time. True, they have built on it, not necessarily changed it, but none of them were particularly afraid to invent, or reinvent. In fact you may remember some of them, in part because they did invent something. We don’t often scoff at inventors, at least in our so-called modern world.

But most importantly, project ideas aren’t like the wheel. Most projects are being born out of ideas. They’re not perfect. They can be improved. But without ideas, without invention, there would be no new thing to try. And whatever else, I find it pretty sad to consider.

Developers have a huge advantage which often is overrated: ideas we have can turn into projects pretty quickly. As developers, we don’t often need billions of dollars or other currencies to start something. Ideas are cheap, perhaps, but our projects are quite cheap too. We don’t often begin our project life by a thorough, 80-page market analysis. We just think of something and fire our text editor and start working, a day, a week, a month, a year, a decade… but still working. I often believe the world wouldn’t be such a bad place if ideas had more leverage, if we could create something as easily as developers can start a new project. Tons of ideas were never started because whoever thought of the initial idea didn’t have the time, or the money, or the cooperation of banks and inventors or lawyers. Yet, where these ideas bad? Some people believe this is a natural filter: we cannot allow every idea to be a new invention, otherwise the world will be crowded with junk. Ho… wait… it kind of is. Well, that’s a valid point, but I’m still ready to argue a lot of people with great ideas couldn’t even contribute to society, to the world at large, out of lack of resources. And I would argue this is a loss.

The wheel and the developer

Let’s imagine a developer has an idea of a new project. What then? This developer might not be experienced enough to do it all alone, and she’s certainly not aware of everything that has been done by others (are any of us?), but she has the idea and the motivation. So she starts a project and spends some time in her text editor, writing code, testing, muttering in dismay or clapping in excitement, depending on the project stage.

What will she write? New code. Code that works for her. If the code doesn’t work she’ll try to learn something about why it doesn’t work.

Now a more advanced developer would tell her: “but why do you try to reinvent the wheel? What you want to do has been done a long time ago”. If she has some regard for the advise, she’ll drop the part of the project that doesn’t work and will look up what has been done and seek to use solutions from others. She will come out of this experience believing “someone else did something better than I could”, and possibly “next time I will not create without looking at what exists”.

Both statements are wrong. Yes, others have written a lot of code before, and it’s quite possible to find code that did what she was trying to do. But it’s not true these people did it right, whereas she did it wrong. The truth is that her own idea about a portion of her project died there and she made the choice to use another solution. This solution might be more performant, have less bugs. But it’s not hers. She will build the belief that the way to create great projects out there is to avoid doing, let somebody else do it.

If everyone thought that way, I guarantee you computer sciences wouldn’t be at the level they are today. I guarantee you a lot of things that have been invented, software or hardware, wouldn’t have been. Using existing solutions has its cost too, and while we shouldn’t dismiss what was done before, we should at least think of it as a balance. This balance is even more important while learning. So let’s focus on both aspects.

Existing solutions may not be that bad

Experienced developers usually admit that one key to becoming a good developer is to “know when to use what exists” and “when to do it yourself”. In other word: these developers aren’t afraid of reinventing the wheel. They just don’t do it all the time. Let’s first focus on using existing solutions: why it may be a good idea… but why it may not be.

• What has been done OFTEN is more performant and more stable: an existing solution might run faster, possibly doing a better job. If the existing solution exactly matches what you want, it’s always worth considering using it, keeping in mind the other points.
• What has been done seldom aligns with what we want to do: a developer with a new idea doesn’t often find useful things in an existing project. I remember hours spent on a new project that seemed to do what I wanted, so I read the documentation and run some tests, before realizing it didn’t do what I wanted. If I had started right away coding what I wanted, these few hours would have been employed toward a more productive goal.
• What has been done can be used, with some time and effort: don’t think using what exists is a completely effortless job, or that it doesn’t require any time at all. If nothing else, you might need some time to scroll the documentation (if there’s any) or the source code (if there’s none). Not only is this frustrating (you’re not working on your idea, you’re trying to integrate someone else’s idea and understand it), it can take more time than would have been necessary to code it yourself.

So yes, using what exists can be a good thing, but it certainly can be a bad thing. And keep in mind: the projects you want to add did exist, because someone thought of inventing it. Don’t sell yourself short and write your own ideas off.

Inventing your solution may not be that great

But there are reasons why inventing your own solutions can also be complicated. Let’s see several reasons why to invent… and why not to:

• An inventor is more in control: while it may take you several minutes or hours (or days, yes!) to understand someone else’s solution, what you will create is more aligned with what you want, and you won’t need so much time reading and learning. At least, not from another project.
• An inventor spends time and efforts on her ideas: while integrating existing solutions can take time and efforts, writing your own may take time and efforts too. Which would be greater? This is a hard decision and sometimes, you would need to test both ways at the same time, or in quick succession. Don’t be afraid of doing that. Sometimes, there’s no other way.
• An inventor may not know, or understand, the topic of her work: that is fine, in my opinion. Beginners often spend a lot of time learning, and it’s less frustrating to learn about a topic than learn from others’ codes. Of course, there’s the moment when you need something and don’t want to learn how it works. In this case, it’s definitely better to use something that has been done by someone else.

To do or not to do, what to choose?

I’ve read a lot of beginner books and often come across this “don’t reinvent the wheel” sentence. I almost always find tips about how to use others’ solutions and code faster. But I don’t always see a real rational for doing that instead of inventing, so here’s a very basic one.

Focus on your interests

The first question you should ask yourself is: how am I interested with this feature?

Say you want to create a basic music player, because you’re not happy about what already exists. Such is the privilege of developers. They can begin a new project just because.

But are you interested in every detail of sampling, sound rates, sound encoding? Or do you just want to focus on the user interface (because you found something really great) and let someone else read the music files for you?

When starting a new project, it’s not useless to state what you’re interested in. It can be something you know how to do (I’m quite familiar with pyQt, say, and that’s what I’ll use) or something you want to learn (I’m not familiar with the way to handle user options, but I would like to learn). These interests may be a bit closer to “do-it-yourself” than “let-someone-else-do-it-for-you”. But that’s not the last question to ask. Don’t place the ideas that interest you under “things to invent” quite yet, just move them closer to this column and let’s go on to the second question.

Try to consider time and efforts

This one is a bit more tricky. As explained above, using something that exists and writing your own solution both consume time and other resources. While a new developer will not know how to assign time to each feature of her new project, an advanced developer might not have much better luck. Advanced developers have the advantage of knowing SOME solutions, so they can tell you, for instance, creating a user interface might take them 3 hours, but writing the very graphical library would take them years. In this case, it’s quite obvious what to choose.

Again there’s a catch here though: if you’re motivated by the project feature, it might be a good idea to do it yourself. If you think it will take you weeks to do it, but that you really want to learn it, consider doing it. Others will say that’s a waste of time, but you should know better now. And who can tell what the world will lose if you don’t do it?

What’s that? No, you don’t need to be self-centered to be a developer. You should just be able to not feel meaningless either. Another balance.

Speaking of which…

Keep in mind the destination of your project

It is not infrequent for developers to change focus in the project life. One would create something, expecting to be only useful for himself, and then others will come and see what has been done and say it perfectly aligns with what they want, can they use it? It is not your task to imagine what your project will be in 10 years, but it’s worth pondering over its usefulness to others. And this would affect what you decide.

A project that is seemingly useful to others might focus more on performance, testing and stability. Such things USUALLY are found on existing projects. Keep in mind some of them have had years to develop. Don’t dismiss your own ideas too quickly, but don’t dismiss others’ ideas too easily either.

On the other hand, a project that you create just for yourself, or that will help you learn, is definitely more aligned with a “do-it-yourself” approach than a “use-what-exists” approach.

Conclusion

Okay, did you write a table on a blank piece of paper, write down all your ideas and sort them in “do-it-yourself” or “use-what-exists” column? Well, I hope you took notes anyway. The question of reinventing the wheel has its pernicious side-effects, so to speak. One of the most worrisome ones I often see in the world of student developers is that conviction that their idea is either worthless or of no consequence. Fortunately most of us align with a broader understanding of our own approach, but let’s not discourage learners too much either. What they try to do might alter your opinion of a 20-year-old library you thought was pretty much the wheel of developing, something too obvious to be put into questions.