- Solo la acción en sí es ejecución real; pensar o prepararse no es ejecutar.
- Se recalca repetidamente que planear, aprender, debatir o comprar herramientas no es “hacer el trabajo”.
- Solo el acto de intentarlo directamente, incluso si sale mal o se hace con torpeza, se considera ejecución real.
- Empezar aunque sea en pequeño es importante, y no hace falta una preparación perfecta ni condiciones ideales.
- Es un texto que recuerda que la actitud de pasar a la acción real es el núcleo de la creación y el desarrollo.
La diferencia entre ejecutar y no ejecutar
- El texto enumera que “pensar, soñar, visualizar, prepararse” y demás no son ‘hacer el trabajo’.
- Ejemplos: “pensar”, “soñar”, “imaginar el éxito”, “esperar hasta estar listo”, etc.
- Hablar, explicar o discutir tampoco se considera ejecución.
- Incluye “explicárselo a otras personas”, “discutir en línea”, “anunciar que vas a empezar”.
La trampa de la preparación y del consumo
- Escuchar podcasts, ver tutoriales, leer casos de otras personas no es ejecutar.
- Diseñar un sistema perfecto, comprar herramientas o acomodar el espacio de trabajo tampoco se considera ejecución.
- Consolarse con la culpa o con sentirse ocupado tampoco es acción real.
Cómo se ve la ejecución real
- Hacerlo fallando, hacerlo con torpeza, hacerlo aunque sea en pequeño: todo eso sí cuenta como ‘hacer el trabajo’.
- Aunque no sea perfecto, lo importante es realmente poner manos a la obra.
- Hacia el final, el texto menciona que “incluso escribir un blog no es hacer el trabajo”, y presenta una conclusión autorreflexiva.
Mensaje clave
- Solo la acción es ejecución real; todo lo demás no deja de ser un sustituto de ejecutar.
- Empezar aunque sea en pequeño, aceptar el fracaso e intentarlo directamente es la única forma de avanzar.
- La última frase, “Ahora tengo que volver al trabajo”, simboliza una actitud de acción inmediata.
2 comentarios
Es una buena frase para personas como yo, a quienes se les dificulta ejecutar bien las cosas.
Comentarios en Hacker News
El principio de “hacerlo mal” cambió por completo mi forma de pensar
Pasé semanas intentando diseñar la arquitectura perfecta, pero al final dejé de planear y construí una versión tosca que resolvía mi problema
Lo sorprendente fue que esa primera versión me enseñó cosas que nunca habría aprendido solo con la planificación. Aprendí qué les importa de verdad a los usuarios, qué casos límite importan en la práctica y qué significa realmente “lo suficientemente bueno”
Lo más difícil fue permitirme desplegar algo sabiendo que tenía defectos. Pero el ciclo de retroalimentación del uso real valió muchísimo más que semanas de discusiones hipotéticas
Hoy en día este tipo de publicaciones abundan en subreddits de productividad. Me cuesta creer que sea realista pasar semanas planeando la arquitectura mientras construyes una herramienta de automatización personal
Si ves el historial de comentarios del autor, repite un estilo muy parecido y no inspira mucha confianza
Ver ese proceso fue realmente fascinante
En el proceso de implementar de verdad y refactorizar se aprende muchísimo sobre el problema y sobre programación en general
Casi todas las abstracciones iniciales están mal. A medida que implementas, la estructura cambia por completo y al final termina saliendo un código hermoso totalmente distinto del inicial
La idea es construir la primera versión asumiendo que la vas a tirar, aunque en la práctica casi nunca se tira y más bien se mejora de forma iterativa
Ahora, gracias a las herramientas y los procesos, podemos seguir iterando continuamente
La estructura interna también necesita iteración y prototipado, pero cosas como estructuras de datos, manejo de errores, logging y naming conviene decidirlas con cuidado desde el principio para poder mejorar rápido más adelante
Me gusta la frase “Doing it badly is doing the thing”
Es una lección que aprendí en HN: cuando te atoras, lo importante no es obsesionarte con hacerlo perfecto, sino empezar de una vez
Aunque al principio salga fatal, si lo vas mejorando poco a poco, de pronto aparece una imagen clara. Parece magia
Uno es el consejo de Dan Harmon sobre el bloqueo del escritor, y
el otro es “The Gap” de Ira Glass
La idea central es no esperar a la perfección, sino escribir aunque sea un borrador pésimo y luego corregirlo con ojo crítico
Por eso últimamente digo a propósito “todavía no está listo” hasta que de verdad quede terminado
Yo primero construyo algo rápido, luego lo pulo y al final lo vuelvo a escribir desde cero
Lo importante es no caer en el perfeccionismo durante la etapa beta
Si la mejora incremental de verdad funciona, entonces da igual si la hace un humano o una IA
En una empresa anterior llamábamos a la gerencia la “sociedad de admiración del problema”
Se dedicaban a discutir el problema, analizarlo y buscar culpables, pero no a resolverlo de verdad
Al final, lo que importa es “hacerlo realmente”
El mejor enfoque es combinar el cariño por el problema con la voluntad de resolverlo de manera iterativa
El dogfooding interno es una buena forma de mantener ese equilibrio
Es importante decidir, en la medida de lo posible, en la dirección que más te favorezca
Hay menos coordinación solo para actualizaciones y la organización que realmente trabaja se vuelve más eficiente
Este texto es muy parecido al ensayo de strangestloop.io
Al ver el título me pareció familiar, pero al hacer clic vi que era otro sitio y me sorprendió que se hubiera publicado hace apenas unos días
El contenido es demasiado parecido como para pensar que sea coincidencia
Antes pensaba que la preparación era importante, pero en algún momento me di cuenta de que prepararse puede convertirse en un ciclo infinito
Nuestro equipo terminó un producto en cuatro meses con una especificación de dos páginas, mientras que el equipo rival pasó ocho meses escribiendo documentos y terminó desmantelado
Con un 20% de planificación ya resuelves el 80% de los problemas. Después de eso, lo demás suele ser solo rigidez disfrazada de ansiedad
Al final, casi todo lo aprendí sacando algo vergonzoso y corrigiéndolo sobre la marcha
Está citada en este comentario anterior de HN
La parálisis por análisis existe de verdad
Para no quedarte detenido, hay que empezar aunque sea. Resuelve primero el happy path y después afina los casos límite
Hoy el costo de hacer prototipos es bajo, así que hay que intentarlo sin miedo al fracaso
Esa es precisamente la razón por la que los LLM resultan tan sorprendentemente eficaces: ejecutan de inmediato en lugar de quedarse analizando
Aunque el resultado no sea perfecto, suele ser suficientemente útil, y si hace falta ya se optimiza después
Antes de crear un framework, deberías construir al menos tres sistemas reales. Solo así sabrás qué partes sobran y cuáles faltan
Decir “está suficientemente bien” puede convertirse en autoengaño
Que un prototipo haya fracasado no demuestra que no exista mercado. Solo es una señal de que faltó algo
Este texto transmite casi el mismo mensaje que esta publicación anterior
También se discutió en un hilo anterior de HN
Por otro lado, a veces “doing the thing” en sí mismo es la elección equivocada
Por eso yo sigo insistiendo en los documentos de diseño y las revisiones de código
En la era de la GenAI se volvió demasiado fácil “probar a lo bruto sin planear”, así que hace falta más contrapeso
Uno termina gastando el tiempo en la no determinación y la latencia, y al final el verdadero reto es lograr una economía unitaria que cierre
En Remains of The Day, a “hablar del thing sin hacer nada” se le llama un acto autocomplaciente
Muchas veces se queda en una conversación que te hace sentir bien sin lograr absolutamente nada en la práctica
Por otro lado, la planificación, la preparación y el mise-en-place sí pueden ayudar a la ejecución real