Member-only story
How Senior Engineers Know When an Abstraction Is Too Early
Experienced engineers do not avoid abstraction. They wait until the code has revealed what is truly shared and what only looks similar for now.
Abstraction is one of the most tempting forms of progress in software development. Two functions look similar, so we extract a helper. Three components share a layout, so we build a reusable component. Several services make related requests, so we place them behind a generic client. The duplicated lines disappear, the codebase looks more organized, and the pull request feels like an improvement rather than a simple feature change.
The problem is that similarity is not always evidence of a stable abstraction. Sometimes two pieces of code look alike because their requirements are still immature. Their real differences have not appeared yet. A shared helper created at that stage does not remove complexity. It quietly predicts which parts of the system will change together.
Senior engineers are usually more cautious with that prediction. They have seen abstractions that began as elegant solutions and slowly became containers for exceptions. A small helper gains a boolean flag. Then it gains a mode. Then one caller needs a callback, another needs custom error…
