Qualquer resposta direta será extrema. Claramente há casos em que o prazo é tão apertado que você deve usar um código feio, e há casos em que o código é tão feio que vale a pena perder o prazo para melhorá-lo. O que você precisa é métodos para julgar em que você está, e talvez métodos para estabelecer prazos realistas que permitam tempo para escrever um código melhor.
Não salve a limpeza para mais tarde. A menos que você habitualmente tenha períodos sem nada para fazer além de refatorar, não há "mais tarde" em que de alguma forma ele terá maior prioridade para arrumar o código do que é agora. A rotina é "vermelho, verde, refatorar", não "vermelho, verde, fazer algo completamente diferente por duas semanas, refatorar". Realisticamente, você não mudará o código até a próxima vez que estiver revisitando-o por algum outro motivo, e provavelmente estará em um prazo final também. Suas opções reais são para corrigi-lo agora ou deixá-lo.
É claro que um código bem estilizado é melhor do que um código com estilo ruim, supondo que você planeje lê-lo novamente. Se você planeja nunca mais lê-lo, então não arrume-o . Envie a primeira coisa que passa nos testes. Mas esse é um cenário bastante raro, para a maioria dos programadores isso acontece aproximadamente nunca. Ignorando esse caso, só você tem os detalhes do seu caso real para julgar quanto custa consertar versus quanto custa (em manutenção futura aumentada) não consertá-lo.
Há certas coisas que não são mais difíceis de corrigir no momento em que o código requer manutenção, do que devem ser corrigidas agora. Estes não beneficiam muito você para consertar agora. Os mais óbvios são triviais para corrigir (erros de espaço em branco e afins) e por isso é difícil imaginar que você tenha tempo para fazer essa pergunta, mas não para corrigi-los ;-) Para aqueles que não são triviais e são desse tipo, então OK , você tem algum código que não é ideal, mas você deve ser pragmático. Funciona e você está em um prazo. Use-o.
Existem certas coisas que são consideravelmente mais fáceis de consertar agora do que serão mais tarde quando (a) elas não são tão novas na mente de todos; (b) outras coisas foram escritas que confiam nelas ou as imitam. Estes são muito mais valiosos para corrigir agora, então priorize-os. Se você não tem tempo nos prazos para consertá-los, então precisa pressionar o máximo possível por prazos mais longos, porque está acumulando dívidas na sua base de códigos que provavelmente terá que pagar na próxima vez que visitar o código.
O método preferido para corrigir o código é através de um processo de revisão. Comente sobre os problemas que você tem com ele, e envie de volta para o júnior para mudar . Você pode dar exemplos do que você quer dizer e deixar o júnior para encontrar todos os casos no código ao qual eles se aplicam, mas não apenas terminar o código deles. Se você fizer isso, você não lhes dará nenhum meio de melhorar.
Você deve escrever problemas comuns em um guia de estilo que diz "não faça isso, faça isso" e explica por quê. Em última análise, a razão é permitida, "para tornar nosso código esteticamente consistente", mas se você não estiver preparado para anotar suas regras com alguma justificativa, então provavelmente não deve aplicá-las ou. Apenas deixe cada programador livre para escolher.
Finalmente, tenha cuidado com a tendência de ajustar coisas indefinidamente. Os retornos diminuem e você precisa aprender através da experiência, onde eles ainda são bons. É absolutamente essencial que você formule uma ideia realista do que é bom o suficiente, ou então você não pode ter essa negociação na qual você garante que seus prazos lhe darão tempo para criar um código "bom o suficiente". Gaste seu tempo em coisas que não são boas o suficiente.