The job of a software developer can be summarized into two words: constantly evolving. Anti-static. The nature of software demands it since modern programs, apps, and websites require us to use a plethora of abstraction layers and tools that we can't always know how they really work. Each tool or layer we bring into our environment abstracts some part of the development process behind its API that we will then use. This is a normal process with the fantastic benefit of enabling the developer to create complex, stable, and beautiful applications and tools that would otherwise require whole teams of experts just a couple of years ago to construct. This phenomenon has a downside that we must be aware of, especially in the modern web world. So many processes and behaviors get abstracted that we begin to learn the APIs of those tools, not the programming itself.
Most of the newcomers to the world of software development begin their journey in the web world. The beginnings are rough and hard, and the front end is a great starting point since it provides visual feedback and is the most rewarding part for most people. After spending the humble beginning writing calculators, managing arrays with loops, or handling input and output to the console, the ability to create websites so quickly feels ground-breaking. Naturally, this progress leads a new developer to the UI libraries and frameworks of the modern day: React, Angular, and such.
We tend to forget how amazing these tools are and just how much they speed development up. A decent React developer can easily take a Figma design file and recreate the UI and interactivity without breaking a sweat. They help us handle the UI, updating state, routing, and more, and they introduce their APIs to do so. In a rush to get a job and start earning money, this makes new, fresh, and inexperienced developers rush to these tools, sparking the numerous "What is the best frontend framework to learn" debates.
This has the often forgotten consequence of new developers learning frameworks, not programming itself. They learn the APIs of their tools and how to use them, get a job, and then struggle to keep up with the more complex codebases. Writing UIs and connecting them with backends usually works well, but problems arise when the apps get complicated to the point where custom state management practices are required, reducing the number of requests to the backend should be tackled, or decoupling of the presentation layer from the other code needs to be done, or even rewriting the UI from one library to another. This inevitably brings challenges to the developer, where a clear lack of competence gets shown and the developer struggles to keep up. The pace of modern development doesn't help, making it hard to, between a full-time job and other parts of life, find enough time and energy to try to work on one's personal projects. It is my own opinion that most fresh developers struggle with this, myself included. It's a balancing act all of us need to manage.
Software is not easy, and between college and Udemy tutorials there is a lot of sweat, failed projects, and keystrokes needed to grasp the concepts and get stuff done. This brings me to the title of this post: reinvent the wheel. I constantly hear the advice "Stop going through tutorials, think of an idea, and start working on it", which is the best way to learn in my opinion. But there is an addition I'd like to recommend - start reinventing the wheel, which will further deepen your understanding of your codebase.
Maybe you're using the RxJs library to aid with state management in your front-end project. It's quite a complex library and takes some brain power to grasp the concepts and start using it well. Why not try and recreate its reactive primitives? It's easier than it seems, and the new-found intuition and understanding will reshape your thinking about RxJs. It's incredible how much this practice changes your perspective. They don't say "To fix it, you first need to know how it works" with no reason. Maybe you use Express for writing backend apps in Node. Have you ever wondered how the routes work? What's happening underneath the pretty syntax?
With the power of understanding the hidden layers comes the benefit of making fewer bugs, quicker debugging, and even the ability to modify some behavior otherwise inaccessible. If one has the time, I strongly recommend to try and tackle an unknown variable in your toolset, and by recreating just the most basic parts of it, you may come out a stronger engineer on the other side.