Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?
Você deve dar o melhor de si. Eu sei que às vezes há condições e ambientes que são tão complexos que não podem ser reproduzidos exatamente , mas você certamente deve tentar se puder.
Se você nunca reproduziu o bug e o viu por si mesmo, como você pode ter 100% de certeza de que realmente o corrigiu? Talvez sua correção proposta introduza algum outro bug sutil que não se manifestará, a menos que você teste reproduza o defeito original.
If I am a senior developer, should I be able to read (multithreaded) code and create a mental picture of what it does in all use case scenarios rather than require to run the application, test different use case scenarios hands on, and step through the code line by line? Or am I a poor developer for demanding that kind of work environment? Is debugging for sissies?
Eu não confiaria em alguém que executa o código "em sua cabeça", se essa é a abordagem somente . É um bom lugar para começar . Reproduzindo o bug e corrigindo-o e, em seguida, demonstrando que a solução impede que o bug ocorra novamente - é aí que ele deve terminar .
How should I talk with my team to convince them that my approach is reasonable, conservative and more bulletproof?
Porque se eles nunca reproduziram o bug, eles não podem saber ao certo se ele foi corrigido. E se o cliente voltar e reclamar que o bug ainda está lá, não é uma coisa boa. Afinal, eles estão pagando a você muito $$$ (suponho) para lidar com esse problema.
Se você falhar para corrigir o problema corretamente, você quebrou a fé do cliente (até certo ponto) e se houver concorrentes em seu mercado, eles podem não ser seus clientes.