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💰.)
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.
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.