Seems a little arrogant to say most developers don't know how to refactor or do it poorly. Maybe it's true. I really can't say one way or the other because what I see is most devs believe they don't have time to refactor.
Let me ask you - and by "you", I mean everybody reading this - a question.
If you had poor design or refactoring skills, how would you know?
Let's just say you've finished working on some code that involved writing new code. How do you know whether it's well-designed?
Well, you start by using your own sense of what is good design. But all of us can only see the things that we already know about, which us thinking that the code has decent design is only a sign that it is up to our level of understanding. This is a fundamental part of how knowledge works.
Code review can give some additional design feedback, but 1) code reviewers generally don't have time to give in-depth design feedback and 2) "you should redesign this" is generally not well received (see previous point about everybody thinking they are good designers), and I both have to work with my teammates and their comments factor into the kind of review I get. So, code review is not a good way to improve design change, even assuming that you have people on your team who have useful design advice to pass on and you are in the kind of environment that lets you be thoughtful about design.
If you are in a team with decent designers and your team pairs, then you are in luck; you have a good chance to expand your design skills. Leverage this at every opportunity.
Finally, it is possible to spend time (almost always your free time) learning more about design, doing katas, going to code retreats, etc. This also works.
And I'm sorry if this sounds arrogant; I've tried to find other ways of saying it.
Let me ask you - and by "you", I mean everybody reading this - a question.
If you had poor design or refactoring skills, how would you know?
Let's just say you've finished working on some code that involved writing new code. How do you know whether it's well-designed?
Well, you start by using your own sense of what is good design. But all of us can only see the things that we already know about, which us thinking that the code has decent design is only a sign that it is up to our level of understanding. This is a fundamental part of how knowledge works.
Code review can give some additional design feedback, but 1) code reviewers generally don't have time to give in-depth design feedback and 2) "you should redesign this" is generally not well received (see previous point about everybody thinking they are good designers), and I both have to work with my teammates and their comments factor into the kind of review I get. So, code review is not a good way to improve design change, even assuming that you have people on your team who have useful design advice to pass on and you are in the kind of environment that lets you be thoughtful about design.
If you are in a team with decent designers and your team pairs, then you are in luck; you have a good chance to expand your design skills. Leverage this at every opportunity.
Finally, it is possible to spend time (almost always your free time) learning more about design, doing katas, going to code retreats, etc. This also works.
And I'm sorry if this sounds arrogant; I've tried to find other ways of saying it.