Além do Código: O Livro dos Maus Argumentos e as Soft Skills

Introdução: o grande mito do desenvolvedor isolado.

Existe um mito persistente que acompanha quem está começando na área de tecnologia: a ideia de que o trabalho de quem programa se resume a sentar diante de uma tela preta, digitar comandos e se comunicar apenas com o compilador.

A realidade do mercado exige outra postura, onde o software não nasce sozinho. Ele é criado, discutido e mantido por pessoas. As linhas de código são apenas o resultado de um processo anterior, muito importante que refletem a troca de ideias, a definição de prioridades e a tomada de decisões técnicas em equipe.

Durante minha jornada na Turma 17 do DIO Campus Expert, uma mentoria em especial mudou minha visão sobre a carreira. O Workshop de Comunicação Profissional, conduzido por Felipe Aguiar, o Felipão, apresentou uma ideia que se destacou: falar bem e saber se comunicar são habilidades diferentes.

Entre as leituras recomendadas pelo Felipão, comecei por uma obra direta e interessante: O Livro Ilustrado dos Maus Argumentos, de Ali Almossawi. Ao conhecer os erros de raciocínio apresentados no livro, percebi que eles não aparecem apenas em debates acadêmicos ou políticos. Também fazem parte do dia a dia das equipes de tecnologia, nas conversas pelo Slack, nas reuniões de planejamento, nas discussões sobre arquitetura e principalmente, nas revisões de código (code reviews).

Neste artigo, quero compartilhar como reconhecer esses erros de raciocínio pode melhorar as discussões técnicas e transformar a comunicação em um diferencial profissional na engenharia de software.

Quem sou eu e por que este tema importa?

Meu nome é Igor Peixoto Lins. Sou graduando em Engenharia de Software e embaixador universitário no DIO Campus Expert. Antes de me dedicar ao desenvolvimento front-end com React e TypeScript, construí uma trajetória de mais de uma década no setor financeiro corporativo, no Banco Bradesco, atendendo ao segmento de Pessoa Jurídica (PJ).

A experiência com empresas, a análise de processos e as negociações envolvendo riscos me ensinaram desde cedo que a forma como explicamos e defendemos uma decisão é tão importante quanto a própria decisão.

No desenvolvimento de software, não é diferente. De pouco adianta criar uma excelente solução técnica se não conseguimos explicá-la com clareza, respeito e bons argumentos para o time e para as lideranças.

4 falácias comuns em times de tecnologia — e como lidar com elas.

Uma falácia lógica é um erro de raciocínio que pode fazer um argumento parecer convincente, mesmo quando as razões apresentadas não justificam a conclusão.

Em tecnologia, onde opiniões pessoais, preferências por ferramentas e diferentes formas de resolver problemas fazem parte da rotina, esses erros podem influenciar as decisões da equipe.

A seguir, apresento quatro falácias abordadas na obra de Ali Almossawi, com exemplos próximos da realidade de quem desenvolve software.

1. A falácia do espantalho (Straw Man).

Significado: acontece quando alguém distorce ou exagera a ideia de outra pessoa para tornar mais fácil criticá-la ou rejeitá-la.

No dia a dia do desenvolvimento:

• A proposta original: pensando na manutenção do projeto, você sugere organizar melhor os arquivos de estilo e centralizar variáveis globais como cores, temas e espaçamentos, usando o :root do CSS.
• A resposta que distorce a proposta: "Então você quer burocratizar o desenvolvimento, criando um monte de arquivos e variáveis para tudo, atrasando a sprint por puro capricho visual?"

Qual é o problema?

A resposta ignora os possíveis benefícios da proposta, como reduzir retrabalho, manter as cores e os estilos consistentes e facilitar futuras alterações. Em vez de discutir os pontos positivos e negativos da solução, transforma a sugestão em algo exagerado para tentar desqualificá-la.

Como lidar com isso?

Explique novamente o objetivo da proposta, sem entrar em uma discussão pessoal.

"A ideia de centralizar as variáveis no :root e organizar os estilos é justamente reduzir retrabalho e evitar diferenças visuais à medida que o projeto cresce. Como podemos adotar essa organização sem comprometer o prazo da sprint atual?"

2. O falso dilema (False Dilemma).

Significado: acontece quando alguém apresenta apenas duas opções como se fossem as únicas possíveis, ignorando outras soluções que também poderiam funcionar.

No dia a dia do desenvolvimento:

• Exemplo: "Ou refatoramos toda a aplicação antiga para uma arquitetura moderna agora, ou o sistema vai cair a qualquer momento e a empresa vai quebrar."

Qual é o problema?

Nem sempre precisamos escolher entre mudar tudo de uma vez e não fazer nada. Entre reescrever toda a aplicação e deixar o sistema como está, existem várias alternativas como: melhorar os módulos mais importantes, criar testes automatizados para as partes mais arriscadas e atualizar o código aos poucos, conforme surgirem novas necessidades.

Como lidar com isso?

Procure outras possibilidades antes de tomar uma decisão.

"Quais mudanças podemos fazer primeiro para reduzir os riscos, sem precisar interromper o trabalho de todo o time para reescrever a aplicação?"

3. O apelo à autoridade irrelevante (Appeal to Irrelevant Authority).

Significado: acontece quando alguém usa a opinião de uma pessoa conhecida ou respeitada como principal justificativa para uma decisão, sem verificar se aquela recomendação faz sentido para a situação atual.

No dia a dia do desenvolvimento:

• Exemplo: "Precisamos usar essa biblioteca de gerenciamento de estado porque o Tech Lead de uma grande empresa de tecnologia publicou que eles a utilizam e que ela representa o futuro da web."

Qual é o problema?

Uma ferramenta que funciona muito bem em uma grande empresa, com milhares de usuários, sistemas complexos e equipes numerosas, pode trazer trabalho e dificuldades desnecessárias para um projeto menor.

Isso não significa que devemos ignorar a experiência de profissionais mais experientes, pelo contrário, suas opiniões podem ajudar muito. O problema está em adotar uma solução apenas porque alguém importante a recomenda, sem avaliar as necessidades do nosso projeto.

Como lidar com isso?

Traga a discussão para os problemas que o time realmente precisa resolver:

"Essa ferramenta pode ser útil em alguns cenários. Mas qual problema do nosso projeto ela resolve hoje? Os benefícios compensam o trabalho extra que teremos para utilizá-la?"

4. O ataque à pessoa (Ad Hominem).

Significado: acontece quando alguém tenta invalidar uma ideia atacando quem a apresentou, em vez de avaliar os argumentos e as evidências.

No dia a dia do desenvolvimento:

• Exemplo: "Você está sugerindo mudar essa regra no pull request, mas acabou de entrar na empresa e quase não trabalhou com essa tecnologia."

Qual é o problema?

O tempo de experiência de uma pessoa não determina por si só se sua sugestão está certa ou errada. Uma mudança proposta em um pull request deve ser avaliada considerando o funcionamento do código, as regras do negócio e os resultados dos testes, e não apenas o cargo ou o tempo de empresa de quem fez a sugestão.

É claro que a experiência de um profissional pode trazer informações importantes sobre o sistema. O problema surge quando ela é usada como motivo para rejeitar uma ideia sem analisar se ela faz sentido.

Como lidar com isso?

Volte a conversa para os aspectos técnicos.

"Vamos analisar essa mudança juntos. Como ela afeta o funcionamento da função, os possíveis erros e os testes automatizados que já temos?"

Boas práticas: como melhorar a comunicação em pull requests.

Reconhecer falácias não significa aprender a vencer discussões. O objetivo é encontrar soluções melhores e criar um ambiente onde todos se sintam seguros para compartilhar ideias, fazer perguntas e aprender.

Três atitudes simples podem fazer diferença no dia a dia:

1. Separe a pessoa do código.

Em vez de comentar "Você esqueceu de tratar essa Promise", prefira algo como:

"Podemos adicionar um tratamento de erros aqui, com try/catch, para lidar com possíveis falhas na requisição?"

Ao falar sobre o código e sugerir uma solução, em vez de apontar o erro como uma falha pessoal, você ajuda a tornar a revisão mais respeitosa e produtiva.

2. Explique o motivo da sua sugestão.

Em vez de dizer apenas "Troque por useMemo", explique por que a mudança pode ser útil:

"Como essa função filtra uma lista extensa a cada renderização, podemos avaliar o uso de useMemo para evitar repetir esse cálculo quando as dependências não mudarem."

Além de explicar sua ideia, essa abordagem permite que a equipe avalie se a mudança realmente vale a pena naquele caso.

3. Pratique a escuta ativa.

Quando alguém questionar sua solução técnica, evite responder imediatamente na defensiva. Primeiro, procure entender a preocupação por trás da sugestão.

Você pode perguntar:

"Qual situação de erro você está considerando com essa sugestão?"

Essa atitude ajuda a transformar uma discussão entre opiniões diferentes em uma oportunidade de aprendizado e melhoria do código.

Conclusão: o pensamento crítico como diferencial de carreira.

A tecnologia continuará mudando rapidamente. Bibliotecas ganham e perdem popularidade, ferramentas de inteligência artificial aceleram a escrita de código e novas linguagens surgem constantemente.

Nesse cenário, saber analisar problemas, explicar suas ideias com bons argumentos e trabalhar bem em equipe são habilidades que continuam importantes.

A leitura de O Livro Ilustrado dos Maus Argumentos, motivada pela mentoria do Felipão no DIO Campus Expert, reforçou uma ideia importante para minha trajetória: conhecimento técnico e boa comunicação precisam caminhar juntos.

Ser um bom desenvolvedor não significa apenas escrever código que funciona. Também significa entender os problemas, questionar decisões com respeito, explicar suas escolhas e ajudar o time a encontrar soluções melhores.

Afinal, um bom argumento não é aquele que encerra uma discussão, mas aquele que ajuda a equipe a tomar uma decisão melhor.

E na sua rotina, quais falácias aparecem com mais frequência?

Você já presenciou alguma dessas situações em revisões de código, trabalhos da faculdade ou reuniões de equipe? Como costuma lidar com opiniões diferentes e divergências técnicas no dia a dia?

Deixe seu comentário para compartilharmos experiências e aprendermos juntos! 🚀

Referências

ALMOSSAWI, Ali. O livro ilustrado dos maus argumentos. Ilustrações de Alejandro Giraldo. Tradução de Diogo Lindner; revisão da tradução de Tiago Fernandes. Nova York: JasperCollins Publishers, 2013. Disponível em: https://bookofbadarguments.com/pt-br/.

AGUIAR, Felipe. Workshop de Comunicação Profissional. Mentoria apresentada no programa DIO Campus Expert, Turma 17. São Paulo: Digital Innovation One (DIO), 2026.

Artigo desenvolvido como parte dos desafios do programa DIO Campus Expert — Turma 17, com apoio do Santander.

Nota sobre o uso de IA: ferramentas de inteligência artificial foram utilizadas como apoio na revisão textual e no aprimoramento da clareza e da organização do artigo. As ideias, experiências pessoais e decisões finais de conteúdo são de responsabilidade do autor.