10 Frases Idiotas que podem (e devem) ser evitadas na hora de pedir ajuda (e como pedir ajuda apropriadamente)

Um agradecimento especial à turma do Stack Overflow em Português que me ajudou com esta lista.

Pedir ajuda em programação é algo diário. Ninguém nasce sabendo programar super bem ou dominando um framework. Com um bom domínio do inglês e o Google, a maioria dos problemas encontram soluções no primeiro ou segundo link da primeira página de resultados de busca. Só que não é todo mundo que consegue encontrar solução dessa forma.

Essas pessoas normalmente vão para os fóruns e para os sites de perguntas e respostas (como o Stack Overflow em Português, do qual participo ativamente). A conclusão que chego é que as pessoas que pedem ajuda não sabem como pedir ajuda. Normalmente querem que as coisas venham meio prontas, ou que a gente adivinhe o que tem na mente e no código delas. Infelizmente, não tenho esta capacidade até o momento, e acredito que meus colegas programadores também não.

Além disso, há uma coleção de frases infelizes e que nada ajudam o programador na resolução do seu problema. Por causa disso, vou listar aqui dez frases inolvidáveis e inúteis que são ditas na hora de se pedir ajuda.

"Fiz isso aqui e não deu certo."

Entendemos sua dor. Nada é mais frustrante que tentar aplicar uma solução e ela não funcionar, mas infelizmente não tenho essa capacidade de procurar o problema para você, então se faz necessário detalhar o que foi feito. Eu sei que é um trabalho chato, mas precisa ser feito. Sem informação não é possível resolver.

Há uma série de perguntas que podem ser feitas aqui:

• Deu erro? Se sim, qual a mensagem?
• Você entendeu o que a mensagem diz? Pesquisou no Google sobre ela?
• Como está seu código até o momento?
• Como estão suas configurações até o momento?

"O erro não tem nada a ver com a atualização que eu fiz agora."

Afirmar uma coisa assim é algo desonesto. Atualizações podem sim ter a ver com o seu problema. Se você veio pedir ajuda, tudo pode influenciar no problema, então prefira não afirmar coisa alguma.

Se você fez alguma atualização ou algum procedimento, apenas diga que o fez, e se possível, diga também a motivação para isso. É a melhor forma de propor uma solução para o seu problema.

"Estou há dias tentando, preciso muito de ajuda."

Se você está há dias tentando algo, em primeiro lugar, dizer isso não vai acelerar a resolução do seu problema. Em segundo lugar, vai apenas atestar que você não tentou enxergar o problema sob outra abordagem, que eu diria que é o substrato para uns 50% de todos os problemas que vejo na programação que não são resolvidos, ou são resolvidos parcialmente através de soluções medíocres.

Isto acontece muito com programadores que aprenderam poucas abordagens e as tentam usar em tudo o que podem. Isto é um velho problema cultural e profissional brasileiro. O programador sempre "acha que já aprendeu o suficiente, e que, portanto, não precisa mais estudar". Nada é mais errado. A profissão de programador exige que o profissional estude a vida toda. Que leia muito, que se informe ainda mais. O mercado muda completamente a cada 10 anos.

Assim sendo, procure explicar o que você tentou e tente ver o problema sob outra ótica. Isto eu sei que não é simples e mereceria outro post em separado só sobre como pensar fora da caixa. Mas tente.

"Me ajuda nisso? Você tinha me ensinado, mas eu esqueci."

No Stack Overflow em Português, temos uma série de mecanismos de pesquisa interna. Perguntas e respostas feitas por você normalmente ficam num histórico. Basta apenas procurar.

Esquecer é normal. Eu mesmo esqueço de várias coisas que disse em perguntas e respostas minhas, mas o que acho pouco válido é alugar o tempo dos outros para pedir para repetir uma explicação que já foi dada.

Responder pessoas em fóruns e sites de perguntas e respostas não deixa de ser uma forma de filantropia. Toma tempo do programador que ele poderia estar usando para fazer outras coisas. Eu e meus colegas nada ganhamos para responder perguntas de outros usuários (indiretamente confesso que isso me beneficia em outras coisas, mas diretamente faço isso como voluntário). De qualquer forma, este tipo de pedido apenas toma desnecessariamente o tempo dos outros porque você está com preguiça de achar a informação que precisa e que sua memória não ajuda. Pense se seria legal se fizessem isso com você.

Se está escrito, é pesquisável. Use a barra de ferramentas. Use o Google. Use o painel de informações do seu perfil. Está tudo lá.

"No meu computador funciona."

Isto é o que eu chamo de "pareidolia computacional". Montei esta expressão porque meu ceticismo funciona da mesma forma tanto para a pareidolia tradicional quanto para a computacional. E a explicação normalmente está na falta de uma investigação mais aprofundada sobre o fenômeno em ambos os casos. E, normalmente, quem se contenta com este comportamento inexato normalmente é um profissional de baixa qualidade.

É natural o programador não investigar o problema muito a fundo porque dá trabalho, há um investimento de tempo nisso, pode ser frustrante dispender de tempo e energia para se chegar a lugar nenhum, e assim por diante. A frase dita por alguém apenas mostra como o problema não foi investigado o suficiente. Às vezes nem por culpa do programador, mas porque o problema é tão cabeludo que fica mesmo complicado achar uma solução facilmente.

De qualquer forma, é muito difícil sua máquina ser a areia na engrenagem. A exceção da exceção. Claro que pode acontecer, mas o correto é tratar fenômenos e causas pela regra geral, e não pela exceção.

"Eu sei que está errado, mas foi definido assim."

Além de inútil, esta frase apenas prova como a solução não foi discutida o suficiente, e que o resultado de um consenso errado (ou da falta de um consenso) pode acabar fazendo um programador (ou uma equipe inteira) incorrer em uma abordagem errada.

Neste caso, devo dizer que o problema não é nem a frase, mas a forma de trabalho e a relação do superior com seus liderados. É por isso que o conceito de liderança é tão importante aqui: o verdadeiro líder aceita as ideias dos membros da sua equipe e os deixa livres para implementá-las de acordo com o que julgam certo. O que se revela aqui é justamente o contrário: a decisão é tomada monocraticamente o o(s) programador(es) é(são) obrigado(s) a fazer da forma errada.

Se está errado, contrarie. Se seu emprego não permite contrariar seu supervisor, não fique nele. Ninguém precisa ter um emprego à moda do século passado.

"Este framework é ruim. No outro eu fazia de tal jeito e funcionava. Este não tem o que eu preciso."

O framework pode até ser ruim, mas você é pior do que ele.

Frameworks só são de fato ruins quando são muito jovens, de comunidade pequena e pouco flexíveis. Fora isso, é raro um framework ser ruim e continuar a ser plenamente aceito por muito tempo. O que normalmente ocorre é que surge um novo framework melhor que supera o ruim, e frameworks ruins são naturalmente extintos.

É muito difícil um framework "não ter o que você precisa". Normalmente tem, mas está fora de uma abordagem em que você esteja habituado. Aqui estão toda sorte de programadores teimosos, com vários vícios de programação e que não querem aprender como um novo framework funciona: querem usá-lo como se ele fosse um framework mais antigo. Isso é muito comum no Brasil e ocorre quando se começa um novo sistema que já começa velho, porque seu programador responsável não quer aprender algo novo.

"Não dá pra fazer assim. Meu prazo é curto."

Dá. Acredite. O que talvez você não possa fazer é dizer "não".

Acho que, no Brasil, dizer "não" a um chefe pode ser uma grande afronta. Depende da empresa. Já disse "não" algumas vezes. Em algumas fui compreendido. Em outras fui penalizado de alguma forma. Gosto de entender as reações ao "não", que me dizem muito sobre a companhia. Empresas que simplesmente penalizam sem entender os motivos são aquelas que estão fadadas a amargar problemas, rotatividade elevada, prejuízos e até a desaparecer em breve. As que compreendem e correm para fazer o certo são as que valem a pena e costumam prosperar, com baixa rotatividade e bons índices de satisfação. Nada melhor que uma empresa que aceite suas contribuições e as valorize.

Ao dizer "sim", você está admitindo entregar um produto a qualquer custo, cheio de artifícios técnicos e pouca confiabilidade. Provavelmente será um esforço que terá que ser refeito mais tarde. O cliente se revoltará. Muitos episódios de stress virão. Muitas horas extras desnecessárias também. Só quem já virou finais de semana arrumando cagada sabe o valor que se tem de organizar as coisas direito. E de dizer "não" quando é preciso ser dito.

"Precisa de tal coisa? Ninguém me falou isto!"

Mostrar surpresa ante a um fato novo normalmente atesta a capacidade de absorver novos desafios e a rapidez para superá-los. Ou melhor dizendo, atesta o quanto o programador irá se bater para resolver mais um problema.

Trabalhando com agências de publicidade, onde a urgência é rotineira, o encontro de novos problemas no desenvolvimento de um projeto, normalmente feito a toque de caixa, é diário. Poucos programadores possuem a desenvoltura adequada para antever problemas rapidamente e a melhor maneira de resolvê-los também com certa celeridade. Neste período, tive alguns problemas com colegas meus por insistir numa abordagem que, apesar de um pouco mais demorada, era a mais correta, e os ganhos futuros seriam enormes. Este tipo de frase veio algumas vezes deles, e só consegui me fazer entender algum tempo depois, à custa de muitas críticas sobre o tempo de entrega dos projetos e algum desgaste pessoal e profissional. Mas valeu a pena.

Um bom programador, ao verificar que existe um novo problema, primeiro parte atrás de uma solução, silenciosamente, e não alardeia sobre o problema novo. Os próprios gestores irão agradecer se você puder resolver os problemas por si só, ao invés de apenas se queixar de que não tinha conhecimento da situação.

"Não entendi essa forma de fazer. Não tem uma mais fácil?"

No Stack Overflow em Português, normalmente apresentamos a melhor forma de resolver um problema, mas infelizmente não somos responsáveis pelo entendimento das pessoas que fazem perguntas por lá: apenas pelo conteúdo apresentado, que - esperamos - seja sempre o mais claro possível.

Em alguns casos acontece de a pessoa simplesmente não querer aprender a abordagem da resposta. Isto é bastante revoltante por alguns motivos:

• Alguém gastou um tempo para interpretar seu problema e propor uma solução para ele;
• Alguém, para explicar e entender seu problema, precisou estudá-lo e implementá-lo, e provavelmente esta é a melhor forma de fazer;
• Normalmente as respostas acompanham exemplos. Alguns deles são soluções até prontas, que as pessoas simplesmente precisam baixar o código e ler, e nem isso é feito.

É desperdício de trabalho. Obviamente muitas pessoas podem ser beneficiadas pela dúvida de uma pessoa, mas se a própria pessoa não usa a solução proposta, a solução pode ser tida como imprecisa ou errada. O cúmulo ocorre quando a pessoa disse que "resolveu o problema" e apresenta como resolução algo que certamente dará problemas. Naturalmente, algum tempo depois a pessoa retorna pedindo ajuda novamente.

Isto não quer dizer que toda solução tenha que ser louvada. Existem respostas bem ruins naquele site e em muitos outros. O problema é quando soluções boas são deixadas de lado por serem "muito difíceis".

Agora que falei, vou definir algumas premissas que podem ser úteis quando se quer buscar ajuda:

1. Antes de mais nada, pesquise se alguém já teve o mesmo problema que você. Procure pesquisar sempre em inglês primeiro;
2. Se seu problema já não tem uma resposta e você realmente deve pedir ajuda em sites e fóruns, detalhe o melhor que você puder seu problema;
3. Descreva o que você já tentou e o que não funcionou;
4. Exponha o melhor que puder o que você imaginou para um caminho de resolução;
5. Se você não entendeu um conceito apresentado por alguém que quer te ajudar, vá atrás. Estude. Pesquise. Procure se informar. Pea material de apoio, se for o caso;
6. Evite atalhos, soluções fáceis ou caminhos curtos, como diz H. L. Mencken, "para todo problema complexo, existe sempre uma solução simples, elegante e completamente errada";
7. Não acate tudo o que seus superiores dizem, sem questionar. Se algo lhe parece errado, converse. Não fique numa empresa em que superiores tomem decisões ruins e não aceitem ideias divergentes.

Pense em tudo isso. Não seja um programador ruim. Programadores ruins prejudicam a si mesmos, seus colegas e clientes.