I've had this happen before, and the code review was met with resistance -- ultimately the person on the team least able to design modular architecture was give

I've had this happen before, and the code review was met with resistance -- ultimately the person on the team least able to design modular architecture was given perhaps one of the most critical architectures to design, and it was more difficult because management gave him the task because everybody else was busy with other tasks. It can be difficult. Somes some people aren't meant to be developers, but ultimately you need to foster a good culture of software craftsmanship. If you have the same manager, I'd see about talking to them first about how to approach it. If you don't, you are in trouble. Hopefully, this person wants to learn how to write better code. Now, the opposite is also true, it sucks to be on the other end, and sometimes the person reviewing is on a high-horse and possibly wrong as well. A 400 line function does seem wrong, but just because you're not using someone's favorite Ruby function or not writing all 2-line methods doesn't mean that is wrong either. Code is intensely personal - engineering rigor is required,b but personal style and creativity are vital to enjoying the job as well. This can be very hard in group contexts. Perhaps it would be possible, if you're on good terms with this person, to set up a pair refactoring session where you start to unwind it? I think it's always easier to do things while things are being designed, rather than to do something at review stage, where it more feels like things are being judged. I always like to encourage folks to talk about code as it's being written when I can.