- Según estudios de psicología cognitiva, el límite del trabajo profundo (deep work) en los humanos es de 3 a 4 horas al día, y después de eso la concentración y la calidad del código caen de forma drástica
- Un análisis de más de 250 mil desarrolladores mostró que la mediana del tiempo real de programación es de apenas 52 minutos al día, mientras que el resto se consume en reuniones, gestión y colaboración
- Después de una interrupción, volver a la tarea original toma 23 minutos; en el caso de los programadores, recuperar todo el contexto requiere entre 30 y 45 minutos
- En estado de flujo (flow state) la productividad aumenta un 500%, pero entrar en él requiere entre 15 y 25 minutos seguidos de concentración continua
- El rol del engineering manager no debería centrarse en agregar procesos, sino en eliminar distractores y proteger el tiempo de trabajo profundo
Límite cognitivo: el trabajo profundo tiene un tope de 4 horas al día
- Cal Newport define el trabajo profundo como una "actividad profesional realizada en un estado de concentración sin distracciones que lleva la capacidad cognitiva hasta su límite", y para la mayoría de las personas el máximo promedio es de 4 horas al día
- En el estudio de violinistas de K. Anders Ericsson también se comprobó que, tras 4 horas de práctica concentrada, aparece la fatiga
- El desarrollo de software también es trabajo cognitivo de alta intensidad, porque incluye resolución creativa de problemas y diseño de sistemas, así que después de 3 a 4 horas aparecen rendimientos decrecientes
- El matemático Henri Poincaré trabajaba 2 horas por la mañana y 2 por la tarde; G.H. Hardy trabajaba solo por la mañana; Charles Darwin, B.F. Skinner y C.S. Lewis también mantenían horarios de 3 a 4 horas de trabajo
- Según una investigación de Gloria Mark en UC Irvine, el tiempo promedio actual de atención sostenida en pantalla es de 47 segundos, una fuerte caída frente a los 2.5 minutos de 2004
Cómo usan realmente su tiempo los desarrolladores
- Según un análisis de más de 250 mil desarrolladores de Software.com, la mediana del tiempo de programación es de 52 minutos al día (unas 4 horas y 21 minutos por semana)
- Solo el 10% de los desarrolladores programa más de 2 horas al día, y el 40% más de 1 hora
- Según un análisis de 1.5 millones de reuniones de Clockwise, los ingenieros de software pasan en promedio 10.9 horas semanales en reuniones
- Los engineering managers pasan 18 horas por semana en reuniones, casi la mitad de una semana laboral de 40 horas
- Los desarrolladores en organizaciones grandes gastan 12.2 horas semanales en reuniones; en organizaciones pequeñas, 9.7 horas
- Si se excluyen reuniones, gestión, code review y colaboración, quedan 19.6 horas semanales potenciales de concentración, pero en su mayoría están fragmentadas en bloques cortos imposibles de aprovechar
- El 45% de toda la programación ocurre entre las 2 p. m. y las 5 p. m., mientras que entre las 9 a. m. y las 11 a. m. apenas ocurre el 10%
- No es que los desarrolladores sean naturalmente más productivos por la tarde, sino que la mañana queda invadida por standups, syncs y ceremonias
El alto costo de las interrupciones
- Según la investigación de Gloria Mark, después de una interrupción se necesitan exactamente 23 minutos y 15 segundos para volver por completo a la tarea original
- En un estudio del Georgia Institute of Technology, en programadores se requieren de 10 a 15 minutos para retomar la edición de código y de 30 a 45 minutos para reconstruir todo el contexto mental
- En su ensayo sobre el "maker schedule", Paul Graham explica que una reunión no es solo un cambio de tarea, sino una excepción que cambia el modo de trabajo completo
- Una sola reunión puede destruir toda la tarde, y el simple hecho de tener una reunión programada en la tarde hace que uno evite empezar trabajo ambicioso por la mañana
Estado de flujo: el multiplicador de productividad de los programadores
- Mihaly Csikszentmihalyi define el estado de flujo como un "estado en el que uno está completamente inmerso en la actividad misma, desaparece el yo y se pierde la noción del tiempo"
- Tras 10 años de investigación, se confirmó un aumento del 500% en productividad en estado de flujo frente al estado normal
- La clave para entrar en flujo es el equilibrio entre desafío y nivel de habilidad; si el desafío es demasiado alto o demasiado bajo, se interrumpe el flujo
- Los equipos de software que experimentan flujo con frecuencia entregan más valor, más rápido y con mayor satisfacción
- El flujo no aparece por sí solo; es indispensable protegerlo de los factores que lo consumen
Cómo entrar en flujo mientras programas
- Crear un entorno sin interrupciones: cerrar Slack, silenciar notificaciones y usar un indicador visible de estado para avisar que estás en modo de trabajo profundo
- Incluso si no respondes a las notificaciones, verlas ya reduce la concentración
- Definir un objetivo claro antes de cada sesión de código: no "trabajo de backend", sino algo específico como "corregir el endpoint de autenticación para que devuelva respuestas de error adecuadas"
- Resolver los problemas difíciles en tu pico cognitivo: según estudios de ritmos circadianos, el rendimiento cognitivo varía entre 9% y 40% según la hora del día
- Para la mayoría de los adultos, el mejor momento para resolver problemas es entre las 10 a. m. y las 2 p. m.
- Las personas de tipo matutino ("alondras") y vespertino ("búhos") tienen picos distintos, así que hace falta proteger el horario pico individual
- Time blocking para un maker schedule: reservar en el calendario bloques de 2 a 4 horas para trabajo profundo y concentrar las reuniones al final del día o en días específicos
- Definir un objetivo por cada bloque de trabajo y dividirlo en tres tareas accionables
- Eliminar el cambio de contexto: en lugar de responder al instante, establecer dos ventanas de comunicación al día y cerrar las pestañas del navegador que no tengan relación con la tarea actual
- Trabajar por sesiones enfocadas, no por sprints maratónicos: un Pomodoro de 25 minutos no encaja bien con trabajo de desarrollo complejo, porque el temporizador suele interrumpirte justo cuando empiezas a entrar en flujo
- El objetivo no es el máximo tiempo posible, sino la máxima calidad dentro de los límites de la capacidad cognitiva
- El efecto compuesto de la reflexión y el aprendizaje: en los estudios de práctica deliberada de Ericsson, lo que construye expertise no es el tiempo invertido, sino el pensamiento reflexivo
Las 4 estrategias de trabajo profundo de Cal Newport
- Estrategia monástica (Monastic): eliminar por completo el trabajo superficial
- El caso representativo es Donald Knuth, que eliminó el email en 1990
- Estrategia bimodal (Bimodal): dividir la semana entre días de trabajo profundo y días de trabajo superficial
- Por ejemplo: de lunes a miércoles incomunicado; jueves y viernes para reuniones y correo
- Estrategia rítmica (Rhythmic): hacer trabajo profundo todos los días a la misma hora, sin excepciones
- El enfoque de Jerry Seinfeld de "no rompas la cadena"
- Estrategia periodística (Journalistic): entrar de inmediato en trabajo profundo cada vez que aparece un hueco libre
- Puede aprovecharse incluso en bloques de 30 a 45 minutos, pero en la práctica existe el riesgo de confundir el cambio de contexto con trabajo profundo
- Para la mayoría de los desarrolladores, la estrategia rítmica es la más efectiva, y la clave es reservar la mañana para programar sin caer en la tentación reactiva de Slack
Por qué esto debería importarle a un engineering manager
- Si el tiempo real diario de programación de un desarrollador es de 52 minutos, y una sola interrupción consume más de 23 minutos de recuperación, entonces un solo mensaje puede comerse casi la mitad de la cuota diaria de programación
- Experimento de TechSmith: al eliminar por completo las reuniones, la percepción de productividad aumentó un 15%, y el 85% de los empleados dijo que reemplazaría las reuniones por comunicación asíncrona
- En una encuesta de Microsoft a 31,000 personas, las reuniones ineficientes fueron el factor número uno que más perjudica la productividad laboral
- Recomendaciones para managers:
- Asegurar mañanas sin interrupciones
- Introducir no meeting days (por ejemplo, miércoles)
- Hacer que la comunicación asíncrona sea la opción por defecto en lugar de la síncrona
- Fijar plazos realistas que dejen margen para la exploración creativa
- Métricas para medir el efecto: reducción del cycle time, satisfacción del equipo, puntajes de engagement y métricas de calidad como tasa de bugs y retrabajo
Conclusión
- Las 3 a 4 horas diarias de programación profunda no son un problema de hábito, sino un límite físico de la carga cognitiva
- La clave es optimizar los factores controlables, como apagar notificaciones, avisar al equipo que responderás por la tarde o negociar no tener reuniones matutinas dos veces por semana
- 4 horas de trabajo profundo siempre producen mejores resultados que 8 horas de "semi-concentración"
- Entrar en estado de flujo durante varias horas al día lleva a código de alta calidad, menor riesgo de bugs, soluciones innovadoras y mejor equilibrio entre vida y trabajo
- Los programadores no son sprinters, sino corredores de maratón, y necesitan conservar su energía
Nota sobre los asistentes de programación con IA
- Herramientas como Copilot, Cursor o Claude no amplían el tiempo de trabajo profundo, solo cambian el foco
- Revisar la salida de la IA en lugar de escribir código desde cero sigue requiriendo el mismo contexto, criterio y concentración
- El límite de 3 a 4 horas no depende de la velocidad de tipeo, sino del límite del cerebro para sostener decisiones de alta calidad, así que no cambia porque el código aparezca más rápido
- Donde la IA sí ayuda de verdad es en las horas superficiales (shallow hours): borradores de documentación, generación de boilerplate, consultas sobre uso de librerías, etc.
- Delegar esas tareas a la IA permite reservar el presupuesto de trabajo profundo para el pensamiento arquitectónico y la resolución de problemas complejos
- La trampa está en usar IA para producir más código del que puedes procesar mentalmente
- El objetivo no es escribir más líneas de código al día, sino concentrar los recursos cognitivos limitados en las decisiones más importantes
13 comentarios
La comparación en sí misma está mal planteada.
El estudio sobre violinistas de K. Anders Ericsson no se basó en personas ya dominantes, sino en la práctica. En el caso de un instrumento, aunque practiques una pieza perfectamente, eso no garantiza siempre una interpretación perfecta (hay excepciones en cada ejecución). En cambio, en desarrollo, las necesidades son claras y, una vez terminado, siempre produce el mismo resultado. Hay una diferencia muy grande entre hacer de forma continua algo que tiene fin y hacer de forma continua algo que no lo tiene. Por eso, incluso fijar que la capacidad cognitiva humana es en promedio de 3 a 4 horas ya es problemático; además, también hay otra diferencia entre programar 3 a 4 horas por indicación de otros y hacerlo voluntariamente durante 3 a 4 horas. Este texto me parece uno que generaliza todo para persuadir de forma verosímil de que 3 a 4 horas es el límite de la capacidad cognitiva humana. Que el tiempo de concentración de ellos sea de 3 a 4 horas no significa que el de todos también lo sea. Más bien, parece un texto que fija de antemano un límite para decir “trabajemos solo 3 o 4 horas” y ponerse de acuerdo en eso.
¡Exacto~! En realidad hay mucha gente que hace muy bien su trabajo.
Ojalá la gente no se definiera a sí misma diciendo “yo soy este tipo de persona” a partir de su pico de rendimiento y concentración de toda su carrera. Este texto pone el trabajo profundo como un estado ideal y se esfuerza demasiado por entrar en él. Obviamente, cuando aparecen ideas interesantes para resolver un problema y se ve una dirección clara para probar cosas, surge ese trabajo profundo y la productividad mejora. Pero si eso no aparece y aun así uno vive creyendo que en realidad su cerebro es más genial que esto, y siempre inconforme, al final solo va a reducir mucho más la probabilidad de entrar en “flow”. Cuanto menos metacognición tengas, más fácil es pensar que tu cerebro te pertenece solo a ti, pero ese estado mental nunca lo construyes por tu cuenta. Hay que reconocer la ayuda del entorno que hizo posible esa concentración (no solo que te dejaran tranquilo o te dieran dinero, sino también que recibieras distintos estímulos y que, en algún momento, ocurriera ese evento en que todo eso se articula con precisión en una sola dirección; eso también es el estado de concentración). Sea cual sea el resultado, guardar una gratitud interna y, sin necesidad de expresársela a otros, sentirse razonablemente satisfecho y afirmarse a uno mismo ayuda a mejorar a largo plazo la concentración y la condición mental.
Trabajo en una empresa donde trabajamos 3 horas por la mañana, almorzamos y luego volvemos a trabajar otras 3 horas por la tarde (7 horas en total, 4 días a la semana). Incluso con solo eso, mentalmente se siente mucho más llevadero.
¡Es una buena empresa!
Ahora entiendo por qué me iba tan bien cuando programaba solo después de salir del trabajo, cuando ya no quedaba nadie... ;;;
Por eso, cuando los demás se quedan haciendo horas extra, yo más bien me voy temprano.
Creo que con entrenamiento, descanso y un entorno adecuado se puede aumentar un poco más, pero al final es exprimir a la gente y es difícil aguantarlo por mucho tiempo. Las empresas empujan para exprimirte y lo mantienen en silencio, pero también he visto con cierta frecuencia a técnicos que trabajan tomando medicamentos (antidepresivos, medicamentos para el TDAH).
Sí, es cierto: que a los consultorios de psiquiatría les vaya bien en Pangyo es una verdad incómoda.
Creo que una hora al día de programación es suficiente. Incluso antes de la IA, en realidad no pasábamos tanto tiempo programando, y ahora ese tiempo se ha reducido todavía más.
Parece que cuando se trata de desarrollar algo, jugar o leer
lo que yo quiero hacer, uno puede concentrarse durante horas, hasta terminar esa actividad.Aquí, esas 4 horas probablemente se refieren a la capacidad de concentración para trabajos que
no quieres hacer pero haces porque es tu profesión(¿sería algo así como concentración pasiva?).Simple. Cualquier hombre probablemente ha tenido la experiencia de mantener la concentración toda la noche mientras juega.
Por experiencia personal, cuando desarrollo algo que realmente quiero hacer, aunque siga durante varias horas seguidas, no siento que me canse tanto.
El simple hecho de ejecutar múltiples sesiones también se convierte en multitarea, lo que probablemente reduce la concentración.