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.
Top comments (6)
This is a wonderful idea for learning languages, frameworks, and any/all of the fundamentals. However, I think the process of black-boxing is still incredibly useful, as long as you use it correctly. As you said, sometimes it's good to reinvent the wheel. But at the same time, you can't know everything, so you have to find a way to, at the very least, comprehend those other concepts.
I absolutely agree. The black-boxing (abstracting behavior) of things is what programming is all about. My goal with this post is just to bring attention to the fact that the underlying experience of programming brings so much intuition and power to the developer if he invests in the basics, not just the high-level tools. Both developers will achieve the goal - but the one that has the basics covered will use their tools better. :)
This is something that I have started to notice. A few decades ago, software engineers didn't really have abstractions that we have today so they learnt how the systems worked under the hood. We developers have it easy nowadays.
I have recently started learning the internals of how Rails framework works and it's internals. I don't understand half of it but what I understand is just beautiful. I hope more people will try to learn the interns of their favourite libraries/frameworks and try to implement even a small feature of it on their own
i totally agree with your post. Nowadays, Many modern developers including popped out from boot-camp, to get a job easily, just made abundant projects without fully understading how they worked. And when faced with technical interview, they didn't explain the process of their projects due to the lack of deep-comprehension.
So this is my conclusion: make a project one-by-one with fully understanding.
This. So much this.
A frightening number of new developers I interview are - to my mind - worryingly incompetent (for want of a better word). They have a convenience culture mentality of programming where they just want to do 'cool stuff' as fast possible (to get 'likes'), without having any real understanding of how the stuff they've built with 'off the shelf' components actually works.
This really needs to be addressed... I think it is a big problem for our industry.
Learning fast is great