Cegueira de bugs: por que devs não enxergam falhas óbvias

{ "resumo": "## O fenômeno da cegueira de bugs\n\nO autor, Dan Luu, relata que enxerga centenas a milhares de bugs por semana, enquanto a maioria das pessoas com quem conversa não nota nada parecido. Durante muito tempo atribuiu isso à sua forma de usar computadores, mas concluiu que as pessoas estão, na verdade, atingindo os mesmos bugs sem perceber. Ele argumenta que curar essa "cegueira de qualidade" é útil para programadores e relata que, ao simplesmente apontar bugs para amigos e conhecidos, muitas pessoas começam a notá-los por conta própria após algumas semanas.\n\nPor causa dessa habilidade, o autor diz ter sido convidado em vários empregos para avaliar produtos quando executivos queriam uma opinião de alguém propenso a notar problemas. Às vezes não encontra falhas; mais frequentemente encontra problemas de grau "leve" a "moderado"; e, em alguns casos, os problemas são tão graves que o produto simplesmente não funciona sem uma série de soluções alternativas nada intuitivas. O que o intrigava é que, ao investigar discussões internas, havia fluxos de comentários dizendo que o produto era ótimo. Por anos ele se perguntou se não estaria desencadeando comportamentos de canto incomuns, mas passou a ver produtos lançados que fracassam exatamente pelos problemas que ele havia notado, e hoje usa LLMs para simular usuários normais e mostrar que os problemas se reproduzem em muitos cenários.\n\n## Exemplos de cegueira coletiva\n\nO autor cita um experimento próprio com consultas de busca em que Google, Bing e Kagi retornaram resultados ruins, cheios de spam de SEO e até golpes - o que ele classifica como "moderado", não "sever". Quase ninguém discordou da caracterização sobre Google e Bing, mas pessoas defenderam Kagi; em todos os casos em que enviaram seus resultados reais, faltava um resultado útil e havia spam, exceto quando o usuário fixava o GitHub no topo.\n\nEle compara isso a fóruns de Volvo, que insistem que os carros são muito confiáveis apesar de dados de confiabilidade medíocres ou ruins por mais de uma década. O exemplo central é o Blackboard, software de gestão de cursos que era amplamente detestado por estudantes e professores - a Wikipédia cita uma pesquisa da Amplicate de 2011 em que 93% dos respondentes "odiavam" a empresa. Ainda assim, um funcionário do Blackboard ficou genuinamente confuso quando o autor disse que muita gente não gostava do software, pois acreditava que ele era amado. Outro caso citado é a performance web do Discourse: a empresa tinha código que retardava carregamentos reais de página para trapacear em métricas como LCP, o que sugere que os programadores sabiam da performance ruim, mas ergueram barreiras mentais.\n\nO autor também menciona um jogador de basquete considerado o mais violento da sua era, cujos fãs não percebem as faltas, e reflete que humanos têm grande capacidade de ignorar negativos em coisas de que gostam, especialmente no próprio trabalho. Ele diz ter a reação oposta: enxerga imediatamente as falhas no próprio trabalho e busca críticas ativamente.\n\n## Hábitos de contorno e dogfooding\n\nO autor descreve mitigações habituais acumuladas ao longo dos anos: esperar antes de renomear um Google Doc por causa de um bug que sobrescrevia o título, ou desligar o Wi-Fi do laptop antes de logar na Microsoft para burlar um serviço que falhava o login. Para ele, grande parte da alfabetização computacional é uma biblioteca desses hábitos inconscientes. Por isso, dogfooding funciona apenas parcialmente: programadores são muito bons em contornar falhas e param de notá-las. E, quando recebem feedback desse tipo, a reação reflexiva costuma ser defender que a tarefa é fácil - desde que se siga uma sequência complexa que ninguém descobriria sem anos de uso.\n\nAinda assim, ele acredita que a cura é possível quando a pessoa é receptiva, e argumenta que isso importa porque viu equipes com alta cegueira de qualidade lançarem produtos sem chance real de sucesso. Com agentes de código, o tema ficou mais importante: nunca foi tão fácil produzir software de baixa qualidade, mas também nunca foi tão fácil melhorá-lo - desde que se perceba que isso é possível.\n\n## Apêndices\n\nEm apêndices, Michael Malis relata cegueira análoga sobre publicidade, e o autor discorda da ideia de que "anúncios não funcionam", citando testes A/B geo-segmentados que viu em empresas em que o retorno sobre o investimento em anúncios foi bom. Ele observa que programadores, por usarem bloqueadores de anúncios, não notam anúncios, enquanto muitas pessoas comuns nem sabem que anúncios são anúncios. Outros comentários citados incluem mitigações de bugs de laptops (Emu Chu), um bug do Google Docs encontrado por Gary Bernhardt ao ler o rascunho, e notas sobre a palavra alemã "Betriebsblindheit". O autor reconhece precedentes, como o post de John Regehr "Operant Conditioning by Software Bugs".", "hook": "Um programador enxerga centenas de bugs por semana onde a maioria das pessoas não vê nada - e descobriu que as outras pessoas estão atingindo os mesmos defeitos sem notar. Um funcionário do Blackboard, software notoriamente detestado, ficou confuso ao saber que havia gente que o odiava. O texto explora por que todos envolvidos em um projeto podem acreditar que estão entregando algo de alta qualidade quando não estão.", "entities": ["Dan Luu", "Blackboard", "Discourse", "Google Docs", "Kagi", "Google", "Bing", "Volvo"], "themes": ["engenharia-de-software", "trabalho-e-carreiras"], "story_key": "cegueira-de-qualidade-software",\n "reasoning": { "story_key": "Tese central do texto: programadores e equipes não enxergam falhas óbvias do próprio software por causa de hábitos de contorno e cegueira de qualidade.",\n "themes": {\n "engenharia-de-software": "O assunto é qualidade de software, bugs, dogfooding e hábitos de contorno - craft clássico, sem IA como assunto central (agentes aparecem só como nota final).",\n "trabalho-e-carreiras": "O texto discute como equipes e profissionais se cegam à qualidade, impacto no sucesso de produtos e reação de devs a feedback de qualidade."\n },\n "entities": {\n "Dan Luu": "Autor e narrador das observações e experimentos.",\n "Blackboard": "Exemplo central de software amplamente detestado cujo funcionário o considerava amado.",\n "Discourse": "Exemplo de código que trapaceava métricas de performance (LCP).",\n "Google Docs": "Exemplo recorrente de bugs e hábitos de contorno.",\n "Kagi": "Buscador cujos resultados spam defenders negaram.",\n "Google": "Motor de busca avaliado no experimento de resultados ruins.",\n "Bing": "Motor de busca avaliado no experimento de resultados ruins.",\n "Volvo": "Exemplo de fãs cegos a dados de confiabilidade."\n },\n "excluded": {\n "Tumblr": "Menção secundária em nota de rodapé.",\n "Codex": "Menção secundária em comentário de hábitos de contorno.",\n "Microsoft": "Aparece apenas como anedota de login no Wi-Fi.",\n "Michael Malis": "Citar como fonte/apêndice, não sujeito do fato.",\n "Gary Bernhardt": "Citado em comentários e agradecimentos."\n }\n }\n}