Reading Code You Didn't Write
The skill that separates junior and senior developers most clearly has nothing to do with writing code.
Most of the code a working developer touches in a given week was written by someone else, often a while ago, often without much documentation explaining why it works the way it does. Writing new code from a blank file is comparatively rare. Reading unfamiliar code is the constant.
This is why the ability to read a codebase quickly and accurately matters more, day to day, than the ability to write clever code from scratch. It's also a skill almost nobody teaches directly, because it doesn't show up in tutorials — tutorials start from nothing and build forward, which is the opposite of the situation most developers are actually in.
Reading well starts with resisting the urge to understand everything before touching anything. The goal isn't a complete mental model of the codebase. It's a narrow, accurate model of the specific path your change needs to travel through — which components render, which data flows where, and which assumptions the existing code is quietly relying on.
The fastest way to find those assumptions is to look for what would break the code, not what makes it work. Where does this component assume its data always exists. What happens if this list is empty. Code that has been in production for a while usually has already answered these questions somewhere — the job is finding where.
Junior developers often try to prove themselves by writing. Senior developers usually prove themselves first by how quickly and safely they can move through work they didn't write. It's a less visible skill, and a far more valuable one.