The basics can be considered the root of any concept, that is that multiple concepts grow from this one idea. This is significant because this implies that knowing one idea well could allow for the understanding of multiple concepts downstream. To show this visually I will be creating charts using the app Miro. You can learn more from the article ‘Miro my Hero’.
Perhaps one level down for a good understanding of the root idea, perhaps multiple if you take the time to master it (i.e. If you understand time well, you can probably grasp the concept of a second in time. If you have mastered the concept of time you may even be able to grasp the concept of a minute without first understanding what a second is).
I mention this observation of mine on the basic principles of understanding because I’ve struggled with going in the opposite direction.
A little background about my development story so far. I graduated from the June 2020 cohort at Flatiron School Software Engineering boot camp.
In the actual boot camp, we learned Sinatra and Ruby on Rails both of which are Ruby frameworks.
So, when I no longer had classes, suddenly I was responsible for my own progression. This is where I began to make mistakes. I was under the impression that I must continue forward. Not necessarily learn new languages right away but at least explore different technologies. The flaw with this logic is that all technologies are built upon another. Without first understanding what they are built upon, you will be greatly hindered in your understanding of the new technology itself which hamstrings your ability to progress.
Not knowing what you don’t know is the deep dark hole of technology.
I’m not suggesting that you comb through the source code of React to find all the packages and technologies utilized in the actual framework but if you don’t understand why hooks are useful or using state management, perhaps look into what people did before those things existed would be helpful because, at the end of the day, each abstraction and technology was created to solve a problem or to remove redundancy (the more code, the greater the chance of a bug being created). By utilizing technology without first recognizing the problems it is fixing, you are attempting to solve a problem that doesn’t exist.
Instead of thinking about what you need to add and learn, think about what you can take away and how you can innovate with what you already know.
Identify the roots from which technologies have grown from. Identify the problems those technologies were created to solve. Identify if you have ever run into that problem yourself because if you haven’t, or don’t plan to (scaling isn’t a factor perhaps), then do you really need the solution?
Though, if you are trying to learn, maybe you could create the scenario where you need that solution (replicate the problem).
In any case, this whole article is based on the observations of my own flaws and struggles. And I still struggle to find balance and optimize my own learning habits. It’s been a matter of mental gymnastics trying to convince myself to learn the long and gruesome way and every day I just want to go faster. If you feel the same, know that desire is a good thing because that’s your drive to learn. Keep that fire going by holding fast to learning things the through-and-through.
If anyone has their own methodology or disagrees with mine, I’d greatly appreciate the feedback via LinkedIn or down below. I learn the most from others.
Thanks so much for your time!