It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something.
So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes.
But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code.
My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc.
I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.
I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.
This has been my experience too. It's also common (maybe even nearly universal) for devs to go thru a stage where "rewiting" feels like the path of least resistance. This is usually (not always) wrong, but until you've ramped up in several very different codebases it's difficult to see how something so foreign can end up being as productive as what you're used to.