Yes, Simon Richter has the best point. A) take charge AND responsibility. B) make a peer review. See what other programmers would say about his work and time consumption. We've had our share of FAST solutions, where I'm from. Yet the support pipeline hasn't stopped pumping bugs about them. Making code readable is ALWAYS a project MUST. You don't have to make it pristine - just so other people can have a basic orientation in it. This can be evaluated even by a NON programmer if so desired.

Otherwise if you replace a bad coder for any reason, by the time the new guy finds his way around a bad written code you would have lost MONTHS of salaries. Now they are people who just prefer to do stuff their way and thats that. If you are sure your coder is slow just for the sake of PRISTINE code, you can lean on him. Otherwise be very careful what pressure you put, because coding is one of these things that you can save 2 days of work earlier only to waste 3 months later.

Especially when you want a crucial new feature that doesn't fit in any way with the current architecture and you have to recode entire sections of code, that tie in at dozens of places.