Separation of Concerns is another name for organizing things well. This takes practice. But there is a natural feedback loop. Code that is not well organized can fall into two extremes: hard to change or hard to use.
When you have mixed different concerns, code becomes hard to change. You might find yourself making extra changes which are unrelated to the actual reason you wanted to change the code in the first place. Or you can hardly change code because the risk of breakage is too high. Both of these also overlap with failing to follow Single Responsibility Principle.
When you divide a single concern into too many pieces, it may not be hard to change, but it will be hard it use. It will feel like there is too much overhead or it is too awkward for the pieces to work together. This can also apply at the higher levels than just code. Overly divided up libraries/packages can cause dependency/discoverability mazes. Overly divided services can lead to an explosion of failure modes and untraceable code paths.
A perfect separation of concerns may not be possible in all cases. It is not an exact science, but more of a judgement call. This is why it requires practice. I always say if the solution feels awkward, there is probably a better way. Lean into the instinct that "something isn't right" and try to find out what it is.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Separation of Concerns is another name for organizing things well. This takes practice. But there is a natural feedback loop. Code that is not well organized can fall into two extremes: hard to change or hard to use.
When you have mixed different concerns, code becomes hard to change. You might find yourself making extra changes which are unrelated to the actual reason you wanted to change the code in the first place. Or you can hardly change code because the risk of breakage is too high. Both of these also overlap with failing to follow Single Responsibility Principle.
When you divide a single concern into too many pieces, it may not be hard to change, but it will be hard it use. It will feel like there is too much overhead or it is too awkward for the pieces to work together. This can also apply at the higher levels than just code. Overly divided up libraries/packages can cause dependency/discoverability mazes. Overly divided services can lead to an explosion of failure modes and untraceable code paths.
A perfect separation of concerns may not be possible in all cases. It is not an exact science, but more of a judgement call. This is why it requires practice. I always say if the solution feels awkward, there is probably a better way. Lean into the instinct that "something isn't right" and try to find out what it is.