I started programming around age 16 and am now 21. While setting up an Angular project, I realized how many basic concepts I only understand superficially. I recently had to look up what development dependencies are and how npx runs locally installed packages. I know an API allows applications to exchange data, but I cannot explain much about how APIs work internally. I also struggle to clearly define terms like runtime, package, library, and framework.
I often feel tempted to investigate every unfamiliar concept in depth, but that quickly becomes overwhelming. Seeing frontend learning roadmaps makes the knowledge gap look even larger. I worry that I wasted time and should already understand these fundamentals, especially when I see people my age building impressive projects or quickly adapting to unfamiliar technologies.
How should I decide what to learn and how deeply to learn it while focusing on a particular area? Should I first build projects and study concepts as they become relevant, or spend time strengthening broader computer science and programming fundamentals?
5 Answers
Keep building things. Pick a project that genuinely interests you, learn the concepts needed for the next feature, and occasionally study a structured fundamentals course or book. You can go deeper with languages such as C, basic computer architecture, networking, or operating systems if those topics interest you, but do not treat every possible subject as a prerequisite for becoming competent.
There is no universal pace, and you will forget some of what you learn. That is normal. Repeatedly solving real problems is what turns scattered facts into working intuition.
The fact that you discovered several gaps and then learned what those terms mean is evidence that you are learning, not evidence that you are incapable. Strong programmers still encounter unfamiliar tools and concepts constantly. They become effective by having enough fundamentals to ask good questions, testing their assumptions, and knowing when to consult documentation.
It may help to spend some time on computer science fundamentals alongside your projects. Learn data structures and algorithms, operating-system and networking basics, how programs run on a computer, and how software is designed and tested. You do not need to master all of it before building frontend applications, but a solid foundation makes higher-level tools easier to reason about.
You could also create a small application without a major framework or package ecosystem, then gradually add those layers. That makes the roles of libraries, packages, runtimes, build tools, and frameworks much less abstract.
Research is not a sign that you are inexperienced. Every developer I have worked with begins unfamiliar tasks by investigating the requirements, tools, and possible approaches. Programming is largely the ability to find, understand, and apply information effectively.
You should know enough fundamentals to form a reasonable plan, but you are not expected to memorize every API, framework detail, or implementation. The goal is not instant knowledge of everything; it is becoming comfortable figuring out what you do not know.
A good developer may look fast from the outside because they know how to narrow the problem and search efficiently, not because they have every detail stored in memory.
You do not need to understand every layer before using a technology. A useful rule is to learn roughly one abstraction layer deeper than the thing you are working with, so it does not feel completely magical. When starting a project, you should be able to break the task into steps, even if some individual steps require research or documentation.
Focus on the next problem instead of the enormous list of things you might eventually learn. Build projects, look things up, and revisit concepts when they become relevant. Regret and comparison will not improve your skills; consistent practice will.
That makes sense. I tend to compare programming to competitive hobbies like chess, where measuring yourself against others is constant. I also notice that returning to something after a break is easier than starting from zero, so the earlier effort was not completely lost.
I had assumed data structures and algorithms were mostly interview material, but understanding how the computer works underneath the frameworks sounds like a useful way to connect the concepts.