> dragging each handle in different directions affected the shape’s position and size in a different way
The cause of the duplication itself is probably wrong: why would you do it in different ways? Treating ovals and rectangles the same way is simpler for the users.
> My boss invited me for a one-on-one chat where they politely asked me to revert my change
No justification given here? Is it because the boss did not give any, or is something omitted?
> Once we learn how to create abstractions, it is tempting to get high on that ability.
People should start forbidding themselves to use that "abstraction" word for anything. That's just code factoring.
> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together
It seems here that this was taken as a hostile overwrite. Nothing to do with "abstractions", "clean code" or factoring.
The problem here is not "building trust", the problem is that they did again something that was already done without discussing the issue they see in it before doing something about it.
This is a methodological, not social, mistake.
> How exactly do they affect the way the code is written and modified?
The usual FUD, the actual trap many people fall in. You cannot predict the future. You should not try to predict the future, that's not your job.
I understand some may be confused by the fact the etymology of "programming" means "write before" or "write ahead of time", but the meaning is that we write what something is going to do; we are not actually writing what will happen for things that are not under our direct control.
> Let clean code guide you. Then let it go.
No. What they call "clean code" is doing the right thing at a specific time. If the requirements change, then do the right thing again. That's called code maintenance.