Refactoring A Strange Codebase
Nat Pryce points out an interesting connection to the Dunning-Kruger effect as applied to other peoples’ code. I’ve been burned by it, and tried to learn a little humility, but would be lying if I said I never do it myself now. It’s hard not to stumble across a particularly pernicious part of some miserable module and not want to curse the cruel curs who put you in this predicament.1
But I disagree with Nat that embarking upon a large refactoring in a codebase you’re unfamiliar with is a bad idea. On the contrary, I think it’s a great idea, precisely because in all likelihood you will fail, thoroughly and (to the amusement of your new teammates) spectacularly, and in failing you’ll learn a lot more about the structure of the code than you would have if you’d done nothing but make humble, incremental changes for six months. Also, it’s a great way to build a team rapport with all those developers you just alienated two weeks ago by dumping all over their hard work.
As always, though, try to be good to the people who come after you. In this I differ somewhat with my coworkers; because no codebase is perfect, I think the occasional explanatory comment is a very good idea indeed. The relevant quote comes from John F Woods, although I don’t know the origin: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
1 Too much?