At first, programming is just programming. You think of a thing. You make the computer do it. 🎉
After a while, you notice that not all programming is the same. Deja vu sets in. “I’ve done this before.” (Also the basis for patterns.)
Empirical Software Design book series presents a series of these distinctions. (I think of them as “two hats”. Merch opportunity💰.)
Reversible versus irreversible. Some changes are easily reversed. Make these quickly & with confidence. Other changes have consequences for the larger system. Make these only after double checking. Converting irreversible changes (even partly) into reversible changes creates value.
Structure versus behavior. Structure changes are mostly reversible. Behavior changes are likely irreversible (e.g. reporting different answers to tax authorities) & require multiple feedback loops. Separating behavior changes from structure changes creates value.
Safe versus unsafe. Some changes have little to no risk of accidentally changing behavior elsewhere in the system. Converting unsafe changes into a succession of safe changes creates value.
Personal versus team. Some changes, like tidying first, mostly affect folks making those changes. Others, like an API change, affect other programmers. Learning to slice, stage, & socialize externalities creates value.
Changer versus waiter. At a larger scale, some structure changes don’t affect delivery of value to those waiting for features. Others affect non-programmers—”We’re going slow down for a bit while we tidy this mess up.” Converting interruptive changes into a sequence of flow-maintaining changes creates value.
Interface versus implementation. Changes to an interface ripple to all invokers. Changes to an implementation are contained (ideally—see safe versus unsafe above). Only changing one at a time reduces risk, improves flow, and creates more value.
Tidy first versus tidy after (or later, or never). Timing of design changes is as important as the resulting structure. Pay attention to the time value of money & the (often opposing) optionality of the system.
In the point about structure vs. behavior, you close with a statement that might lead some readers down an unintended path: "Separating behavior from structure changes creates value." I can see how some might interpret this as unconditional advice to separate structure from behavior; hopefully that's not the intended advice (most systems don't need to head in the direction of a bunch of structs/DTOs and util functions with no associated state).
I had to re-read that paragraph to understand that you were advising "Separating behavior _changes_ from structure changes creates value." Very different thing to separate the changes than to separate the code elements themselves.