Escrito em 2005 por Philipp Lenssen, um texto mostrava a importância de bons programadores terem condutas que muitos poderiam considerar ‘defeitos’. Dias atrás, tive o prazer de reencontrar esse mesmo texto, e percebi que muita coisa continua atual. O que se segue é uma tradução / adaptação do texto original, com alguns comentários pessoais sobre o assunto. Reflitam. WTF’s não vem apenas dos usuários, mas principalmente dos programadores…

Ao longo dos anos, percebi que, por mais paradoxal que isso possa parecer, bons programadores devem ser preguiçosos e burros.

Preguiçosos, porque apenas programadores preguiçosos irão pensar em escrever o tipo de código que no fim fará o trabalho por eles. Preguiçosos, porque apenas um programador preguiçoso evitará a todo custo escrever trechos repetitivos e monótonos de código – o que evita a redundância, principal inimigo da manutenção no código-fonte. Principalmente, as ferramentas e processos criados por esse comportamento de pura preguiça irão aumentar a velocidade de desenvolvimento.

Isso tudo faz com que o programador preguiçoso um bom programador. Claro, isso é apenas uma parte da verdade: para um programador preguiçoso ser um bom programador, ele (ou ela) também deve ser extremamente ‘não-preguiçoso’ quando se trata de aprender a como permanecer preguiçoso – ou seja, qual software faz sey trabalho mais simples, quais métodos evitam redundância, e como ele pode fazer com que a manutenção do seu código seja a mais simples possível.

Em segundo, (e vou elaborar um pouco mais a partir daqui, porque o conceito é bem menos claro que o primeiro) um bom programador deve ser burro. Por que? Oras, se ele for inteligente, e tiver a consciência de que ele é inteligente, o programador irá:

a) parar de aprender
b) parar de ser crítico com relação ao seu próprio trabalho

O primeiro ponto fará com que seja complicado para ele encontrar novas técnicas para que trabalhar mais rápido. Basicamente, o programador que para de aprender não busca novas soluções, não busca novas alternativas e permanece preso às ferramentas e métodos que ele já conhece. O segundo ponto fará com que ele perca muito tempo debugando o próprio código. Na interminável luta entre um programador e o compilador, é melhor que o programador desista logo e admita que a culpa é sempre dele, e não do compilador, e vá tentar entender o quê ele está fazendo de errado. (nota: OK, há casos em que a culpa É do compilador. Mas são tão raros que dificilmente você vai encontrar várias situações assim no seu dia-a-dia).

Mas há um ponto ainda mais importante sobre porque um programador deve ser burro. Para encontrar sempre a melhor solução para o problema, ele deve ser capaz de manter uma mentalidade fresca e aprender a “pensar fora da caixa”. Tem em mente que o problema nem sempre é o que parece, e a melhor solução nem sempre é o que você imagina, e saber pensar em soluções alternativas e fora do comum.

O contrário disso não seria muito construtivo: conhecer todos os parâmetros e funções, e aceitá-los. Quem garante que os limites que você conhece são reais? Quanto menos você souber, mais radicais serão suas soluções: assim, melhores serão as ferramentes que você criará, e melhores serão os produtos que você desenvolverá com essas ferramentas.

Um bom programador sempre se perguntará “Por que?”, porque ele é burro (ou suspeita de um problema maior).

Um bom programador, quando confrontado com um problema vindo dos usuários, vai adotar a mentalidade de ser burro: ele começará a fazer as perguntas mais simples e infantis possíveis. Isso é porque ele não aceita os parâmetros sugeridos pra ele do que alguém pensa que pode estar causando o problema. Por exemplo, veja uma conversa típica de desenvolvedores web frente a um problema:

“Desde ontem, nosso cliente não consegue ver o logo no site.”
“Ele reiniciou o navegador?”
“Sim.”
“Ele reiniciou o computador?”
“Sim.”
“Limpou o cache?”
“Sim.”
“Ele roda o Internet Explorer 6?”
“Sim.”
“Tem certeza de que ele não consegue ver o logo?”
“Sim.”
“Ele olhou para o site na tela?”
“Como assim?”
“Talvez ele tenha visto o site impresso em papel.”
“Não, ele estava olhando para a tela.”
“Ele não consegue ver outras imagens também, ou só o logo?”
“Como? Bom, vou perguntar pra ele.”

Para fins de argumentação, vamos dizer que o cliente na verdade tenha desligado a exibição de imagens no navegador. Ou o seu filho desligou. Ou um funcionário desligou. Em qualquer caso, a resposta não poderia ser encontrada da “maneira inteligente“. Nenhuma das questões levantadas pelo programador exigiam algum talento em programação. Nenhuma. Mas simplesmente pelo motivo ser tão estúpido, somente a estupidez pode lidar com isso.

Muitas vezes, a suposição de que alguma ação do programador gerou um problema não passa de uma suposição. Sempre que possível, ouça apenas os fatos antes de começar a debugar, e ignore o que as pessoas pensam que seja a razão do problema.

E isso se aplica a VOCÊ. Recentemente, tive um problema aparentemente simples: migrar um sistema de um domínio X para o subdomínio de um domínio Y. Coisa aparentemente simples, se o domínio Y não redirecionasse automaticamente para o domínio Z no Ning, e o subdomínio não estivesse fazendo a mesma coisa. Depois de várias horas batendo cabeça com o DNS e o CPanel, decidi deixar pra lá e fazer algumas atualizações no sistema em questão. Nos primeiros minutos, descubro que o redirecionamento era feito pelo sistema, em um trecho de código que eu havia colocado por questões de segurança. Removido o trecho, tudo funcionou como deveria desde o princípio. Por descuido, cansaço e vários outros motivos, havia perdido tempo e cabelo com um problema que não existia, na verdade….

Pode parecer complicado, ou até mesmo burocrático, mas esse é um processo investigativo simples: quanto mais informações reais você possui, mais fácil é o processo de chegar ao que realmente está causando o problema. Aceitar que o usuário diga apenas “Há um problema no site, e acho que pode ter sido causado pela sua última atualização” só fará com que você perca horas, talvez dias, até perceber que na verdade o problema era mais simples do que parecia.

(Nota: sim, meus caros usuários, nós não tratamos vocês como idiotas ou ignoramos completamente o que você fala do problema por acharmos que somos melhores do que vocês. Nós fazemos perguntas E chegamos à conclusões baseado no que você nos diz que está acontecendo, não no que você acha que pode ser o problema. Na verdade, muitas vezes o que você acha só nos atrapalha. Bons programadores vão ignorar suas sugestões, pelo menos em um primeiro momento…)

Pensem nisso. Sejam burros e preguiçosos. E sejam bons programadores.

Semanas atrás, meu superior me ligou, perguntando se eu estava sabendo de um problema que estava rolando no sistema, com relação a títulos enviados para o banco. Respondi que não, e imediatamente fui ‘escalado’ para resolver um problema que já durava há mais de dois meses: alguns títulos não eram reconhecidos pelo banco. E eu tinha que descobrir a causa do problema em menos de um dia, pois alguns desses títulos já estavam para vencer.

Explicando: nosso sistema (assim como qualquer outro, imagino), logo após emitir nota fiscal dos produtos vendidos, também permite a emissão de boletos para que o cliente efetue o pagamento. Esses boletos possuem uma identificação, e para facilitar todo o processo de pagamento e reconhecimento pelo banco, o mesmo exige que seja enviado diariamente um arquivo com informações dos boletos (ou títulos, como preferir), utilizando um software próprio (cada banco usa um sistema diferente). Esse arquivo é gerado pelo sistema, contendo todas as informações referentes aos boletos emitidos. Mas, de uma hora pra outra, alguns títulos enviados acabavam sendo rejeitados pelo banco, o que trazia uma série de problemas, até mesmo na hora de identificar se o cliente realmente havia pago o boleto.

E o problema se alastrava há dois meses. E eu tinha um dia pra descascar esse abacaxi.

Normalmente, é aqui que os funcionários de TI ficam loucos e começam a correr atrás de soluções bizarras ou explicações malucas para tentar explicar o bug. Mas, acostumado a sofrer com problemas malucos e prazos apertados, me acostumei a utilizar um sistema conhecido como análise da causa raiz, muito utilizado em empresas que possuam certificação ISO. Com a análise da causa raiz, o que é necessário é entender o erro, listar algumas possíveis causas para o mesmo, e testar essas causas, até que uma se mostre a ‘verdadeira’.

No caso, após conversar com os usuários que estavam tratando do problema (e em nenhum momento tiveram a idéia de usar um pouco de raciocínio ou ao menos vieram falar comigo, vejam bem), pude perceber que tudo o que tinha de concreto era uma série de emails enviados tanto para o suporte do sistema quanto para o banco, a maioria com ameaças, e retornos dos mesmos, a maioria com comentários como “está tudo OK aqui, favor verificar com o sistema / banco, o problema é lá“. Ou seja, nada de muito útil. Era hora de tentar entender o problema. Com isso, cheguei às conclusões:

• Apenas alguns títulos davam problema, não todos;
• Os títulos rejeitados eram sempre dos mesmos clientes;
• O mesmo cliente não tinha títulos aceitos e outros rejeitados;
• Não havia qualquer relação entre os clientes, ou seja, detalhes que pudessem fazer pensar que o problema estava no tipo de cadastro deles;
• Tentar re-enviar o arquivo não resolvia; (usuário pensa que se não deu certo na primeira, tenta de novo, e assim vai, até funcionar);

Com isso, já dava para entender alguma coisa, e formular que a causa raiz poderia estar em três pontos:

• No momento da geração do título, alguma informação para esses clientes estava sendo gerada de forma errada ou incompleta (falha no sistema);
• No momento do recebimento do arquivo, o mesmo não estava reconhecendo alguma informação, e dando o título como rejeitado (falha no banco);
• Usuário errou em algum ponto (falha ao nascer);
• Algum outro problema, ainda desconhecido;

Com minha experiência, havia uma certeza de que o problema estava na 3ª alternativa, mas por obrigações contratuais eu era obrigado a provar minha teoria. Perguntei à responsável pelo Financeiro se havia como saber através do contato no banco qual havia sido o motivo da rejeição (percebam que, em dois meses, ninguém havia pensado nisso). Enquanto a mesma procurava obter essa informação, parti para outra linha de frente: investigar algum problema visível no arquivo enviado para o banco. O arquivo na verdade era até bem simples: um arquivo de texto puro, várias linhas, cada linha correspondia a um título, e as informações tinha ‘colunas’ certas para estarem dispostas. Mais ou menos assim:

nomedocliente CNPJInscriçãoEstadual Valoretc.

Claro, era bem mais complicado do que isso, e em uma primeira olhada, o arquivo não trazia nenhum erro visível. Como eu não tinha uma tabela mostrando o que cada ‘coluna’ do arquivo significava, era difícil chegar à alguma conclusão. Mas eu já sabia que, se fosse algo na geração do arquivo, seria alguma informação de cadastro. Nesse meio tempo, a resposta do banco chegou: todos os títulos rejeitados traziam o mesmo erro: ‘CEP incorreto”. E a responsável pelo Faturamento (que deixei sem qualquer atividade nesse período, ela seria mais útil assim) começou a armar a maior confusão, dizendo que havia revisado todos os cadastros, que ela nunca iria deixar um cadastro com o endereço incorreto, e etc. Mas era o que o banco havia informado, valia uma investigação. Nesse momento, nenhuma das possíveis causas apontadas era a ‘preferida’, mas já sabíamos que:

• O banco, por alguma razão, rejeitava alguns títulos de clientes específicos, alegando que o CEP estava incorreto

E qual a melhor forma de descobrir se isso era causado pelo sistema? Comparando um título que havia sido enviado corretamente, com outro que tivesse sido rejeitado. Abrindo o cadastro de um cliente que estava OK, copiei o CEP, fiz uma busca no arquivo de texto, e encontrei em qual coluna estava a informação. Procurando na linha referente ao título rejeitado, tinhamos ’00000000′. Zero.

Nova explosão da responsável pelo Faturamento. Frases como “Eu não estou louca! Eu não estou louca! Esse sistema está trazendo informação errada! O cadastro está correto!” preenchiam a minha sala. E, realmente, o cadastro do cliente estava correto. O cadastro principal dele.

Explico novamente: é muito comum existirem clientes cuja empresa reside em um endereço, mas a entrega do produto ou dos títulos a pagar é em um ou mais endereços diferentes. E o nosso sistema trata isso possibilitando a criação de endereços alternativos, tanto de Entrega quanto de Cobrança. Caso alguma dessas informações esteja cadastrada, o sistema pergunta qual o endereço de entrega, ou qual o endereço para o qual deve ser feita a cobrança. E essas informações aparecem na Nota Fiscal E no Boleto gerado. Agora, advinhem QUAL desses endereços estava SEM o CEP……

Exato. Por algum motivo, a responsável pelo faturamento havia pensado que, se já havia sido cadastrado todas as informações de um endereço, todos os outros endereços poderiam ser cadastrados com o mínimo de detalhes, já que tudo seria ‘puxado’ do endereço principal (mesmo que o endereço fosse diferente).

Estava resolvido, em menos de três horas (sendo que dessas, uma hora foi o tempo que o banco levou para responder sobre o erro nos títulos), chegamos à verdadeira causa raiz:

• O usuário não havia cadastrado o CEP no endereço de cobrança, fazendo com que o título fosse gerado sem essa informação, causando assim, erro no banco.

E, lembrando, isso já vinha ocorrendo há dois meses….

(esse post faz parte da “blogagem inédita“)