El espejismo de la productividad

• El legendario ingeniero de Facebook Bob lanzó Facebook Groups y logró resultados en hackatones una y otra vez, incluso sin un entorno de desarrollo sofisticado
• Usaba solo Sublime Text básico y logs con printf; el resaltado de sintaxis era impreciso y no tenía live reloading ni depurador
• En cambio, los desarrolladores a su alrededor consideraban que una configuración compleja de herramientas —resaltado de sintaxis y snippets en Vim, tmux, mosh, atajos de hphpd, alias de Git, etc.— era la clave de la productividad
• En las victorias de Bob en hackatones pesaron más su criterio e intuición de producto, es decir, su capacidad para decidir qué construir, que la configuración del editor
• Aunque nuevas formas de trabajo pueden generar cambios, el rendimiento final proviene de resolver el problema correcto

---

La diferencia entre herramientas complejas y resultados reales

• Bob era un ingeniero prolífico que lanzó Facebook Groups y una figura legendaria que entregaba resultados en hackatones de forma consecutiva
• Un colega obsesionado con la productividad en ese entonces usaba resaltado de sintaxis y snippets personalizados en Vim para Hack, el dialecto de PHP de Facebook
  • Ejecutaba tmux sobre mosh y tenía configurados atajos personalizados de hphpd y alias de Git
• La forma de trabajar de Bob, en contraste, era muy simple
  • Usaba Sublime Text sin configuración adicional, por lo que cerca de la mitad de los colores del código se mostraban mal
  • En lugar de live reloading o un depurador, insertaba printf en el código y esperaba a que aparecieran los logs
• Ese día, Bob ganó el hackatón; se recuerda que su proyecto era una función para permitir publicaciones de compra y venta en Facebook Groups
  • Esa función luego evolucionó hasta convertirse en Facebook Marketplace

Qué construir, más que cómo hacerlo

• Si uno se enfoca en herramientas complejas, puede quedar atrapado en el cómo, la forma de trabajar, y perder de vista el qué, el objeto del trabajo
• La clave de la alta productividad de Bob no era la configuración del editor, sino su criterio e intuición de producto
• En X aparecen todos los días nuevas formas de trabajar que parecen capaces de cambiarlo todo, y algunas de ellas quizá sí puedan producir cambios reales
• Sin embargo, lo más importante no son las herramientas ni la forma de trabajar en sí, sino resolver el problema correcto

[GN⁺]

Comentarios en Hacker News

• Es un error dividir entre el artesano que no escatima en herramientas y la persona obsesionada con ellas. Las buenas herramientas no son juguetes, sino medios para un fin, y yo también he pasado varios días creando scripts de shell, funciones de Emacs y herramientas de organización de ventanas adaptadas a mi flujo de trabajo
  Como resultado, el resaltado de sintaxis, la navegación y análisis de código, la disposición de la pantalla y la manipulación de Git quedaron al alcance de unas cuantas pulsaciones, y desaparecieron los elementos que rompían mi concentración. Vale la pena invertir en tu entorno de trabajo, como la silla, el prompt del shell o el editor, pero una vez que te sientas cómodo, hay que olvidarse de eso y concentrarse en el problema real
  Aun así, ajustar herramientas sin fin puede ser una señal de que estás evitando tareas pesadas y poco divertidas, y no es algo tan simple como echarle la culpa a las herramientas

  • ¿Qué harías si en un nuevo trabajo te dieran un nuevo stack tecnológico y una laptop con Windows? Al inicio de mi carrera aprendí a trabajar de forma eficiente solo con las herramientas básicas del entorno que me tocaba, y en realidad rara vez podía elegir mis propias herramientas. Las herramientas multiplataforma también suelen ser poco consistentes, salvo la línea de productos de JetBrains
  • Se parece a la diferencia entre samuráis y ninjas. Los samuráis veían la espada como una extensión de su alma, pero los ninjas, si hacía falta, también la usaban para forzar y abrir cosas. En la economía actual, la visión samurái de las herramientas no encaja
  • Es importante disfrutar el uso de las herramientas. Aunque la productividad no se multiplique por 10, lo clave es poder concentrarte en el trabajo y disfrutar el proceso
    Sobre todo en la era de los LLM, las herramientas te hacen ir y venir constantemente entre varios agentes y terminales. Estos cambios de contexto frecuentes te quitan el disfrute y el estado de concentración, así que ojalá alguien encuentre una solución
  • Parece que muchos principiantes se saltan pasos porque quieren ser reconocidos y tomados en serio. Parecerlo y realmente llegar a serlo son cosas distintas, y mientras construyes habilidades también tienes que ganarte la vida
  • Después de dominar una técnica, las buenas herramientas en sí mismas se vuelven un gran placer. Por otro lado, una persona experta a veces puede lograr resultados sorprendentemente buenos incluso con herramientas inadecuadas

• He visto a muchos técnicos dedicar más tiempo a la optimización de la configuración del entorno que a crear cosas de verdad, y yo también he pasado por eso. Pensar que, como el 90% del tiempo de programación es escribir, hay que aumentar la velocidad de entrada, es un error; el 90% del tiempo debería dedicarse a pensar, y la mayor parte de eso, a leer

  • El software es una solución concretada para un problema, así que primero hay que definir qué problema se va a resolver. El código es una instantánea que muestra a todos, incluido tu yo futuro, tu nivel actual de comprensión del problema y qué tan clara y adecuada es la solución
    En el momento adecuado, programar es más bien teclear para concretar una solución que ya entendiste
  • Antes me obsesionaba con la configuración, pero desde que uso AI estoy creando cosas geniales que antes no habría podido hacer. En cambio, mi comprensión del código base y mis habilidades previas se van debilitando poco a poco, y aunque me asombran las técnicas nuevas, siento que no las aprendo a fondo
    En ese sentido, la AI también es otra forma de mejora del entorno, porque bajó la barrera de entrada al empezar. Cuando antes viajaba por Europa estudiando InterviewCake para pasar de un rol de QA a desarrollador, también desperdiciaba más tiempo afinando el editor que resolviendo problemas
    Tal vez esto sea un síntoma de TDAH. Después de un tratamiento reciente con medicamentos, mi productividad cambió muchísimo, y casi me hizo llorar pensar que había desperdiciado la mitad de mi vida intentando perfeccionar la configuración en vez de hacer el trabajo real
  • Hay una brecha entre la productividad real y la productividad percibida. Moverse con soltura por el código usando Vim o Emacs te hace sentir como hacker, pero eso no significa que seas productivo. Incluso si diriges decenas de agentes de AI con una enorme cantidad de tokens, no hay garantía de que el resultado funcione o resuelva el problema
  • No estoy seguro de que para la mayoría de los desarrolladores de aplicaciones CRUD comunes sea correcta esa proporción de dedicar el 90% del tiempo a pensar y leer
  • Pensar y teclear suelen ocurrir al mismo tiempo. A mucha gente le resulta más fácil razonar sobre un problema mientras escribe y modifica código, y esa también es una razón por la que la comprensión del código puede bajar mucho incluso si lees completo el código generado por un LLM

• Existen empresas financiadas por VC que no logran crear productos que la gente realmente use o por los que pague. Para justificar su valuación, muestran qué tan ocupadas y productivas están, y el furor por la AI podría ir en la misma línea al enfocarse solo en la productividad y en los métodos, más que en qué se va a construir
  https://components.news/the-gamer-and-the-nihilist/ compara este tipo de startups nihilistas con estudios de videojuegos que sí crean productos por los que la gente paga y que usa. En una economía donde las apps de productividad representan casi el 40% de los resultados de Product Hunt, a veces se invierte trabajo en parecer que se crea algo más que en crear algo real

  • Los desarrolladores de videojuegos también dedican un esfuerzo enorme a crear herramientas, solo que su objetivo principal no son los editores de texto
  • Me pregunto dónde encajan en esta analogía las personas que pasan incontables horas creando el entorno perfecto para jugar en vez de jugar, o los audiófilos que pasan la vida buscando el equipo perfecto en vez de escuchar música
  • Más que una burbuja, esto se parece a una vieja y repetida forma de manipular señales. Siempre ha existido y seguirá existiendo

• Solo hago o uso herramientas de productividad lo suficiente como para no quedarme atrás, y todo lo que va más allá lo veo como una trampa. Antes las revisaba una vez por trimestre, pero desde la llegada de la AI ahora paso 1 o 2 días a la semana en ese trabajo meta de mejorar herramientas, aunque espero que eso disminuya cuando las herramientas relacionadas se estandaricen
  Si se te pega demasiado la imagen de experto en herramientas, no solo puedes perder de vista el trabajo realmente valioso, sino que además la gente puede verte como alguien con secretos misteriosos de productividad. Si la diferencia no resulta tan grande como esperan, podrían dejar de confiar incluso en tus otros juicios

• Mientras menos tiempo pasaba frente a la computadora, más cosas resolvía, y cuando reduje mis monitores de 3 a 1 mi productividad subió mucho. Resuelvo la mayoría de los problemas mientras pico verduras o corto el césped; no por sentarte frente a tecnología brillante vas a tomar decisiones más rápidas o mejores
  Si obtengo mejores resultados que los equipos de desarrollo de mis clientes, también es porque no soy empleado de planta y puedo detenerme lo suficiente para pensar con calma. Mucho teatro de productividad, como la presión de mantener en verde el estado de Teams, termina provocando decisiones absurdas en muchas organizaciones

  • Durante 15 años trabajé en dos empresas con oficinas sobre acantilados con vista al mar en La Jolla, California. Pensaba en el trabajo caminando por los acantilados y el parque, y si había una conversación seria que no necesitaba pizarrón, le proponía a un colega salir a caminar. Vale la pena volver a escuchar la hammock talk de Rich Hickey
  • Por el nombre de usuario, me pregunto si será Bob, el que aparece en el texto

• Pensando en por qué existe la productividad, llegué a la hipótesis de que es un intento de reducir el dolor. Muchas optimizaciones de rendimiento, incluida la productividad de los programadores, a menudo se vuelven una vía de escape para ingenieros que quieren evitar el dolor de la ambigüedad del dominio del problema, la política organizacional, la falta de claridad o el riesgo de fracasar
  Pero para resolver problemas reales hay que enfrentarse a la realidad: revisar con un nivel casi tedioso de detalle el flujo de trabajo del usuario, proponer con claridad una estrategia común para conseguir la cooperación de otros, etc. No hace falta glorificar el dolor en sí, pero los buenos resultados llevan dentro un entrenamiento casi atlético, y hay que desarrollar la capacidad de manejar el dolor necesario en la cancha

• La clave está en qué tan fácil es recibir reconocimiento. Cualquiera puede ver y admirar una herramienta brillante, pero son pocos los que pueden reconocer un gran producto o una gran función nueva en un editor vacío o en código esqueleto. Por eso la atención se concentra en herramientas visibles, mientras se ignora la difícil e incierta cuestión de qué construir
  A las herramientas les aplico un criterio tipo Marie Kondo. Si no es agradable usarlas ni me facilitan la vida, las descarto; si sí, las mantengo

• En 2004, un pequeño equipo compuesto en su mayoría por desarrolladores junior recibió una formación excelente y extensa en Java. Antes de la capacitación, discutían intensamente y con obsesión sobre la configuración de IntelliJ y Eclipse, pero el instructor, de forma sorprendente, recomendó usar solo las herramientas básicas del JDK y Notepad
  El objetivo era que aprendieran lo que pasaba por dentro, y también decía que probablemente la productividad no sería tan distinta

• La razón por la que uno se obsesiona con optimizar el entorno es que la relación entre el esfuerzo enfocado y la recompensa es visible, concreta y física. En cambio, el aprendizaje abstracto no lo es. Hay muchas más tareas de aprendizaje que sillas por optimizar, así que ojalá hubiera una forma de hacer que el aprendizaje abstracto también se sintiera más concreto

• No se trata de productividad, sino del placer de jugar con juguetes