I'm still new to software development, and I find it difficult to follow code that is split across many functions and modules. For example, I might see `const result = await createOrder(data);`, then have to open another file to find `createOrder()`, which may call several more functions elsewhere.
I understand the benefits of separation of concerns, small functions, and modular design, but sometimes I feel that related logic would be easier to understand if it were kept together. Is navigating between files simply something that becomes easier with experience? How do experienced developers decide when to follow a function into its implementation, and when to treat it as a black box? Can code be over-abstracted?
4 Answers
Some abstraction is useful, but code can definitely be over-abstracted. A function should represent a meaningful concept, hide complexity that callers shouldn't need to care about, or be reused in multiple places. Splitting code into several tiny wrappers that merely pass the same arguments along can make the program harder to understand without providing much benefit. If one simple behavior requires opening many layers just to discover what it does, the design may be too indirect.
Yes, jumping between definitions and references is a normal part of working in a real codebase, including for experienced developers. Use your editor's navigation features—such as Go to Definition, Find All References, and the back-navigation shortcut—so you can move through the call chain without manually searching for files. After a while, it becomes muscle memory. Good naming and clear types also reduce how often you need to inspect the implementation.
In VS Code, F12 or Ctrl-click opens a definition, and Alt+Left takes you back. Those shortcuts make tracing code much less frustrating.
Navigation history, bookmarks, split panes, and good type information are especially useful when you need to compare several files at once.
You usually don't need to understand every function all the way down. If `createOrder` has a clear name, sensible parameters, and a known return type, treat it as a black box until something requires more detail. Focus first on what goes into the function and what comes out. Drill into the implementation when you're debugging, checking validation or side effects, learning an unfamiliar domain, or trying to reuse it correctly.
The goal changes how you read. For a quick feature change, follow the relevant path and stop at trustworthy boundaries. For debugging or deep learning, trace the whole chain.
Names, types, and documentation are what make abstraction work. A line like `const order = await createOrder(data)` communicates far more than `const result = ...`; the return type can tell you whether it is an order, status, or something else. Function documentation should explain purpose, inputs, outputs, errors, and important side effects. Comments are most valuable when they explain why a non-obvious decision exists, rather than repeating what the code already says. When exploring an unfamiliar system, start at an entry point, follow the data through the relevant path, and keep notes instead of trying to hold the entire codebase in your head.
Good organization doesn't necessarily eliminate navigation, but it should make each jump meaningful. Related code that is always understood and changed together may belong closer together.