I had a co-pm that was big into refactoring code. I think he is still re-factoring that engine instead of making money.
If you can avoid refactoring, it's better, until you gain substantial value, for the job and possible new flaws (risk). Dilligent refactoring of needed/valuable functionality and bugfixes, can on the other hand increase your code quality and usefulness, since it's been through many iterations of different usages in different settings. Such "trusted code", can become more valuable by such usage and evolve into better systems over time, provided there's investment in its growth, a "gardener" interested in keeping it tidy without sacrificing new/better features.
All general of course, and not something one readily sees in their first 10 years of programming experience, or without clear goals in mind that trumps programming fun
. A bit crude but: one either spends time building perfect libraries, or spend the time building and researching stuff that provide some actual results and new understanding. You can spend so much time on one library, and then you don't need it anymore, or need it very differently.I agree interfaces can help mitigate much of code cruft, though wouldn't want to structure a trading engineso until I got more specs / concrete requirements, and when I'd need to implement from such. Often in school we get served distilled knowledge, but wisdom is from own experience of trying and failing.
