Ensaios de software que me moldaram

 (refactoringenglish.com)
74 pontos por GN⁺ 2025-10-02 | 3 comentários | Compartilhar no WhatsApp
  • Ao longo de 20 anos, li milhares de posts de blogs sobre software, mas apenas alguns ensaios mudaram fundamentalmente minha forma de pensar; aqui estão 10 ensaios centrais, do "Joel Test", de Joel Spolsky, à defesa do JavaScript puro por Julia Evans
  • O "Joel Test", de Joel Spolsky, apresenta 12 perguntas para avaliar se o empregador respeita os desenvolvedores, verificando se prioriza o tempo e o foco deles por meio de controle de código-fonte, builds diários e correção de bugs antes de tudo, entre outros pontos
  • "Parse, don't validate", de Alexis King, apresenta uma técnica de converter dados em novos tipos durante a validação, mostrando que o sistema de tipos pode contribuir para melhorar a segurança e a confiabilidade da aplicação
  • "No Silver Bullet", de Fred Brooks, divide o trabalho de software entre complexidade essencial e complexidade acidental e argumenta que avanços em ferramentas e hardware não podem gerar um ganho de produtividade de 10x, embora a IA introduza uma variável nessa teoria
  • O ensaio de Julia Evans sobre JavaScript puro trouxe a percepção de que só o JavaScript ES2018 já basta, e desde 2020 ela não integra frameworks nem etapas de build em nenhum projeto

"Joel Test", de Joel Spolsky (2000)

  • Joel Spolsky é o maior blogueiro de software de todos os tempos, e seus ensaios influenciaram profundamente a forma como o autor aborda software
  • O "Joel Test" é um conjunto de 12 perguntas para avaliar o quanto um empregador investe bem em sua equipe de software

  • Lista das 12 perguntas

    • Usa controle de código-fonte?
    • É possível fazer o build em uma única etapa?
    • Faz builds diários?
    • Tem um banco de dados de bugs?
    • Corrige bugs antes de escrever código novo?
    • Tem um cronograma atualizado?
    • Tem especificações?
    • Os programadores têm um ambiente de trabalho silencioso?
    • Usa as melhores ferramentas que o dinheiro pode comprar?
    • Tem testadores?
    • Os novos candidatos escrevem código durante a entrevista?
    • Faz teste de usabilidade de corredor?

  • Mensagem central

    • Algumas perguntas ficaram datadas, mas o importante não são as perguntas em si, e sim o ponto por trás delas
    • O que Joel realmente pergunta é: você respeita os desenvolvedores?
    • Todas as perguntas avaliam se o empregador prioriza o tempo e o foco dos desenvolvedores acima de escritório barato e prazos de curto prazo
    • O texto foi publicado no auge da bolha ponto com, quando desenvolvedores experientes eram um recurso valioso, mas nem todo mundo percebia isso
    • O blog de Joel sempre apresentou programadores como gênios raros e delicados, que os empregadores deveriam buscar e valorizar
    • Ao longo da carreira, o autor sempre procurou empregadores que tivessem pontuação alta no Joel Test e agradece a Joel por esse guia

"Parse, don't validate", de Alexis King (2019)

  • É um ensaio sobre como usar o sistema de tipos do Haskell, mas mesmo sem interesse em sistemas de tipos ou em Haskell, ele muda profundamente a forma de pensar sobre software
  • A técnica de Alexis pode ser usada em qualquer linguagem com tipagem estática, como Go, C++ e Rust

  • Conceito central

    • Sempre que validar dados, é preciso convertê-los em um novo tipo
    • Exemplo: se houver uma regra que limita nomes de usuário a até 20 caracteres alfanuméricos, uma solução ingênua seria uma função validateUsername(username string) error

  • Problemas

    • O código fica inseguro por padrão
    • Como todo nome de usuário recebido precisa ser validado, fica fácil criar por engano um caminho de código que processe um nome sem validação
    • Se um usuário malicioso encontrar esse erro, poderá inserir código malicioso no campo de nome de usuário ou preenchê-lo com bilhões de caracteres para esgotar os recursos do servidor

  • A solução de Alexis

    • Usar uma função parseUsername(raw string) (Username, error)
    • No restante do código, usar o tipo customizado Username em vez de uma string chamada "username"
    • A única função capaz de criar um Username é parseUsername, que aplica as regras de validação antes de retornar uma instância de Username
    • Se você tem uma instância de Username, então ela necessariamente contém um nome de usuário válido
    • Como entrada não confiável é sempre string, não é possível passar uma string para uma função que espera Username

  • Impacto

    • Antes desse ensaio, o autor achava que sistemas de tipos eram uma forma curiosa de distrair nerds de linguagem
    • "Parse, don't validate" mostrou o quanto recursos do compilador são valiosos para melhorar a segurança e a confiabilidade de uma aplicação

"No Silver Bullet", de Fred Brooks (1986)

  • Na faculdade, o autor leu The Mythical Man-Month, de Fred Brooks
  • É uma coletânea de ensaios de engenharia de software baseada em sua experiência liderando o projeto OS/360 da IBM

  • Complexidade essencial e complexidade acidental

    • Complexidade essencial: trabalho que precisa necessariamente ser feito, independentemente das ferramentas e do hardware
      • Exemplo: em um software de cálculo de bônus para vendedores, definir a fórmula do bônus e cobrir todos os casos extremos
      • É o mesmo trabalho num supercomputador de $5B ou num microcontrolador de $1
    • Complexidade acidental: todo o resto
      • Lidar com vazamentos de memória, esperar o código compilar, descobrir como usar bibliotecas de terceiros
      • Quanto melhores as ferramentas e os recursos de hardware, menos tempo é gasto com complexidade acidental

  • Conclusão de Brooks

    • Avanços em ferramentas ou hardware não podem produzir uma melhoria de 10x na produtividade do desenvolvedor
    • Mesmo que todas as atividades acidentais fossem reduzidas a tempo zero, esse ganho não seria possível a menos que elas representassem mais de 9/10 do esforço total

  • Casos de aplicação

    • Ao longo da carreira do autor, as pessoas sempre tentaram remover programadores do desenvolvimento de software
    • Plataformas no-code geraram hype ao prometer a não programadores todo o poder de um desenvolvedor web experiente
    • O ensaio de Brooks sempre o tranquilizou de que a plataforma da moda do momento não pode substituir desenvolvedores
    • Essas plataformas se concentram na complexidade acidental, não na essencial
    • Mesmo que uma plataforma pudesse gerar magicamente código funcional a partir de uma especificação, ainda seria preciso alguém para escrever a especificação

  • Impacto da IA

    • A IA moderna joga uma chave inglesa na teoria de Brooks
    • A IA realmente reduz a complexidade essencial
    • Se você der à IA uma especificação incompleta ou contraditória, ela pode preencher as lacunas tomando emprestado de especificações parecidas
    • Mesmo que a IA elimine parte da programação conhecida, o ensaio de Brooks ainda oferece esperança de que, em algum nível de abstração, continuará sendo necessário alguém para gerenciar a complexidade essencial

"Choices", de Joel Spolsky (2000)

  • Foi difícil escolher apenas um ensaio favorito de Joel Spolsky, então o autor escolheu dois
  • "Choices" trata da criação de interfaces de usuário e do custo sutil de dar poder ao usuário

  • Mensagem central

    • Cada opção oferecida pede ao usuário que tome uma decisão
    • Isso significa que ele precisa pensar sobre algo e decidir
    • Isso não é necessariamente ruim, mas em geral devemos tentar minimizar a quantidade de decisões que as pessoas precisam tomar

  • Exemplo do Windows 98

    • Joel compartilha uma caixa de diálogo absurda que aparece ao pesquisar documentos de ajuda no Windows 98
    • Motivos pelos quais a caixa de diálogo deixou Joel furioso:
      • Interrompe o usuário quando ele está tentando obter ajuda
      • Pede que ele tome uma decisão desinformada sobre otimização de banco de dados
      • O Windows evita decidir e joga a responsabilidade para o usuário

  • Escopo de aplicação

    • O ensaio de Joel foca em interfaces gráficas de usuário, mas o autor o considera em todo lugar em que alguém possa entrar em contato com o código, incluindo linha de comando ou outros desenvolvedores chamando funções que ele escreveu
    • Dá para tomar decisões úteis no lugar do usuário e, ao mesmo tempo, dar a ele controle sobre o que lhe importa
    • O ensaio de Joel já impediu inúmeras vezes que o autor jogasse para o usuário decisões que ele mesmo poderia tomar

Raymond Chen, "“Application compatibility layers are there for the customer, not for the program” (2010)

  • Raymond Chen é um dos desenvolvedores há mais tempo na equipe do Microsoft Windows
  • O blog dele tem milhares de histórias úteis e divertidas sobre a história da programação no Windows

  • Caso de solicitação de cliente

    • Solicitação de um cliente sobre o modo de compatibilidade do Windows Vista:
      • Um programa projetado para Windows XP e Windows Server 2003 tinha dificuldades no Windows Vista
      • Ao configurá-lo no modo de compatibilidade do Windows XP, ele funcionava bem no Vista
      • Pergunta sobre quais mudanças seriam necessárias no instalador para que, ao rodar no Vista, o programa fosse executado automaticamente no modo de compatibilidade do XP

  • A analogia de Raymond

    • "Normalmente eu jogo lixo na calçada em frente à pet shop, e toda manhã, quando a loja abre, alguém varre o lixo e joga na lixeira. Mas a pet shop não abre aos domingos, então no domingo o lixo simplesmente fica lá. Como faço para que a pet shop abra aos domingos também?"

  • Lição

    • A analogia era tão engraçada que só agora percebi que Raymond estava errado
    • Zomba do pecado de desenvolvedores que esperam que o Windows não quebre seus apps depois de uma única release
    • Não concordo com os detalhes, mas os textos de Raymond são tão divertidos e afiados que dá para relevar as falhas
    • Uma excelente lição sobre como influenciar o comportamento do usuário:
      • Se você quer induzir o usuário a fazer algo que ajude você, precisa pensar com cuidado, do ponto de vista dele, no caminho de menor resistência
      • Se você mostrar que jogar lixo na calçada resolve completamente o problema, ele vai continuar fazendo isso

Erik Kuefler, "Don’t Put Logic in Tests" (2014)

  • O autor sempre gostou de testes unitários e tinha muito orgulho do seu código de teste
  • Foi um choque quando esse ensaio apareceu no banheiro e revelou que ele vinha escrevendo testes horríveis a carreira inteira

  • Exemplo de teste problemático

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Problemas identificados

    • Quando leu o ensaio pela primeira vez, pensou: "É exatamente assim que eu escrevo testes unitários!"
    • Por que duplicar a string http://plus.google.com/ em dois lugares? Criar uma única fonte da verdade como no código de produção
    • O autor sempre fazia isso, adicionando funções auxiliares, variáveis e loops para remover duplicação nos testes
    • O problema é que essa abordagem esconde bugs sutis: na prática, está fazendo assert de http://plus.google.com//u/0/photos (duas barras)

  • Percepção

    • O ensaio de Erik mostra que não devemos tratar código de teste como código de produção
    • Os dois têm objetivos e restrições completamente diferentes
    • Acima de tudo, um bom código de teste precisa ser claro
    • Como o código de teste não tem um código de teste próprio, a única forma de verificar sua correção é pela inspeção
    • O teste precisa deixar dolorosamente óbvio para o leitor qual comportamento está sendo verificado
    • Para atingir esse objetivo, é aceitável permitir duplicação para reduzir complexidade

Julia Evans, “A little bit of plain Javascript can do a lot” (2020)

  • Como engenheiro de software, entrou no mundo web de forma constrangedoramente tardia
  • Nos primeiros 10 anos de carreira, só escreveu código para apps desktop e servidores backend
  • Até 2017, não dava atenção a HTML nem JavaScript

  • Equívoco sobre frameworks

    • Quando começou a estudar desenvolvimento frontend a sério, tinha a impressão de que JavaScript era uma linguagem bagunçada criada em 10 dias e que se comportava de forma muito diferente em cada navegador
    • Para escrever apps web, seria preciso alguma coisa moderna e refinada que protegesse você de toda a bile e todos os defeitos do JavaScript
    • Tentou frameworks web populares como Angular, React e Vue
    • Aprendeu Vue o suficiente, mas ainda assim gastou um tempo enorme com problemas de dependência e armadilhas do framework
    • Mesmo depois de tudo que esses frameworks frontend fizeram para consertar o JavaScript, programar para a web continuava sendo ruim

  • O que o ensaio de Julia trouxe

    • Percebeu que estava tão convencido de que JavaScript precisava ser consertado que nem tinha lhe dado uma chance
    • Estava trabalhando em um protótipo do TinyPilot e planejava implementar a interface web com Vue
    • O ensaio de Julia o inspirou a ver até onde dava para ir com JavaScript puro
    • Sem framework, bibliotecas wrapper, etapa de build ou Node.js, apenas JavaScript comum (ES2018)
    • Continuou esperando esbarrar em algum problema que o forçasse a migrar para um framework ou builder, mas isso nunca aconteceu
    • Houve algumas armadilhas relacionadas a WebComponents, mas nada comparado ao sofrimento que teve com Vue e Angular

  • A liberdade sem framework

    • Passou a gostar de se livrar dos frameworks
    • Quando há um erro em runtime, o stack trace não é um pesadelo ruim de código minificado, transformado e tree-shaken
    • É depurar meu código exatamente como eu o escrevi
    • O preconceito que tinha contra JavaScript estava errado
    • O JavaScript moderno é muito bom e absorveu muitas das ideias das bibliotecas wrapper, então elas já não são mais necessárias
    • Os navegadores se acertaram para garantir comportamento consistente entre plataformas e dispositivos
    • Desde 2020, não integrou frameworks JavaScript nem etapas de build em nenhum projeto novo e não sentiu falta
    • Com JavaScript puro, conseguiu 90% das vantagens de um framework com 5% da dor de cabeça

Dan McKinley, “Choose Boring Technology” (2015)

  • É um ensaio estranho para incluir nesta lista porque ele nunca o leu de fato
  • As pessoas citavam esse ensaio e, quando entendeu a ideia, ela pareceu tão intuitiva que ele não sentiu necessidade de lê-lo

  • Ideia central

    • Ao começar um projeto novo, há a tentação de usar tecnologias de ponta que estão em alta
    • O Google anunciou um novo banco de dados que escala até exabytes, é 40% mais rápido que o Postgres e custa 20% disso
    • Usar Postgres quando essa alternativa nova e sexy está ali faz você parecer um idiota
    • Na realidade, tecnologias novas têm bugs e fraquezas, mas isso ainda não está evidente
    • Quando você esbarra nisso, fica sem saída
    • O Postgres tem problemas, mas após 30 anos de experiência no mundo real, ele tem soluções comprovadas para praticamente todo problema que você provavelmente vai enfrentar

  • O conceito de tokens de inovação

    • Dan reconhece que às vezes é preciso usar tecnologia nova, mas só de forma estratégica e em quantidade limitada
    • Toda empresa recebe três "tokens de inovação" para gastar
    • Se você quer aquele banco de dados novo e chamativo, precisa gastar um desses tokens
    • O ensaio de Dan se encaixa naturalmente com o ensaio de Julia
    • Seria ótimo se eu tivesse lido um dos dois antes de desperdiçar todo aquele tempo com frameworks frontend

Terence Eden, “I’ve locked myself out of my digital life” (2022)

  • Terence Eden é um blogueiro de tecnologia bem-humorado e eclético
  • Escreve vários textos novos por semana, mas o que mais impactou foi “tranquei a mim mesmo para fora da minha vida digital”

  • Cenário de desastre

    • Simulação do que aconteceria se um raio atingisse a casa de Terence e destruísse todos os seus pertences
    • Armazenar no gerenciador de senhas as senhas de tudo
    • Se todos os dispositivos forem destruídos, fica impossível acessar o gerenciador de senhas
    • O motivo de isso não poder ser resolvido com passkeys de hardware é que elas também estavam em casa

  • Percepção

    • O autor sentia que seus dados estavam bem seguros, já que guardava tudo em unidades redundantes e tinha backups off-site em três continentes com dois fornecedores
    • O texto de Terence o fez pensar em muitas ameaças confiáveis que podem eliminar todos os dispositivos ao mesmo tempo: incêndio, enchente, surto elétrico, investigação criminal
    • Como todos os dados estão criptografados com senhas que estão na própria cabeça, amnésia, incapacidade e morte também entram na lista

  • O problema dos serviços online

    • Serviços online são frágeis quando se trata de ajudar usuários a se recuperar de um desastre
    • Uso de vários serviços que presumem que perder o telefone é impossível, sem falar na conta de e-mail e em todos os dispositivos digitais que a pessoa possui

  • Impacto

    • Desde que leu o ensaio de Terence, passou a considerar mais quais serviços e dispositivos são importantes e como poderia se recuperar no cenário descrito por Terence
    • Quando comprou o notebook seguinte, configurou-o na biblioteca para testar se conseguiria recuperar o acesso ao gerenciador de senhas e às contas importantes sem nenhum dispositivo que estivesse em casa
    • Ainda dá para melhorar bastante a preparação para desastres digitais, mas o texto de Terence ecoa na sua cabeça sempre que pensa em como proteger dispositivos e dados
    • O que aconteceria se tudo fosse destruído de repente?

Bônus: “parsing user input” (2009), de Brad Fitzpatrick

  • Tecnicamente não é um ensaio, mas é uma citação de entrevista sobre software na qual ele pensa constantemente
  • Leu Coders at Work por causa da resenha superelogiosa de Joel Spolsky em 2009
  • Uma coletânea de entrevistas com programadores de sucesso

  • Frase marcante de Brad Fitzpatrick

    • Brad Fitzpatrick, criador do LiveJournal e do Memcached, aparece como um dos entrevistados
    • Na época ele tinha 28 anos, era o programador mais jovem do livro e também o mais boca-suja e engraçado
    • Em resposta a uma pergunta sobre ética em engenharia de software, fez uma fala apaixonada sobre validação de entrada:
      • “Queria pedir que todo mundo deixasse, de forma consistente, as pessoas digitarem espaços ou hífens em formulários de cartão de crédito. Computadores são bons em remover esse tipo de coisa. Não me diga como formatar meus números.”

  • Aplicação

    • Sempre lembra dessa citação quando tenta colar um número de telefone em um formulário web
    • Reclama quando parênteses ou espaços não são permitidos ou, pior ainda, quando o sistema corta o número de telefone por causa dos parênteses e depois reclama que parênteses não são permitidos
    • Sempre que cria um campo de entrada em software e pensa em caracteres inesperados, escuta Brad Fitzpatrick dizendo: “Computadores são bons em remover esse tipo de coisa”

Leituras relacionadas

3 comentários

 
shakespeares 2025-10-07

Há um presente porque existe uma história.
 
GN⁺ 2025-10-02
Comentários do Hacker News

  • Depois de ler o texto "I've locked myself out of my digital life", senti que ele expressa muito bem uma preocupação que eu tinha, mas achava difícil explicar
    No mundo analógico, eu talvez conseguisse convencer uma pessoa de quem eu sou, confirmar minha identidade e recuperar acesso à conta, mas diante dos algoritmos impiedosos do mundo digital, sem as credenciais não adianta implorar
    Isso porque nem mesmo a empresa do meu gerenciador de senhas tem permissão para acessar minhas senhas
    Não existe sequer alguém para convencer, e apenas o código vira a lei
    Acho que todo mundo deveria entender esse problema antes de defender a eliminação do atendimento presencial em todos os processos
    No artigo isso pode soar como algo raro, mas é algo que pode muito bem acontecer em casos de desastres naturais ou roubo
    Texto relacionado: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • Acho que, na prática, não há tanta gente assim defendendo esse tipo de automação extrema ou a redução do contato humano
      E esse problema não é exclusivo da IA; software baseado em regras sofre do mesmo mal
      Na União Europeia (UE), a lei garante o direito de recorrer a um ser humano contra qualquer decisão

  • Grug Brained Developer é um texto que sempre ficou na minha cabeça, mas não estava na lista
    Na verdade, talvez seja porque eu já concordava com ele, então em vez de transformar meu jeito de pensar, ele apenas ficou marcado na memória
    Referência: https://grugbrain.dev/

    • Desses trechos, gostei muito especialmente da parte sobre "a melhor sensação é finalmente aprisionar o demônio da complexidade no cristal devidamente corrigido"

    • Sou bilíngue e uso o inglês como segunda língua, então textos no estilo grug brain são bem difíceis de ler e entender
      Nem sei exatamente o que significa a palavra "grug"
      Mesmo assim, continuo achando o blog divertido de ler

  • Não concordo com a conclusão sobre "No Silver Bullet", de Fred Brooks
    Não concordo com a ideia de que a IA recente reduziu a complexidade essencial a ponto de derrubar a tese de Brooks
    A IA pode até preencher automaticamente especificações incompletas ou contraditórias com base em casos parecidos, mas a complexidade essencial continua longe de ser plenamente resolvida por IA, e acho que isso continuará impossível no futuro
    Minha análise detalhada sobre isso está aqui: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Obrigado por ler e compartilhar meu texto
      Como você mencionou na sua explicação, concordo que LLMs não conseguem eliminar totalmente a complexidade essencial
      Mas acho que LLMs conseguem reduzi-la até certo ponto
      Como exemplo real, pedi ao Claude 4.1 Opus para definir uma linguagem específica de domínio para imagens geradas por computador
      Eu só passei os requisitos e deixei os detalhes ambíguos, mas o LLM ainda assim escreveu a especificação
      Em casos assim, tenho certeza de que o LLM reduziu a complexidade essencial
      Eu poderia definir tudo do zero com alta qualidade por conta própria, mas se o resultado do LLM já for suficiente, diminui o motivo para investir mais esforço só para melhorar a qualidade
      Originalmente eu sentia pouca necessidade de LLMs, porque em geral sou melhor programando e também gosto mais disso, mas depois de usar percebi que, nas partes em que não preciso gastar meu tempo e minha energia, o LLM assume uma parcela considerável da complexidade essencial
      Exemplo: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • A complexidade que a IA reduz, no fim, é apenas a carga cognitiva de quem escreve o código
      A "complexidade não essencial (nonessential complexity)" de que Brooks falava continua quase toda no próprio código
      No fim das contas, esse peso é transferido para quem for ler o código
      É como vestir um exoesqueleto para colocar um objeto pesado na prateleira e depois pedir ao colega para pintar aquilo de forma bonita

  • O ensaio "Parse, don't validate" é, na minha opinião, um clássico absoluto
    E achei difícil concordar com a frase "Don't put logic in tests"
    No exemplo, o problema surge porque se deveria usar um tipo URI em vez de uma string, e eu penso que, como o código de teste também influencia o sucesso ou fracasso do deploy, ele também deve ser tratado como código de produção
    De qualquer forma, essas discussões certamente valem a pena ser examinadas com calma e avaliadas para ver se fazem sentido no seu caso

    • Também acho curioso que "Parse, don't validate" não seja mais conhecido
      Talvez seja porque a maioria das pessoas ao meu redor trabalha com Go, Python e C++, e o texto parece ser famoso mais no lado das linguagens funcionais
      Acho válida a visão crítica sobre o exemplo de "Don't put logic in tests"
      O exemplo poderia ser trocado por um caso melhor, mas o ponto importante é que até uma simples concatenação de strings pode adicionar complexidade ao teste e fazer bugs passarem despercebidos

    • Pessoalmente, acho atraente a filosofia de não colocar lógica demais nos testes
      Já tive várias experiências de falsos positivos causados por bugs no código de teste, então acabei desenvolvendo certa desconfiança em relação a isso
      Acho que você não deveria sentir necessidade de escrever "testes para os testes"
      Na prática isso é raro, mas recentemente testes ruins escritos por LLMs estão virando moda, e isso está ampliando o problema independentemente dessa filosofia

  • Recomendo os materiais de investigação e revisão de Nancy Leveson sobre o acidente do Therac-25

  • Para mim, meu texto favorito nesta área é "The Parable of the Two Programmers", de Neil W. Rickert
    É uma história que resume com concisão a vida e os desafios de um programador
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Conheço bem o Neil, porque interagi bastante com ele por anos no grupo de notícias Usenet comp.ai.philosophy
      O tom e o conteúdo do texto são realmente muito a cara dele

    • Esse texto é realmente excelente

  • Para mim, este texto foi um ponto de virada
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell não é tão conhecido por aqui

    • Obrigado por compartilhar!
      É a primeira vez que leio esse texto, mas no começo da minha carreira eu li Code Complete e fiquei muito impressionado
      Mantive o livro na estante e, sempre que relia alguns trechos, pensava "isso é realmente excelente, preciso reler direito qualquer hora"
      Fazia tempo que eu não ouvia falar de McConnell, então eu me perguntava por que, enquanto autores contemporâneos como Kent Beck, Martin Fowler e Ward Cunningham continuaram escrevendo mesmo depois de perderem popularidade nos anos 2000, McConnell parecia ter ficado em silêncio
      Descobrir que ele saiu da área de software e migrou para atuar como assessor financeiro foi um choque discreto para mim
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • Não é exatamente um ensaio clássico de software, mas o post de blog "Ban on Imports", de Gilad Bracha, mudou completamente minha visão sobre sistemas de módulos
    Ele enfatiza que import/export equivale, na prática, a estado global, e por isso carrega todos os mesmos problemas do estado global
    Depois disso, passei a valorizar muito mais o conceito de injeção de dependência
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • Talvez não seja fácil classificar estritamente como ensaio de software, mas "Don't Call Yourself A Programmer, And Other Career Advice", de Patrick McKenzie, é um verdadeiro tesouro
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Como alguém muito interessado em linguagens de programação, o texto "slumming with basic programmers" ficou muito marcado na minha cabeça
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Concordo totalmente com a parte sobre parsing de entrada do usuário.
Em que tipo de ambiente trabalha a grande maioria dos programadores que desenvolve a função de inserir um número de telefone alternativo, para ter tanto medo assim de chamar replace() duas vezes numa string?