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.
Oldest comments (11)
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
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. :)
Totally agree. I mean, going deeper is a good thing to do. Still, I think the black box idea should go first. Since you are taking time to learn, go black-boxing rather than go deeper. Seeing things not working or struggling with something may be frustrating sometimes.
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
It is a very insightful post! After all, it is all about the developers' mentality in learning. I came across few people, one is a self-claimed backend developer and a young chap who just learnt about shopify in 1-2 years experience. Self-claimed backend developer just sticked with Hugo static web generator and refused to learn more about the latest technology(other frameworks, cms etc) and more on html, css and javascript further.
Another young chap who worked as a marketing executive and had 1-2 years experience in setting up shopify, fired his boss and thought he knew it all.
"Stay hungry, Stay Foolish" will be a good learning mentality as always. Like Oscar said, no one will know everything, at the very least, comprehend those other concepts. And also, there has always been new frameworks and technology to keep up with.
It will be great if developers in dev.to community can work synergistically on game-changing projects and make impactful breakthroughs with our skillsets.
Very nice article I have got it at the right time, but I think it's also very important to know when you should re-invent the wheel and when not to, cause it's not good for business, time efficiency and can hinder progress, but at the other hand it's very rewarding and it can get you like a virus and you start wanting to re-invent everything or am talking about the curse of curiosity if you like, here is my joruney in brief:
wherever possible don't attempt digging into why and how a wheel works or how it was made, it's a very death reckoning journey, I wanted to make react context better by making it a full blown state management library, guess what I found 🤦♂️🤦♂️🤦♂️ 3 months upto date am still researching the topic, near everyday and it has quite helped, cause over this weekend I was able to roll out state management in this framework am making using plain js, thanks to my digging into how react does it, so you can try to look through and also give some feedback: github.com/javaScriptKampala/z-js/... but back to this,
yes if I knew what I was getting into, I wouldn't have started, it turns out state management is one of the hardest things in react, I think if react ever makes it inbuilt it will become the most powerful framework of all time but now it's a library and they too know it's a hard topic that's why we have these third party libraries like redux to tap it, and in my workings, at some point I just ended up re-inventing some existing libraries and cross checking to find they work exactly as what I had got to, and then I iterate and like that, it was a terrible idea to start with, though rewarding,but in all I want to make a global useState hook for react thus even whatever existing is not enough, this is what am working again to solve state management in react but github.com/javaScriptKampala/react...! 😂 but know when to re-invent the wheel.
You should always re-invent the wheel when learning something new. Your comment only applies to people who already know the tech in question.
I did my first course ever two years ago. HTML and CSS. And JS was my first programming language ever (and it still is). In these past couple of years, after making so many mistakes -and keep making them of course, but we are friends now), and going through courses, Udemy, Full Stack Web Development Bootcamps, and many different books; after CRA and thinking ok, it's enough, I'll learn Webpack, I think -it's just my humble personal opinion-, that too many abstractions when you are just beggining, well, does not work. I mean, and I'll give three silly examples: 1. If I am asked if is it possible to build a constructor function in JS using arrow functions and I'm not sure, or can't give proper arguments for my response, I would wait until I begin to learn whatever JS library or framework is around. It might not be wise to put another layer of abstraction over a layer of abstraction that I don't really get.
If I use too many divs or spans in my code well, I would start all over again.
If I can not replicate the layout of an average web app with pure CSS, I would not bother myself with Tailwind, BootStrap, Chakra, Material...
I really think this is basic stuff.
I won't talk about backend until until I learn why and how (and learn is being able to explain it to others), async/await are just promises with restrictions, until I get CORS, and the Internet Protocol Suite. And of course write some proper SQL without an ORM.