O senhor conhece a sensação. Isso já aconteceu com todos nós em algum momento: o senhor examinou o código uma dúzia de vezes e ainda não consegue encontrar um problema com ele. Mas há algum bug ou erro do qual o senhor não consegue se livrar. Deve haver algo errado com a máquina em que o senhor está codificando, com o sistema operacional em que está sendo executado, com as ferramentas e bibliotecas que está usando. Simplesmente tem que haver!
Não importa o quanto o senhor esteja desesperado, não escolha esse caminho. Por esse caminho está a computação vodu e a programação por coincidência. Em resumo, loucura.
É frustrante bater a cabeça repetidamente contra bugs difíceis e obscuros, mas não se deixe levar pelo desespero. Uma parte essencial do ser um programador humilde é perceber que sempre que há um problema com o código que o senhor escreveu, a culpa é sempre do senhor. Isso está adequadamente resumido em O Programador Pragmático como “Select Isn’t Broken” (Selecionar não está quebrado):
Na maioria dos projetos, o código que você está depurando pode ser uma mistura de código de aplicativo escrito por você e por outros membros da equipe do projeto, produtos de terceiros (banco de dados, conectividade, bibliotecas gráficas, comunicações especializadas ou
algoritmos especializados, etc.) e o ambiente da plataforma (sistema operacional, bibliotecas do sistema e compiladores).É possível que exista um bug no sistema operacional, no compilador ou em um produto de terceiros, mas esse não deve ser seu primeiro pensamento. É muito mais provável que o bug esteja no código do aplicativo em desenvolvimento. Em geral, é mais vantajoso supor que o código do aplicativo esteja chamando incorretamente uma biblioteca do que supor que a própria biblioteca esteja quebrada. Mesmo que o problema faça se for com um terceiro, o senhor ainda terá que eliminar seu código antes de enviar o
relatório de bug.Trabalhamos em um projeto em que um engenheiro sênior estava convencido de que a chamada de sistema select estava quebrada no Solaris. Nenhum tipo de persuasão ou lógica poderia fazê-lo mudar de ideia (o fato de que todos os outros aplicativos de rede da máquina funcionavam bem era irrelevante). Ele passou semanas escrevendo soluções alternativas que, por algum motivo estranho, não pareciam resolver o problema. Quando finalmente foi forçado a sentar e ler a documentação sobre o select, ele descobriu o problema e o corrigiu em questão de minutos. Agora usamos a frase “select is broken” como um lembrete gentil sempre que um de nós começa a culpar o sistema por uma falha que provavelmente é nossa.
O outro lado da propriedade do código é código de responsabilidade. Não importa qual seja o problema com seu software, talvez nem seja seu código em primeiro lugar. sempre presuma que o problema está em seu código e aja de acordo. Se o senhor vai submeter o mundo ao seu software, assuma total responsabilidade pelas falhas dele. Mesmo que, tecnicamente falando, o senhor não precise fazer isso. É assim que o senhor ganha respeito e credibilidade. O senhor certamente não ganhará respeito ou credibilidade se ficar eternamente atribuindo erros e problemas a outras pessoas, outras empresas, outras fontes.
Estatisticamente, o senhor entende, é incrivelmente raro que haja bugs ou erros em seu software não seja culpa do senhor. Em Código CompletoSteve McConnell citou dois estudos que comprovam isso:
Um par de estudos realizados [in 1973 and 1984] constatou que, do total de erros relatados, cerca de 95% são causados por programadores, 2% pelo software de sistemas (o compilador e o sistema operacional), 2% por algum outro software e 1% pelo hardware. O software de sistemas e as ferramentas de desenvolvimento são usados por muito mais pessoas hoje do que eram nas décadas de 1970 e 1980 e, portanto, meu melhor palpite é que, atualmente, uma porcentagem ainda maior de erros é culpa dos programadores.
Seja qual for o problema com seu software, assuma a responsabilidade. Comece com seu código e investigue cada vez mais até ter uma evidência definitiva de onde está o problema. Se o problema estiver em algum outro trecho de código que o senhor não controla, não só terá aprendido habilidades essenciais de diagnóstico e solução de problemas, como também terá uma trilha de auditoria de evidências para apoiar suas afirmações. Isso certamente dá muito mais trabalho do que encolher os ombros e apontar o dedo para o sistema operacional, as ferramentas ou a estrutura, mas também gera um senso de confiança e respeito que é improvável que o senhor consiga por meio de apontar o dedo e se esquivar.
Se o senhor realmente aspira a ser um programador humilde, não deve ter escrúpulos em dizer “ei, isso é culpa minha – e eu vou chegar ao fundo da questão”.