I'm a beginner learning web development, with some previous experience in Java, and I'm struggling with how much tutorials leave unexplained. I'm currently following a Jakarta EE tutorial where the instructor has me install Java, set up Tomcat, add dependencies, configure files, and start writing code. The example works, but I often don't understand what each part is doing or why it is necessary.
For instance, I want to understand how Tomcat turns my computer into a server, what dependencies and build tools actually do, where annotations and configuration files fit in, and where methods such as req.getParameter() come from. Instead, tutorials often say to install something and continue, which sends me searching through documentation and explanations that I may not fully understand yet.
I frequently pause to investigate these assumptions and end up in long rabbit holes. It makes me wonder whether this is a normal part of learning, whether my fundamentals are weak, or whether beginner tutorials simply assume too much. Should I stop and fully learn every unfamiliar concept before continuing, or keep moving and return to those topics later? What fundamentals and learning structure would help me build a stronger foundation without getting stuck in tutorial hell?
4 Answers
This is completely normal, and being curious about why things work is a strength. There is far too much software knowledge for anyone to understand every library, package, or method in advance. Even experienced developers regularly look up unfamiliar APIs and examples.
A useful approach is to keep a list of things you don’t understand, continue until you have more context, and then revisit the important items. Tomcat often makes more sense after you have seen it receive a request and serve a page. You do not need to understand every internal layer before writing your first working program.
Tutorials often skip explanations to stay short and approachable, but copying commands without experimenting will not teach you much. After an example works, change it: remove a dependency, alter a configuration value, inspect the request, change the input, or deliberately break the program and repair it.
Use the tutorial as a starting outline rather than a script. Read the documentation for the specific method or component you are using, write small experiments, and try rebuilding the example without looking. You learn programming primarily by writing, testing, and debugging code—not by watching someone else write it.
So if you were starting again, would you follow the tutorial while making small experiments, then study the concepts that still feel unclear?
Think of a tutorial as teaching you how to drive, not how to manufacture the entire car. You need a basic idea of what the engine and controls do, but you do not need to understand every part of the transmission before going anywhere.
Learn enough about a tool to use it safely and understand its role, then move on. Set aside deeper exploration for later unless it is directly blocking you. Trying to master every prerequisite before starting can prevent you from gaining the practical context that makes the theory easier to understand.
That helps, but I still want to understand the role of the engine. I don’t need to build the whole car, but I do need more than instructions to install it.
The main danger is not looking things up; it is spending so long researching that you never finish anything. For a personal learning project, give yourself permission to explore, but set a time limit for each rabbit hole. If the missing detail is not preventing progress, make a note and continue. If it affects your understanding or causes an error, investigate it immediately.
Work through a structured fundamentals course or book alongside small projects. Focus first on Java syntax and object-oriented programming, collections, exceptions, files, HTTP basics, and how a web request and response work. Then return to frameworks such as Jakarta EE and learn what Tomcat, dependencies, annotations, and configuration contribute to that process. Finishing several modest projects will give those explanations useful context.
My biggest fear is building knowledge on top of gaps. It sounds like keeping notes and revisiting important gaps is better than stopping every few minutes.
Did you learn most of those concepts through building projects?