> Based on the OP's description, we're talking about someone who isn't capable of producing quality work. Ehh - I've seen coders who can produce quality work,

> Based on the OP's description, we're talking about someone who isn't capable of producing quality work. Ehh - I've seen coders who can produce quality work, but sometimes choose not to because of (perceived) time pressure or (perceived) lack of value. Their mental model for code generation is to generate crap, then identify the patterns, then refactor until it's not crap - where the last two steps are "optional". Time pressure: A new hire likely feels some pressure to prove they can be productive. Value: New grads may not be in the habit of maintaining code (having written lots of throwaway assignments), not so new programmers may be used to writing throwaway prototypes, or "code ownership" situations where readability by coworkers isn't valued. Heck, it's quite possible they realize their current code is crap, and may even plan to clean it up in a subsequent changelist. I do similar on solo projects & private branches for the sake of keeping 1 changelist ~ 1 change parity, as it makes it easier to figure out refactoring mistakes. That said, those changes should generally be either done before the code review request, or noted as intended followup - and some pushback is warranted.