- Apenas a ação em si é execução de verdade; pensar ou se preparar não é executar
- O texto ressalta repetidamente que planejar, estudar, discutir e comprar ferramentas não é “fazer o trabalho”
- Apenas o ato de tentar diretamente, mesmo falhando ou de forma desajeitada, é considerado execução real
- Começar, mesmo que pequeno, é importante, e preparação perfeita ou condições ideais são desnecessárias
- O texto relembra que a postura de transformar em ação concreta é o cerne da criação e do desenvolvimento
Distinção entre execução e não execução
- O texto lista que “pensar, sonhar, visualizar, se preparar” e coisas do tipo não são ‘fazer o trabalho’
- Ex.: “pensar”, “sonhar”, “imaginar o sucesso”, “esperar até estar pronto”
- Falar, explicar ou discutir também não conta como execução
- Inclui “explicar para outras pessoas”, “discutir online”, “anunciar que vai começar”
A armadilha da preparação e do consumo
- Ouvir podcasts, ver tutoriais, ler casos de outras pessoas — nada disso é execução
- Projetar o sistema perfeito, comprar ferramentas ou arrumar o espaço de trabalho também não é visto como execução
- A atitude de se consolar com culpa ou com a sensação de estar ocupado também não é ação real
Como é a execução de verdade
- Fazer falhando, fazer de forma desajeitada, fazer mesmo que pequeno — tudo isso é reconhecido como “fazer o trabalho”
- Mesmo sem perfeição, o importante é realmente colocar a mão na massa
- Na parte final, o texto diz que “até escrever no blog não é fazer o trabalho”, apresentando uma conclusão autocrítica
Mensagem principal
- Só a ação é execução real, e todo o resto não passa de substituto da execução
- Começar, ainda que pequeno, aceitar o fracasso e tentar diretamente é a única forma de avançar
- A frase final, “Agora preciso voltar ao trabalho”, simboliza a postura de agir imediatamente
2 comentários
Para pessoas como eu, que não conseguem executar bem, isso é uma ótima frase.
Comentários do Hacker News
O princípio de "fazer mal feito" mudou completamente minha forma de pensar
Passei semanas tentando projetar a arquitetura perfeita, mas no fim parei de planejar e fiz uma versão tosca que resolvesse meu problema
O mais surpreendente foi que essa primeira versão me ensinou coisas que eu jamais aprenderia só com planejamento. Aprendi o que os usuários realmente valorizam, quais edge cases importam na prática e o que de fato significa “bom o suficiente”
A parte mais difícil é se permitir publicar algo sabendo que há falhas. Mas o loop de feedback do uso real foi muito mais valioso do que semanas de discussões hipotéticas
Hoje em dia esse tipo de post está por toda parte nos subreddits de produtividade. Fico em dúvida se é realisticamente possível passar semanas planejando a arquitetura ao fazer uma ferramenta pessoal de automação
Olhando o histórico de comentários do autor, o mesmo estilo se repete e isso não me passa confiança
Foi realmente fascinante observar esse processo
Há muito a aprender sobre o problema e sobre programação em geral no processo de implementar de verdade e depois refatorar
A abstração pensada no começo quase sempre está errada. Conforme você implementa, a estrutura muda completamente e, no fim, sai um código bonito totalmente diferente do que imaginou no início
A ideia é fazer a primeira versão já esperando jogá-la fora, mas na prática a maioria das pessoas não joga fora e vai melhorando iterativamente
Hoje, graças às ferramentas e aos processos, ficou possível continuar iterando
A estrutura interna também precisa de iteração e prototipagem, mas coisas como estrutura de dados, tratamento de erros, logging e nomenclatura precisam ser decididas com cuidado logo no início para permitir melhorias rápidas depois
Gosto da frase "Doing it badly is doing the thing"
Foi uma lição que aprendi no HN: quando você trava, o importante não é ficar pensando em como fazer perfeitamente, mas simplesmente começar
No começo fica uma bagunça, mas se você for melhorando aos poucos, de repente aparece uma visão clara. Parece mágica
Um é o conselho do Dan Harmon sobre writer’s block, e
o outro é "The Gap" do Ira Glass
A essência é não esperar a perfeição: escreva nem que seja um rascunho horrível e depois vá melhorando com um olhar crítico
Por isso, hoje em dia eu deliberadamente digo “ainda não está pronto” até terminar de fato
Eu costumo primeiro fazer rápido, depois lapidar, e no fim reescrever do zero
O importante é não cair no perfeccionismo na fase beta
Se a melhoria incremental funciona, então tanto faz se é humano ou IA
Na empresa anterior, chamávamos a diretoria de "associação de admiração por problemas"
Eles só se dedicavam a discutir problemas, analisar e procurar culpados, mas não a resolvê-los de fato
No fim, o que importava era “fazer de verdade”
A melhor abordagem é combinar apego ao problema com vontade de iterar na solução
O uso interno do próprio produto, o dogfooding, é uma boa forma de manter esse equilíbrio
É importante decidir na direção mais favorável possível para você
Há menos coordenação por causa de atualizações, e uma organização que realmente trabalha fica mais eficiente
Este texto é muito parecido com o ensaio do strangestloop.io
Quando vi o título, achei familiar, mas ao clicar percebi que era outro site e fiquei surpreso ao notar que a publicação era de poucos dias atrás
O conteúdo é parecido demais para ser coincidência
Antes eu achava que preparação era importante, mas em certo momento percebi que preparação pode virar um loop infinito
Nossa equipe terminou um produto em 4 meses com uma especificação de 2 páginas, enquanto a equipe concorrente passou 8 meses só escrevendo documentos e acabou dissolvida
Planejar 20% resolve 80% dos problemas. Depois disso, o resto muitas vezes é só rigor embalado como ansiedade
No fim, a maior parte do que aprendi veio de colocar algo vergonhoso no ar e ir corrigindo
Foi citado neste comentário anterior no HN
Analysis paralysis existe de verdade
Para não travar, é preciso começar. Faça primeiro o happy path e depois refine os edge cases
Hoje o custo de prototipar é baixo, então é preciso tentar sem medo de falhar
Esse também é o motivo de LLMs serem tão surpreendentemente eficazes — executam imediatamente em vez de analisar
Mesmo quando o resultado não é perfeito, muitas vezes já é útil o suficiente, e depois dá para otimizar se necessário
Antes de criar um framework, você deveria construir pelo menos três sistemas reais. Só assim dá para saber o que está sobrando e o que está faltando
Dizer que algo “está bom o bastante” pode ser autoengano
Um protótipo fracassado não prova que não existe mercado. É apenas um sinal de que estava faltando alguma coisa
Este texto traz praticamente a mesma mensagem do post anterior
Também foi discutido na discussão anterior no HN
Por outro lado, às vezes ‘doing the thing’ em si é a escolha errada
Por isso eu ainda insisto em documentos de design e code review
Na era do GenAI, ficou fácil demais “só sair fazendo sem planejar”, então é preciso um contrapeso
Acaba-se gastando todo o tempo com problemas de não determinismo e latência, e no fim o verdadeiro desafio é acertar a economia unitária
Em Remains of The Day, falar apenas sobre the thing é chamado de ato de autossatisfação
Muitas vezes isso vira só uma conversa que faz a pessoa se sentir bem, sem realizar nada de fato
Por outro lado, planejamento, preparação e mise-en-place podem ajudar na execução real