Hey newbie, as you learn to code, please re-invent the wheel a lot!

Most software engineers will say: “Don’t re-invent the wheel, it’s a waste of time!”. Yet, they still want to compete favourably on the world stage for high-skill gigs and jobs and get paid and recognized at the highest level. Unfortunately, most (if not all) of us don’t see what’s wrong this line of thinking. I have heard many successful software engineers also say “work smart and not hard”. I agree (in context).

However, you can only work smarter after you have initially worked hard and not before. Why ? Well, simply because you cannot build something on nothing. Hard work is the price you pay to have something to replace the nothing you had earlier. Then, after that, switch to working smart so you can scale the impact of your work (just like simple machines e.g. levers and pulleys scale effort) creating leverage.

Reinventing the wheel is in no way about slaving away endlessly as most people will have you think. It lends credence towards mastery. It can help you learning to organize your thought and better explain your code and communicate to others. It can also help you pick the right analogy when teaching/showing others what you have learnt.

Reaching mastery and re-learning the existing wheel

As a software engineer, contrary to what most will have you believe, the aim of learning continuously is not just knowing and doing alone. The aim of learning is pragmatic mastery. Reinventing the wheel is something you’ll do ever so often (specifically while learning) so as to be able to develop muscle to think through problems by yourself and create solutions instead of relying on other people to do the thinking for you.

A good many engineers i know haven’t reached their full potential because they consistently outsource their thinking and problem-solving efforts to other engineers. Over time, these more capable engineers can opt to build reusable packaged solutions that may or may not be optimal for solving said problems but yet dictate such to others. Eventually, mass adoption and clever marketing take over and this makes people choose a way of solving software problems not from a place of it being inherently better but because it is simply popular.

This can put you at the mercy of other engineers creating a dependency problem. I am not sying don’t ask for help when you need it. But, what if those other engineers are no longer available to aid you at the material time you need them ? What if that open-source project is getting sunset and will no longer work for your use case ? How do you pick the best tool for the job if all you know is the surface stuff and the opinionated manners of operation of frameworks and libraries ?

It’s like thinking that because ReactJS is newer than jQuery, then ReactJS is better 100% of the time (when building web sites/apps for any domain) than jQuery. This is a very inauthentic way to think and reason about technology especially without merit. Reinventing the wheel makes you become a better investigator in determining what the best tool for the job at hand is.

People ask me how i became so knowledgable and have a good grasp on concepts and techniques in software engineering. Well, firstly, i am a curious person who uses my experiences from building things to learn how to get better. Still, beyond curiosity, i strive for mastery. One way i do this is by attempting to reinvent the wheel for learning and discovery purposes. There’s always some takeaway from the exercise that i can use elsewhere at work or on a greenfield project (should the opportunity for such arise).

Also, you need to re-invent the wheel to gain scarcely known insights about specific domains and form mature opinions and practices about technology you make use of consistently. It’s always very obvious when mature opinions have not been formed as a result of lacking experiences or ignorance about experiences of others. If your opinions are as a result of only listening to a lot of senior software developers say: “It depends” as the answer to every question without stating specifically what context “It” depends on. Then, you still have a lot of growing to do.

Learn the rules like a pro so you can break them like an artist.

Lastly, reinventing the wheel helps you re-learn what you have understood about what you are currently learning. You sometimes, need to forget what you have been taught after learning because maybe, just maybe, what you learnt was partially correct. Why is this important you say ? Well, because you become someone who has can use existing knowledge to do things that haven’t been done before in interestingly creative way (like an artist). This increases your value among your mates and contemporaries. This makes you highly sought after in the marketplace. There’s a level you get to where trail-and-error brute force efforts doesn’t help your career anymore.

The #100DaysOfCode challenge which most newbies like yourself engage in is a form of reinventing the wheel for strictly learning purposes and a beautiful one at that. Yet, certain people tell newbies to take shortcuts while doing it. They tell them not to try to figure out the way things work under the hood because most of their job is going to be just assembling third-party open-source packages together and getting paid to do so repeatedly. All this is true by the way in the short term. Still, what is your career going to look like 5–9 years out ? Would you be useful and proactive in building delightful solutions to tricky important problems or would you just be part of an assembly line that only does what its’ told ?

Is reinventing the wheel really all that bad?

The existing wheel and other troubles

Sometimes the existing wheel has many issues. Issues of quality, fit and/or efficiency. Usually, when i hear someone say “don’t roll your own auth”, it seems plausible on the surface but doesn’t speak to motivation and objective. What is the current context, situation and motivation for wanting to create your own ? What are the clear objectives as well ?

If the existing wheel provides no way to customize on a granular level or extend the solution it offers to accommodate other use cases not initially envisaged by the author of said existing wheel, then what do we do ?

Also, what if there’s an exorbitant cost component to adopting the existing wheel ?

The solution to your problem might already exist but not for your use case. Sometimes, we aren’t reinventing (in the true sense of the word). We are only upgrading. Now, there are times when the existing wheel serves as a foundation to doing the upgrade. Other times, it could serve as a distraction.

Trying to come up with an upgrade can help us rethink our approach to solving a problem based off of the assumptions or calculations used in creating the existing wheel.

However, there are people who don’t want a better wheel or a wheel that fits well into their use case. There are people who don’t want to learn more about wheels and what makes them tick and that’s okay. These set of people are fine with using an existing wheel because wheels in general don’t interest or fascinate them. They just want to be done with the task as soon as possible irrespective of the outcome. If you are one of those people then this article isn’t for you.

Ultimately, there’s no argument from anyone against building something better and newer than what currently exists.

Nevertheless, if ever you do decide to roll your own auth, there are a few things to keep in mind

• No wheel is perfect even the one you’ll make
• Have a clear objective or set of objectives why you need to roll your own custom auth.
• You will need help from people who have rolled their own auth before so you don’t repeat their mistakes.
• You should focus on your specific use case or point of improvement, copy everything else from the existing auth which has already been rolled except when you also need to improve something in that area.
• Nobody like complicated things. So make it simpler where you can.
• Educate yourself about any peer-reviewed standard ways of going about this if there are any in the public domain.
• You should have built a lot of throw-away versions of auth to be competent enough to roll your own (it doesn’t work any other way).
• Like everything in life, context is everything. Does the benefit of reinventing outweigh the cost on an economic, technical and operational standpoint ? If No. Then don’t make a new wheel!

With these in mind, it’s going to be easier to create your own auth. It also goes without saying that if you haven’t done it several times before (even if for learning purposes), then it’s a bad idea to try to roll your own auth.

Alternatives to strictly reinventing the wheel

As a beginner, only roll your own auth strictly for learning purposes. Am i saying that reinventing the wheel is the only way to learn. No. There are other ways to learn and grow into mastery. One other way by which i improved myself as a software engineer was via reading the code written by other people, making notes of what i didn’t understand and doing extra research to understand it.

I remember spending long hours reading (and re-reading) the codebase of jQuery back in late 2010 (after learning much of the basics first) to understand how that “wheel” was made. I can tell you that i learn’t a ton. Also, i did build a learning aid (you could call it “reinventing the wheel”) called JollofPHP simply to learn how LaravelPHP was built. I even wrote a post about it.

Another alternative to improving yourself would be to take on projects you are not qualified for repeatedly. Trust me, there’s no better way to challenge yourself to become better than you currently are at software development and coding in general. Lean heavily into what makes you freak out and the prospects that scare the sh!t out of you. It’s the best path towards growth and therefore mastery. Plus, it’s another form of “reinventing the wheel” because hey: there’s really nothing new under the sun right ? Someone else has probably done that before. The only reason why it scares you now is because you haven’t done it at all before and probably have zero context.

I always try to persuade beginners (on my Twitter/X page) whenever i can to forget about buzzwords (DRY, SOLID, Separation of Concerns) and focus squarely on the basics (syntax, logic, stepwise (flowcharting) instructions, error handling, control flow, memory, variables, scope). It’s highly beneficial when you’re starting out. Later you can come back to learning the buzzwords with better context.

Conclusion

Knowing how things really work (under-the-hood) will enable you to trace issues and troubleshoot code easily. The educational and experiential value is immeasurable.

In the real world and in software parlance, there has been many successful cases where the wheel was beautifully reinvented while promoting innovation:

• Multics -> UNIX (operating system)
• AltaVista -> Google (search engine)
• Mercurial -> Git (codebase version control)
• IPv4 -> IPv6 (networking addressing — slow adoption doesn’t mean failure)
• Ingres -> Postgres (database engines)

Finally, you don’t have to be passionate about coding to be a software engineer. You also don’t have to learn how things work (under-the-hood) to succeed as a software engineer. But, if you hope to grow in this career and become a very senior position at a software company paying you lots of money as an extremely valuable engineer, you have to sooner than later.

Don’t be allergic to reinventing the wheel when it makes absolute sense to do so. Nothing can teach you what getting your hands really muddy will.