Maybe to management also.
Abstraction
It’s everywhere: naming, functions, classes, libraries, modules, services and systems.
When we code, we deal with abstractions, encapsulate the complexity, hide the “dragon” into a “box”; identify different abstraction levels then push them up and down; when refactoring messy code, usually due to incorrect abstraction mixed up, we move the “abstraction units” around, using functional or OO patterns to align the abstractions properly, so that when reading code — like reading a newspaper (as uncle bob said).
There could be also the chance we misunderstood it, it could be during the interview.
To management, we deal with teams and processes. unlike coding, abstractions are not visible, but it still there, and when there are missing abstractions (positions), we are dealing with “too much detail”, urgent calls-deadline trouble shootings make us crazy; when multi-level abstractions are mixed up, we get a messy process, then messy code, and then poor product.
Logic chain
As a developer, I believe you had this question chain before: Why is it slow? because memory is not enough -> why is memory not enough? because of memory leaks -> which service leaked memory? the order service -> which class leaked the memory? the X and Y class -> which line? L23 and L394.
