> And the point of refactoring is not to indulge one’s interest in fun new coding techniques. Refactoring is a business investment.
The whole post felt repetitive, despite being fairly short. I’m confident you could make it more concise and your point stronger by cutting two thirds or more. Refactoring your words, if you will.
> Refactoring is when you change the design of existing code without changing its behavior.
This is the crux of your point. You know that, because it’s even in bold. What do you want to say after that? Who is this post for? Is it for people who misuse the term? Are you trying to change their behaviour? I’m guessing so, from the title. Then talk to them directly, avoid meandering.
> If we never experiment, we seriously limit our learning. One good way to experiment is with a spike: a small project which is intended from the beginning to be thrown away. I’m also not trying to say that refactorings should never ever contain experiments.
This bit and the surrounding paragraph is a great example. You could cut all of that out and improve your message. None of it is wrong, but it’s also not relevant to the message and looks like you’re backtracking on your previous words.
latexr•1h ago
> (…)
> Refactoring isn’t self-indulgent play. It’s serious business.
> (…)
> And the point of refactoring is not to indulge one’s interest in fun new coding techniques. Refactoring is a business investment.
The whole post felt repetitive, despite being fairly short. I’m confident you could make it more concise and your point stronger by cutting two thirds or more. Refactoring your words, if you will.
> Refactoring is when you change the design of existing code without changing its behavior.
This is the crux of your point. You know that, because it’s even in bold. What do you want to say after that? Who is this post for? Is it for people who misuse the term? Are you trying to change their behaviour? I’m guessing so, from the title. Then talk to them directly, avoid meandering.
> If we never experiment, we seriously limit our learning. One good way to experiment is with a spike: a small project which is intended from the beginning to be thrown away. I’m also not trying to say that refactorings should never ever contain experiments.
This bit and the surrounding paragraph is a great example. You could cut all of that out and improve your message. None of it is wrong, but it’s also not relevant to the message and looks like you’re backtracking on your previous words.