A miragem da produtividade

• Bob, engenheiro lendário do Facebook, lançou o Facebook Groups e emplacou resultados seguidos em hackathons mesmo sem um ambiente de desenvolvimento sofisticado
• Usava apenas o Sublime Text básico e logs com printf, em um ambiente com destaque de sintaxe impreciso e sem live reloading nem depurador
• Em contraste, os desenvolvedores ao redor consideravam configurações complexas de ferramentas como a chave da produtividade, com destaque de sintaxe e snippets no Vim, tmux, mosh, atalhos de hphpd e aliases de Git
• Nas vitórias de Bob em hackathons, mais do que a configuração do editor, o que pesou foi o senso de produto e a intuição, ou seja, a capacidade de decidir o que construir
• Novas formas de trabalhar podem gerar mudanças, mas no fim o verdadeiro resultado vem de resolver o problema certo

---

A diferença entre ferramentas complexas e resultados reais

• Bob era uma figura lendária: um engenheiro prolífico que lançou o Facebook Groups e entregava resultados seguidos em hackathons
• Um colega obcecado por produtividade na época usava destaque de sintaxe e snippets no Vim feitos por conta própria para Hack, o dialeto de PHP do Facebook
  • Rodava tmux sobre mosh e ainda tinha atalhos personalizados de hphpd e aliases de Git
• O jeito de trabalhar de Bob, em contraste, era extremamente simples
  • Usava o Sublime Text sem configurações extras, e cerca de metade das cores do código aparecia errada
  • Em vez de live reloading ou depurador, colocava printf no código e esperava os logs aparecerem
• Naquele hackathon, Bob venceu, e o trabalho era, pelo que se lembra, um recurso no Facebook Groups para dar suporte a posts de compra e venda
  • Esse recurso depois evoluiu para o Facebook Marketplace

Mais importante que como fazer é o que construir

• Focar em ferramentas complexas pode prender a atenção no como se trabalha e fazer perder de vista o o quê do trabalho
• O principal fator por trás da alta produtividade de Bob não era a configuração do editor, mas sim seu senso de produto e intuição
• No X, todo dia surge uma nova forma de trabalhar que parece prestes a mudar tudo, e algumas delas talvez realmente possam causar impacto
• Mas o mais importante não são as ferramentas nem o método de trabalho em si, e sim resolver o problema certo

[GN⁺]

Opiniões no Hacker News

• É errado dividir as pessoas entre artesãos que valorizam suas ferramentas e gente obcecada por ferramentas. Boas ferramentas não são brinquedos, mas meios para um fim; eu também passei vários dias criando scripts de shell, funções do Emacs, ferramentas de organização de janelas etc. adaptadas ao meu fluxo de trabalho
  Como resultado, realce de sintaxe, navegação e análise de código, organização da tela e operações de Git passaram a exigir só algumas teclas, e elementos que quebravam minha concentração desapareceram. Invista no ambiente de trabalho — cadeira, prompt do shell, editor —, mas, depois que ele ficar confortável, esqueça isso e foque nos problemas reais
  Dito isso, ajustes intermináveis de ferramentas podem ser um sinal de que você está evitando tarefas difíceis e sem graça, e isso não é um problema simples de culpar a ferramenta em si

  • O que você faz quando entra em uma empresa nova, recebe uma stack tecnológica nova e um notebook Windows? No início da carreira, aprendi a trabalhar com eficiência usando apenas as ferramentas padrão do ambiente que me davam, e, na prática, raramente pude escolher minhas próprias ferramentas. Mesmo ferramentas multiplataforma tendem a ser inconsistentes, com exceção da suíte da JetBrains
  • Parece a diferença entre samurais e ninjas. O samurai via a espada como uma extensão da alma, mas o ninja, se necessário, também usava a espada para forçar objetos a abrir. Na economia de hoje, a visão samurai das ferramentas não se encaixa
  • É importante ter prazer ao usar ferramentas. Mesmo que a produtividade não aumente 10 vezes, o essencial é se concentrar no trabalho e aproveitar o processo
    Especialmente na era dos LLMs, as ferramentas fazem você alternar continuamente entre vários agentes e terminais. Essas trocas frequentes de contexto tiram o prazer e o estado de fluxo; seria ótimo que alguém encontrasse uma solução
  • Parece comum iniciantes pularem etapas necessárias porque querem ser reconhecidos e levados a sério. Parecer assim e realmente se tornar assim são coisas diferentes, e também é preciso sustentar a própria vida enquanto se desenvolve habilidade
  • Depois de dominar uma técnica, boas ferramentas em si se tornam uma grande fonte de prazer. Por outro lado, pessoas experientes às vezes conseguem resultados surpreendentemente bons mesmo com ferramentas inadequadas

• Vi muitos técnicos passarem mais tempo otimizando a configuração do ambiente do que realmente construindo algo, e eu mesmo já fiz isso. A ideia de que 90% do tempo de programação é digitação, então é preciso aumentar a velocidade de entrada, está errada; 90% do tempo deveria ser dedicado a pensar, e a maior parte disso, a ler

  • Software é a materialização de uma solução para um problema, então primeiro é preciso definir o problema a ser resolvido. O código é um retrato que mostra, para todos — inclusive para seu eu futuro —, o nível atual de compreensão do problema e a clareza e adequação da solução
    No momento certo, programar é mais parecido com digitar para concretizar uma solução já compreendida
  • Antes eu era obcecado por configuração, mas, depois que comecei a usar IA, estou criando coisas incríveis que não conseguiria fazer antes. Por outro lado, meu entendimento do código-base e minhas habilidades anteriores estão enfraquecendo aos poucos; embora eu me impressione com novas técnicas, parece que não as aprendo em profundidade
    Nesse sentido, a IA também é uma forma de melhoria do ambiente, pois reduziu a barreira inicial. Antes, quando eu viajava pela Europa estudando InterviewCake para passar de QA a desenvolvedor, também desperdicei tempo refinando a configuração do editor em vez de resolver problemas
    Isso pode ser um sintoma de TDAH. Depois de tratamento medicamentoso recente, minha produtividade mudou muito, e cheguei a ficar com vontade de chorar ao pensar que desperdicei metade da vida tentando deixar a configuração perfeita em vez de fazer trabalho de verdade
  • Há uma lacuna entre produtividade real e produtividade percebida. Usar Vim ou Emacs com destreza pode fazer você se sentir hacker, mas isso não significa ser produtivo. Mesmo comandar dezenas de agentes de IA com enormes quantidades de tokens não garante que o resultado funcione ou resolva o problema
  • Não sei se, para a maioria dos desenvolvedores de aplicações CRUD comuns, a proporção de gastar 90% do tempo pensando e lendo é precisa
  • Pensar e digitar frequentemente acontecem ao mesmo tempo. Muitas pessoas raciocinam melhor sobre o problema escrevendo e modificando código, e isso também ajuda a explicar por que a compreensão do código pode cair bastante mesmo lendo todo o código gerado por um LLM

• Existem empresas financiadas por VCs que não conseguem criar produtos que as pessoas realmente usem ou pelos quais paguem. Elas mostram o quanto estão ocupadas e produtivas para justificar sua avaliação, e a febre da IA pode estar no mesmo contexto por focar apenas em produtividade e método, não no que será construído
  https://components.news/the-gamer-and-the-nihilist/ compara essas startups niilistas com estúdios de jogos que criam produtos que as pessoas pagam para usar. Em uma economia em que apps de produtividade representam quase 40% dos resultados do Product Hunt, às vezes o trabalho é investido em parecer que se está construindo algo, em vez de realmente construir algo

  • Desenvolvedores de jogos também dedicam enorme esforço à criação de ferramentas, só que o alvo principal não é um editor de texto
  • Fico curioso sobre onde se encaixam, nessa analogia, pessoas que passam incontáveis horas criando o ambiente de jogo perfeito em vez de jogar, ou audiófilos que passam a vida procurando o equipamento perfeito em vez de ouvir música
  • Mais do que uma bolha, parece uma manipulação de sinais que se repete há muito tempo. Sempre existiu e continuará existindo

• Crio ou uso ferramentas de produtividade apenas o suficiente para não ficar para trás, e vejo qualquer coisa além disso como uma armadilha. Antes eu revisava isso uma vez por trimestre, mas, depois da IA, passo 1 ou 2 dias por semana nesse metatrabalho de melhorar ferramentas, e espero que isso diminua quando as ferramentas relacionadas se padronizarem
  Se a imagem de especialista em ferramentas fica forte demais, você não só perde trabalhos de valor real como passa a ser visto como alguém com segredos misteriosos de produtividade. Se a diferença não for tão grande quanto esperam, até outros julgamentos seus podem deixar de ser confiáveis

• Quanto menos tempo eu passava na frente do computador, mais coisas resolvia; quando reduzi de 3 monitores para 1, minha produtividade aumentou muito. Resolvo a maioria dos problemas enquanto corto legumes ou aparo a grama, e sentar diante de tecnologia reluzente não produz decisões mais rápidas nem melhores
  O motivo de eu entregar resultados melhores do que as equipes de desenvolvimento dos clientes também é que não sou funcionário em tempo integral e posso parar o suficiente para pensar devagar. O teatro da produtividade, como a pressão para manter o status do Teams verde, leva muitas organizações a decisões tolas

  • Por 15 anos, trabalhei em duas empresas com escritórios em um penhasco com vista para o mar em La Jolla, Califórnia. Eu caminhava pelo penhasco e pelo parque pensando no trabalho e, se fosse uma discussão séria que não exigisse quadro branco, chamava um colega para caminhar comigo. Vale a pena ouvir novamente o hammock talk de Rich Hickey
  • Pelo nome de usuário, fico me perguntando se é o Bob citado no texto

• Ao pensar por que a produtividade existe, cheguei à hipótese de que ela é uma tentativa de reduzir a dor. Muitas otimizações de desempenho, incluindo produtividade de programadores, acabam virando um refúgio para engenheiros fugirem de dores como ambiguidade do domínio do problema, política organizacional, falta de clareza e risco de fracasso
  Mas, para resolver problemas reais, é preciso encarar a realidade: examinar fluxos de trabalho dos usuários em detalhes quase tediosos, propor claramente uma estratégia comum para obter cooperação de outras pessoas etc. Não é necessário glorificar a dor em si, mas bons resultados trazem embutido um treinamento de atleta, e é preciso desenvolver a capacidade de administrar a dor necessária dentro de campo

• O ponto central é se é fácil receber reconhecimento. Ferramentas chamativas qualquer um consegue ver e admirar, mas poucas pessoas reconhecem um ótimo produto ou recurso novo a partir de um editor vazio ou de código esqueleto. Por isso, ferramentas visíveis atraem atenção, enquanto a questão difícil e pouco clara do que construir é ignorada
  Aplico às ferramentas um critério à la Marie Kondo. Se não dá prazer usar e não facilita a vida, descarto; se dá, mantenho

• Em 2004, uma pequena equipe composta em sua maioria por desenvolvedores juniores recebeu um treinamento excelente e extenso em Java. Antes do treinamento, ficamos obcecados com configurações do IntelliJ e do Eclipse e debatemos intensamente, mas o instrutor, surpreendentemente, recomendou usar apenas as ferramentas básicas do JDK e o Notepad
  A intenção era nos fazer aprender o que acontecia por dentro, e ele disse que provavelmente a produtividade também não mudaria muito

• A razão para a obsessão por otimizar o ambiente é que a conexão entre esforço concentrado e recompensa é visível, concreta e física. Já o aprendizado abstrato não é assim. Há muito mais tarefas de aprendizado do que cadeiras para otimizar, então seria bom encontrar uma forma de fazer o aprendizado abstrato parecer mais concreto

• Não se trata de produtividade, mas da diversão de brincar com brinquedos