Fast - O poder do software rápido

• No desenvolvimento de software, raramente se exige rapidez (fast), mas software rápido muda o comportamento dos usuários
• Tecnologias como deploy rápido e streaming em tempo real melhoram de forma revolucionária a eficiência no trabalho e o trabalho remoto
• Software lento gera atrito cognitivo e, na prática, reduz bastante a produtividade dos usuários
• Software rápido não esconde a complexidade; demonstra simplicidade e foco
• No futuro, a indústria de desenvolvimento deve dar cada vez mais importância à otimização de performance e da experiência

---

Um setor de software que não pede rapidez

• No setor de software, normalmente se pedem funcionalidades, preço e integração de dados, mas é raro pedir diretamente “rapidez”
• Ainda assim, software rápido tem o poder de mudar o próprio comportamento dos usuários
• Quando o tempo para fazer deploy do código cai para segundos, a frequência de deploy dos desenvolvedores também aumenta
• Recursos de autocompletar código com base em inteligência artificial facilitam a prototipagem em linguagens pouco familiares
• A tecnologia de streaming em tempo real abre novas possibilidades para o trabalho remoto

Os limites do software lento

• Software lento impõe mais restrições do que imaginamos
• Um exemplo é a experiência de tentar ser produtivo usando Wi‑Fi de avião
  • Dá para enviar mensagens no Slack ou responder e‑mails,
  • mas muitas vezes o Google Docs não funciona direito
  • no fim, a experiência leva o usuário a desistir
• Em contrapartida, serviços como o Instagram oferecem uma experiência consistentemente rápida

O efeito do software rápido

• Rapidez parece mágica
• Software rápido elimina o atrito cognitivo e, como Raycast e Superhuman, reage um passo antes do que o usuário espera
• A latência abaixo de 100 ms do Superhuman e seu excelente suporte a atalhos revolucionam a experiência de uso de e‑mail
• O recurso de transferência instantânea da Mercury também surpreende usuários acostumados com transações bancárias lentas
• A velocidade dessas ferramentas raramente é elogiada de forma explícita, mas é o que faz os usuários sentirem que há algo quase mágico nelas

Rapidez, simplicidade e foco

• Rapidez significa simplicidade, um valor cada vez mais raro no ambiente moderno de software
• Para um software ficar rápido, é preciso remover funcionalidades desnecessárias
• Ferramentas de gestão de projetos mais enxutas, como a Linear, oferecem uma experiência muito mais rápida do que aplicativos corporativos como Workday e Oracle
• Rapidez é uma forma de respeito ao usuário, mostrando que tudo o que é desnecessário foi cuidadosamente eliminado

O esforço oculto para criar rapidez

• Criar software rápido exige otimizações complexas de backend
• No Cash App, busca-se adicionar apenas as etapas realmente essenciais na jornada do usuário, deixando a complexidade para ser resolvida internamente
• No Instagram, ao enviar uma foto, o upload começa ao mesmo tempo em que a legenda é digitada, fazendo o usuário sentir que o envio foi imediato
• Rapidez não é apenas uma conquista técnica, mas o resultado de prioridades bem definidas e foco

Rapidez como diversão e motivação

• Software rápido, por si só, traz diversão e satisfação
• Mesmo em detalhes pequenos, como medir a velocidade de digitação (WPM) ou configurar atalhos, os usuários gostam da sensação de ficar mais rápidos

A relatividade da rapidez

• Workflows baseados em IA e LLMs oferecem uma experiência muito mais rápida do que métodos tradicionais
• Por exemplo, pedir a um LLM para fazer uma pesquisa em 6 minutos pode gerar uma produtividade mais de 10.000 vezes superior em comparação com o passado
• Mas ainda há muitas limitações no desenvolvimento, build e deploy de apps de IA em relação à era anterior do software
• Neste momento, o foco ainda está mais em novas funcionalidades do que em performance e experiência
• No futuro, deve surgir uma tendência de priorizar otimização em áreas como baixa latência, design de interface, conectividade e confiabilidade
• Quando isso acontecer, surgirão novas possibilidades e uma evolução da experiência do usuário

Referências

• Como materiais adicionais úteis sobre rapidez, há os textos abaixo
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Comentários do Hacker News

• Sou muito grato ao YCom por manter a interface do HN rápida e bem cuidada. Tive a experiência de abandonar o Slashdot logo depois que eles refizeram toda a interface em nome de uma "UI moderna", transformando o site em algo cheio de espaço em branco e difícil de escanear. Antes disso, eu lia o site todos os dias
  • Densidade de informação e encontrar rapidamente o que você quer são conceitos completamente opostos a "engagement". Muitas vezes os sites ficam propositalmente mais complicados para inflar o tempo de permanência e agradar anunciantes. A página carrega devagar de propósito para induzir cliques errados e aumentar a "conversão". Na prática, enganar os outros dá mais dinheiro do que colocar o usuário no centro
  • HN é o site que eu abro para verificar se minha conexão com a internet está funcionando. É uma presença realmente brilhante no meio de toda a gordura da web
  • A UI do HN também precisa de melhorias, especialmente no mobile. Falta contraste, os botões são pequenos demais e difíceis de usar, não há modo escuro etc. Eu fiz uma versão do que considero uma UI ideal em Elm, totalmente client-side, usando a API do HN no Firebase: https://seville.protostome.com/
  • Não acho que o Slashdot tenha decaído por causa da UI. O valor real estava nos comentários de altíssimo nível deixados por SMEs nos primórdios. Depois que o site foi vendido, parece que começou a decadência com usuários piores, má moderação e evasão. Ainda me surpreende que o site continue vivo
  • O orange site (HN) ainda não suporta tags de link em Markdown
• Tenho a sensação de que workflows com LLM na prática muitas vezes são mais lentos. A função de "refactor" da IDE termina em 1 segundo, mas se eu passar isso para um assistente de AI leva 30 segundos, e no modo "agente" leva 15 minutos. Por exemplo, pedi a um agente para fazer código de endpoint HTTP e no começo pensei "ele fez em 10 minutos um trabalho de um dia", mas depois vi que a lógica estava toda enrolada e o tratamento de erro era fraco. No fim, reescrevi tudo eu mesmo por umas 5 horas, com testes melhores do que meu padrão inicial e tratamento de erro até melhor do que eu teria feito sozinho. Há estudos sobre isso também https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • Já escrevi algumas vezes sobre esse assunto. Acho que LLM perseguindo benchmark é seguir contra a fibra do que uma ferramenta de programação deveria ser. Pela minha experiência, a taxa de erro é alta o bastante para eu sempre precisar revisar o resultado, então o tempo de ida e volta com o LLM aumenta, e como as respostas demoram, muitas vezes eu sinto que seria mais rápido fazer tudo à mão. O que eu queria era um agente que respondesse em menos de 1 segundo, mesmo que estivesse só no nível de 60% de benchmark
  • O único caso em que LLM realmente acelerou meu trabalho foi como uma espécie de find/replace avançado para código. Por exemplo, ele responde bem quando peço para trocar a "lógica relacionada a XXX" em vários lugares do código por outra coisa. Poupa bastante do trabalho de procurar e alterar tudo manualmente. Nunca tentei isso em código muito grande, porém
  • Acho que depende do contexto. Refactor é muito mais rápido quando a IDE ou o language server dá suporte, mas fora isso LLM também ajuda. Ontem, por exemplo, fiz um MVP de lógica de normalização de URL, e havia muitos casos de validação porque os dados dos clientes traziam URLs em formatos variados. Coloquei no Claude os casos de cliente mais comuns e pedi que ele gerasse "casos de teste de cobertura mínima"; em 5 a 10 segundos ele entregou um resultado, e a partir disso usei o recurso de agente Opus do Zed para criar o arquivo de teste, revisei os casos, removi excessos e melhorei um pouco a lógica. Esse método foi bem mais rápido do que fazer tudo sozinho
  • Tenho ouvido bastante, online e offline, que em trabalho de nível sênior há ganho de velocidade de 40% a 60%. Ainda assim, não parece que já estamos no ponto de confiar só em agentes de AI e largar tudo de lado
• Este é um episódio de quando eu era júnior e ganhei fama por acelerar software. Naquela época, tanto conhecimento de algoritmos quanto a habilidade de ler saída de compilador eram importantes, e era a era em que Carmak e Abrash estavam virando estrelas. Aos 22 anos participei pela primeira vez de uma reunião com um grande cliente multinacional, e apontaram que a velocidade do nosso produto era um problema. Fiquei completamente chocado ao ouvir o VP da empresa dizer diretamente: "cada 1 segundo a menos representa US$ 1 milhão a mais por ano no nosso lucro". Foi um momento decisivo, a primeira vez em que vi velocidade ser convertida em dinheiro dessa forma. Mesmo 20 anos depois, continua sendo um dos grandes destaques da minha carreira. E outro engenheiro ainda brincou com o VP perguntando se, reduzindo até 0 segundo, eles ganhariam dinheiro infinito. Ninguém na sala riu, mas eu achei bem engraçado
  • Não seria algo como ganhar mais US$ 1 milhão ao passar de 1 segundo para 0, e de 2 para 1? Estranho concluir daí que isso implicaria dinheiro infinito
  • No fim, fico curioso se eles realmente conseguiram deixar mais rápido
• Estou reagindo porque concordei com a primeira frase do post. Usuários não pedem diretamente aos desenvolvedores "faça mais rápido", mas se não for rápido, eles também não confiam. Se Rust fosse mais lento que Ruby, ninguém ligaria. Rust chama atenção porque é "mais rápido que C++". No HN, basta ter o atributo de "rápido" que todo mundo parece hipnotizado. Se algo for nem que seja um pouco mais rápido, já chama atenção imediatamente
  • Isso só funciona para a pequena camada de programadores que escreve no HN. A maioria dos desenvolvedores e usuários comuns não se importa tanto se é lento, desde que a UI seja conveniente. Até cientistas de dados profissionais usam bastante o Github Desktop bonitinho em vez de comandos super rápidos
  • A conclusão parece errada. "Rápido" é um diferencial forte quando entrega o mesmo conjunto de funcionalidades mais depressa. As pessoas correm para "X mais rápido que X", mas também podem migrar por ter mais recursos, UX melhor, preço menor ou simplesmente algo melhor, e ainda podem escolher algo lento
  • Em linguagens e runtimes, velocidade importa; ao escolher frameworks, outros fatores como características e compatibilidade pesam mais. Muita gente usa Electron mesmo sendo lento
  • Na prática, vivemos num mundo em que uma grande parte dos apps, especialmente web, é absurdamente lenta. É rotineiro fazer uma ação e só receber resposta vários segundos depois. Mesmo que digamos que "rápido é o melhor", a realidade é o oposto
  • Os usuários do HN gostam de 'rápido' porque sabem que boa parte da tecnologia com que lidamos hoje é lenta demais, e que em essência ela poderia ser muito mais rápida
• Por outro lado, se algo for "rápido demais", às vezes as pessoas passam a duvidar se realmente funcionou. No caso do TurboTax, a análise real levava menos de 1 segundo, mas criaram de propósito uma tela falsa de carregamento, e as pessoas confiaram mais e gostaram mais. Ou seja, embora o processamento fosse muito mais curto, fizeram parecer lento para transmitir a confiança de que "realmente foi analisado"
• Rapidez também importa pelo lado do custo. Quando você paga por segundo na nuvem, fica impossível oferecer um serviço de transcrição barato em escala sem otimizar cada etapa. Por exemplo, uma imagem que eu montei ficou 2,5 vezes menor do que a alternativa open source, e isso se traduziu em cold boot mais rápido, custo menor e serviço melhor https://speechischeap.com
  • O S3 é lento ou rápido? Na prática, os dois. Em uma requisição única ele parece lento, mas se você dispara várias em paralelo ele passa a parecer rápido. No fim, "rápido" às vezes é essencial para sobreviver e às vezes é uma estética
  • No meu caso, faço o oposto: rodo o serviço em hardware de consumo e opero muito mais barato do que na nuvem. Não preciso me preocupar com tamanho de imagem (bare metal é mais rápido). Já ofereço transcrição gratuita de 20 mil minutos por minuto, com limite de 5 segundos por requisição. Também estou desenvolvendo alternativas open source e multiplataforma relacionadas https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer Se alguém tiver interesse em inovar em serviços de transcrição, entre em contato
  • Espero que ferramentas como PAPER fiquem, pelo menos no Linux, com instalação total abaixo de 2 MB, incluindo cache. pip tem 10 a 15 MB, pipx é maior ainda, e uv tem 35 MB. Estou tentando ir além disso
  • Ser rápido não significa necessariamente ser leve e eficiente. Muitas vezes algo fica rápido porque jogaram um monte de hardware caro em cima
• Sempre que vejo artigos reclamando de transferências bancárias nos EUA, preciso me lembrar disso. No Reino Unido, na Suíça e em outros lugares, transferências bancárias são quase instantâneas. Fico me perguntando por que nos EUA é tão lento
  • Bancos regionais nos EUA quase não têm programadores próprios e dependem de "core processors". Por isso, upgrades de sistema são muito lentos. A adoção do Faster ACH também levou anos, e o lobby dos bancos regionais defendeu adiar a implementação por ser ruim para eles. Recomendo este blog, que explica bem o assunto https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • O ACH é lento por causa do agendamento e do processamento em lote (batch). A transferência em si pode acontecer na hora, mas normalmente o acerto é consolidado à meia-noite. Por isso Venmo e Zelle fazem tanto sucesso nos EUA. Na Suíça, transferências IBAN também são lentas, e o pagamento em tempo real dominante é o TWINT, baseado em QR code. O BACS do Reino Unido também é lento pelo mesmo motivo
  • Os EUA de fato têm dois sistemas de transferência em tempo real: RTP e FedNow. O número de bancos participantes está aumentando https://real-timepayments.com/Banks-Real-Time-Payments.html No passado, também era possível pagar uma pequena taxa e enviar dinheiro instantaneamente pela rede de cartão de crédito. Só que cartões têm garantias e regras de chargeback diferentes, e o prejuízo para o banco em caso de fraude é maior
  • Isso também tem um lado positivo para o consumidor. Por exemplo, quando um débito automático tenta tirar dinheiro de uma conta sem saldo, o banco manda vários e-mails de aviso. Se tudo fosse em tempo real, o problema seria imediato; do jeito atual, você tem tempo para ser avisado e agir antes, podendo evitar multa ou tarifa. Como a transferência não é instantânea, o banco alerta e eu ganho uma chance de reagir
  • O patio11 tem um texto detalhado sobre isso https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• O texto foi interessante e me deu bastante coisa para pensar. Quando velocidade é realmente perceptível, mais importante que throughput bruto é a "sensação de rapidez", como responsividade da UI e atraso de input, aquilo que faz o uso parecer confortável. Por isso acabei preferindo mais Go do que Rust. A compilação do Go é rápida o suficiente para parecer algo que nem precisa ser medido. Já coisas lentas, por maior que seja o throughput real, eu simplesmente passo a detestar (como startups Java)
  • Mesmo comparando Go e Rust, a velocidade de compilação parece realmente importante. Builds em Rust acumulam um monte de dependencies variadas e a estrutura do projeto acaba ficando mais parecida com JavaScript. Em comparação, Go tem bem menos deps, e eu gosto disso
  • É bom que desenvolvedores discutam essas coisas, mas o que realmente importa é: para o usuário, qual linguagem é mais rápida?
• Ao contrário da ideia de que "quase nunca se ouve 'por favor, façam mais rápido' em software", em quase todas as empresas onde trabalhei velocidade de resposta de página e latência eram prioridade máxima. Tanto em startups quanto em grandes empresas, velocidade e latência eram metas importantes, e sempre se levava muito em conta quão rápido o produto era, quão rápido a página carregava e se havia atrasos estranhos
  • Na maioria das empresas que vivi na prática (6 de 8), quase nunca me davam tempo para otimização de performance, então eu fazia isso escondido. Até em lugares que mediam latência e diziam que era importante, no fim o trabalho de performance acabava ficando para depois por causa da pressão por novas funcionalidades
  • Era comum ver obsessão com melhorar a velocidade dos resultados de busca, mas pouca atenção à renderização da página ou ao tamanho dos dados enviados ao usuário
• É algo que vivi repetidamente em vários trabalhos: a maioria subestima o valor real da velocidade. Fazem isso porque assumem apenas "o mesmo workflow, só que mais rápido". Por exemplo, acham que acelerar um experimento grande rodando de madrugada não ajuda tanto, mas se o ganho de velocidade for radical, você pode rodar vários experimentos durante o dia, e isso muda completamente o nível de produtividade
  • As pessoas subestimam demais o custo de troca de contexto. Reduzir um comando de 30 segundos para 3 segundos parece só economizar 5 minutos por dia se você roda isso 10 vezes, mas na prática o custo de transição é muito maior
  • Sempre que um pipeline de CI leva várias horas, eu penso que, se terminasse em 20 minutos, eu corrigiria até aqueles warnings pequenos de lint em toda execução