Tendo trabalhado em locais com revisões de código e outras sem, tornou-se um dos meus problemas de improviso ao procurar novos empregos. O tempo que você economiza evitando emergências, porque os problemas não surgiram até que você produzisse, é muito maior do que o tempo gasto na revisão de código. E isso não menciona o quão menos estressante é encontrar um problema na revisão de código.
Você pode começar pequeno se a equipe precisar convencer. Como você deseja que seu código seja analisado, comece por aí. Peça a um ou mais de seus colegas que se encontrem com você por mais ou menos uma hora e revise alguns trechos de código nos quais você gostaria de receber feedback. Se o feedback for muito negativo, não fique na defensiva. Faça anotações e considere fazer as alterações sugeridas. Mas faça isso em algo que você ainda não enviou para prod (ou, francamente, você não fará as alterações). Você pode fazê-lo informalmente em sua mesa, basta ligar para alguém e dizer: "ei, não tenho certeza se tenho a melhor solução aqui, o que você acha?"
Outra maneira de gradualmente fazer com que as pessoas comecem a ver o valor da revisão de código é ter uma sessão uma vez por semana em que todos devem apresentar um trecho de código para revisão (ou você alterna entre cada pessoa, mas apenas uma por semana, dependendo da a complexidade do tipo de código que precisa ser revisado). Traga rosquinhas ou pãezinhos pela primeira vez! Se as pessoas se sentirem desconfortáveis em contar para alguém pessoalmente ou se você achar que as pessoas serão muito defensivas, peça que enviem um e-mail ao chefe e que ele consolide os comentários para que a pessoa que está sendo revisada não saiba quem disse o que aconteceu com o código. Sinceramente, prefiro saber pessoalmente quem disse o quê, porque minha própria avaliação de suas próprias habilidades de codificação me ajudará a decidir com que seriedade devo levar as críticas.
Se você não conseguir encontrar alguém para revisar seu trabalho, sente-se e tente explicar o código e por que você está fazendo o que está fazendo como se alguém estivesse lá. Estou impressionado com a frequência com que foi a pessoa que criou o código que encontrou o problema ao explicar para que serve o código. Também ajuda a sentar-se com o documento de requisitos como uma espécie de lista de verificação e garantir que não está faltando algo necessário.