Agreed, however I think that sometimes the impact to other teams working on a project or product is overlooked when folks refactor. Documentation can be severely affected by refactoring, but there is usually a lot less thought given to that, or how changes should be communicated.

damn it Greg now our eng team is going to send this to me every time then want to refactor code instead of building features

Refactoring rarely leads to career advancement in oh so many companies. People follow the incentive gradients.

When I write code I strive to make it so it never needs to change -- even in the future. I like to design everything Universal and Scalable. My old code libraries have worked unchanged for the past two decades. And is still the foundation of many modern inventions.

One of the keys to w non-changing system is to discover the universal common denominators -- which aren't code or lang but intrinsic to the universe. Once you found that and build with it, things don't change.

Always look for and seek to extract common denominators to everything in order to simplify your work and future compatibility. At which point the problem become software/hardware independent.

The more I've done the more I've come to agree with the John Ousterhout view in Philosophy of Software Design, that focusing deep/large modules with simple interfaces is the appropriate place to focus this energy.

Is it refactoring or is it a hostile takeover