TDAH y carrera IT: ventajas reales y dificultades concretas

TDAH y carrera IT es una combinación que se ve en cualquier oficina técnica de Madrid o Barcelona y en cualquier canal de Slack remoto: una proporción de developers, devops, data, QA y product manifiestamente más alta que la prevalencia de TDAH en la población general. Cuando llevas tres horas debuggeando un fallo extraño, te metes en un flow tan denso que olvidas comer, y al día siguiente no consigues abrir Jira para mover una tarjeta a “Done”, no eres “raro”: estás en un sector que premia tu hiperfoco y castiga tus puntos débiles, todo a la vez. Tech ofrece ventajas concretas (problem solving rápido, ambientes menos jerárquicos, remoto, novedad constante), pero también trampas específicas: standups, sprints, code reviews que activan rejection sensitivity, context switching, burnout acelerado. En este artículo vemos qué hay de cierto en la “ventaja TDAH en IT”, qué dificultades son reales y qué estrategias funcionan de verdad.

Por qué tantos cerebros TDAH acaban en tech

No hay un censo oficial de developers con TDAH en España, pero la sobrerepresentación es lo bastante visible para que los principales podcasts del sector la mencionen como dato cultural. Los motivos son claros si miras qué busca un cerebro TDAH y qué ofrece tech.

El TDAH adulto se asocia con alta búsqueda de novedad (sensation-seeking) y patrones cognitivos no lineales. La revisión de Wiklund, Yu, Tucker y Marino (2017) en el Journal of Business Venturing mostró que los síntomas de hiperactividad pueden tener efectos positivos en contextos emprendedores, mediados por la dimensión sensation-seeking de la impulsividad. Tech, sobre todo en scaleups, recompensa exactamente eso.

Otros factores:

Problem solving con feedback rápido. Compilas, ves si funciona. Es dopamina limpia, no diferida tres meses como un informe corporativo.
Jerarquías planas. Un junior puede contradecir a un staff engineer si el código lo justifica. La rigidez jerárquica para un cerebro TDAH es asfixiante.
Trabajo remoto. Te ahorras open spaces ruidosos y eliges cuándo entrar en deep work.
Hiperfoco monetizable. Pasar ocho horas seguidas resolviendo un bug raro en otras profesiones se llama “obsesión malsana”. En IT te suben el sueldo.

Las ventajas reales (no las de LinkedIn)

Algunas ventajas TDAH-en-tech son genuinas, no marketing motivacional. Vale la pena distinguirlas de los superpoderes inventados.

Hiperfoco para deep work técnico

El hiperfoco es atención sostenida que no se desengancha fácilmente, según la definición operativa propuesta por Ashinoff y Abu-Akel (2021) en Psychological Research. Para un developer en una arquitectura compleja, eso significa mantener en cabeza un grafo grande de dependencias durante horas.

Hupfeld, Abagis y Shah (2019) encontraron en una muestra de adultos con sintomatología TDAH alta una mayor frecuencia disposicional de hiperfoco a través de estudio, hobbies y screen time. Traducción práctica: si tu trabajo es básicamente “screen time intencional sobre un problema interesante”, el rasgo te ayuda más que te perjudica, siempre que el problema sea genuinamente interesante para ti.

Cuidado: hiperfoco no es flow. El flow de Csikszentmihalyi (1975) es voluntariamente activado y termina rejuvenecedor; el hiperfoco TDAH es involuntario y suele terminar en crash, dolor de espalda y olvido de comer. Si lees más sobre esto, hay una pieza dedicada en TDAH e hiperfoco: ventaja real o trampa.

Debugging como pattern matching no lineal

El debugging real (no el de los manuales) es saltar entre niveles de abstracción, recordar un detalle aparentemente irrelevante visto tres semanas antes, conectar puntos que un cerebro lineal no conectaría tan rápido. El TDAH no es solo déficit; es también un estilo cognitivo divergente que en algunos contextos funciona mejor que el lineal.

La revisión de Hervey, Epstein y Curry (2004) en Neuropsychology, sobre 33 estudios neuropsicológicos en adultos con TDAH, mostró un perfil de impairment selectivo (no global): tiempo de reacción simple normal, déficits específicos en inhibición y working memory. Eso significa que la “potencia de proceso bruta” no está reducida — está distribuida de forma distinta. Para tareas que requieren explorar muchas hipótesis en paralelo (debugging, troubleshooting de prod, refactor), esa distribución es una ventaja.

Novelty seeking en un sector que cambia cada seis meses

En el 90% de las profesiones, lo que aprendiste hace diez años sigue siendo el 80% de lo que necesitas. En tech no: cada año hay un framework JS nuevo, una base de datos vectorial, un protocolo, una práctica de despliegue. Para cerebros que se aburren rápido, esto es perfecto.

Trabajo remoto: control sobre el entorno

Un cerebro TDAH es muy sensible al entorno (ruido, interrupciones, presencia). El remoto bien hecho es probablemente la mayor mejora de calidad de vida laboral para muchos developers neurodivergentes en los últimos años. Si quieres profundizar, hay un artículo específico sobre el entorno de trabajo y el foco TDAH.

Las dificultades reales (las que no aparecen en los carteles)

Aquí es donde el discurso “TDAH = superpoder en tech” se rompe. Las dificultades son específicas, sistemáticas y poco comprendidas por los managers.

Standups, Jira y la fatiga del ceremonial ágil

Las metodologías ágiles asumen un cerebro que tolera bien la fragmentación: standup, refinamientos, plannings, retros, bilateral síncrono con producto. Para un cerebro TDAH, cada cambio de contexto es un coste cognitivo desproporcionado.

Rubinstein, Meyer y Evans (2001), en un estudio clásico del Journal of Experimental Psychology, documentaron costes del task-switching que la APA resumió como hasta un 40% del tiempo productivo (no específico TDAH; en cerebros TDAH el coste se amplifica). Si tu mañana son tres reuniones de 30 minutos y dos quick syncs, lo que queda no son “5 horas de coding”: son fragmentos de 40-60 minutos que casi nunca alcanzan deep work.

Mover tickets en Jira es admin, no es producir; pero los managers lo cuentan como “trabajo”. Para un cerebro TDAH, la disonancia entre “esto no produce nada” e “importante” es agotadora. El patrón completo está en TDAH y rendimiento laboral discontinuo.

Code review y rejection sensitivity

El code review es necesario y, hecho bien, mejora el código de todos. Pero si tienes rejection sensitivity (RSD) — la sensibilidad amplificada al rechazo, real o percibido, frecuente en TDAH adulto —, una PR con quince comentarios de “could you change this?” te puede dejar bloqueado dos días.

No es debilidad: es respuesta amígdala. La revisión de Liu, Hua, Lu y Goh (2023) en Psychology and Psychotherapy sobre 28 RCT de TCC en adultos con TDAH mostró que las terapias adaptadas reducen significativamente síntomas emocionales (ansiedad, depresión, autoestima), no solo síntomas core. Si las code reviews te derrumban con frecuencia, no es un problema técnico ni de carácter: es un patrón gestionable, pero hay que reconocerlo.

Estrategias prácticas:

Lee la PR review en dos pasadas. Primera vez, solo registras. Segunda (al menos una hora después), respondes técnicamente. La distancia temporal apaga la respuesta amígdala.
Pide en 1:1 que se separe “blocker” de “nice to have”. Reduce el ruido emocional de comentarios indiferenciados.
Reconoce el patrón. Si después de cada review necesitas dos horas para volver a coding, no es procrastinación: es recuperación.

Sprints, deadlines y la percepción del tiempo

El TDAH se asocia con time blindness (ceguera al tiempo): el “horizonte temporal” es más corto, lo que está más allá de la próxima semana es prácticamente abstracto. Barkley (1997) describió esto como una dicotomía “now/not-now”: el sprint que termina dentro de 9 días es “not-now” hasta que se vuelve mañana, momento en el que es-todo-ahora-y-pánico.

Resultado típico: el viernes de la semana 1 del sprint te das cuenta de que has subestimado la complejidad de tres tickets, y los últimos tres días son hiperfoco angustioso. Esto se repite sprint tras sprint y se llama “ritmo del equipo”.

Estrategias que funcionan:

No estimes solo. Estima en pareja con alguien neurotípico. El “esto se hace en medio día” tuyo se traduce en realidad a “día y medio”. Tener un calibrador externo ayuda.
Rompe los tickets antes del sprint, no durante. Lo que en planning parece “implementar el endpoint X”, durante la implementación se descompone en 12 sub-tareas. Si las divides antes, el sprint deja de tener sorpresas.
Bloquea bloques de deep work en el calendario. Dos slots de 2 horas a la semana, marcados como “no-meetings”. Es la única manera de que existan.

Burnout acelerado

El burnout en developers TDAH llega antes que en colegas neurotípicos, y golpea más fuerte. La razón es la combinación: hiperfoco frecuente + masking constante en reuniones + context switching no compensado + RSD acumulada. Las semanas “buenas” son tan intensas que la deuda recovery se acumula sin que te des cuenta.

Está documentado en detalle en TDAH y burnout: por qué llega antes y vuelve siempre. Si llevas seis meses funcionando “muy bien” y de pronto no puedes ni abrir el laptop, no es que te hayas vuelto perezoso: es la cuenta atrás biológica.

Context switching entre repos, proyectos y on-call

En equipos modernos un developer toca 4-5 microservicios, dos repos de IaC, documentación en Confluence, dashboards en Grafana y una rotación de on-call. Cada switch carga un modelo mental nuevo en working memory.

Alderson, Kasper, Hudec y Patros (2013) en Neuropsychology hicieron una meta-análisis sobre working memory en adultos TDAH: déficit moderado, más marcado en tareas que requieren manipulación activa que en simple almacenamiento. Traducción: cargar un modelo mental complejo y mantenerlo activo mientras te interrumpe Slack es exactamente lo que tu cerebro hace peor.

Síncrono vs asíncrono: una de las decisiones de carrera más importantes

Para developers TDAH la diferencia entre un equipo predominantemente síncrono y uno predominantemente asíncrono no es una preferencia: es un factor de salud mental.

Síncrono pesado	Asíncrono dominante
Standups diarios, muchas reuniones, decisiones en call	Documentación escrita, ADRs, decisiones por hilos
Disponibilidad continua en Slack	Bloques de focus, respuestas en horarios definidos
Coste alto de context switching	Coste alto de escritura inicial, pero amortizable
Visibilidad social del esfuerzo	Visibilidad documental del output
Mejor para perfiles extrovertidos neurotípicos	Mejor para perfiles deep-work, neurodivergentes

Si en tu carrera puedes elegir, prioriza equipos con cultura asíncrona dominante. Si ya estás en un equipo síncrono, negocia “días sin reuniones” (es un ask razonable y muchos managers lo aceptan).

Estrategias concretas para developers TDAH

Cinco prácticas que funcionan, recopiladas de relatos consistentes en comunidades de neurodivergentes en tech (no son recetas universales, pero el patrón se repite mucho).

Externaliza la working memory. No intentes recordar nada en cabeza más allá de la sesión actual. Brain dump en cuanto un pensaje aparece. Si un pensamiento sobre el código se interrumpe por una notificación, escríbelo antes de mirar la notificación. Para esto está el brain dump de DopaHop — diez segundos y lo has soltado.
Protege el deep work como recurso escaso. Bloquea calendar, calienta el modo focus, silencia notifications. Dos slots de 2 horas a la semana, intocables, valen más que cinco días de “siempre disponible”.
Acepta que las semanas no son iguales. Vas a tener semanas a 130% (hiperfoco productivo) y semanas a 60% (recuperación). Si la suma cuadra al trimestre, está bien. Forzar una constancia diaria que tu cerebro no permite es la receta directa al burnout.
Standups por escrito si puedes negociarlo. Tres líneas en un canal: “ayer/hoy/blockers”. Te ahorra el context switch, da más documentación, y permite a colegas en otros husos horarios participar.
Sé honesto con tu manager (si es posible). No tienes que diagnosticar, pero “trabajo mejor con bloques largos sin interrupciones” es un ask legítimo. Muchos managers lo aceptan si el output justifica.

Cómo DopaHop puede ayudarte en una semana técnica

Tres módulos se conectan directamente con la rutina de un developer TDAH:

Brain dump: para soltar ideas, bugs vistos de pasada, refactors mentales, antes de que se evaporen mientras estás en un PR.
Pomodoro: para abrir el editor cuando el ticket te paraliza. Pulsas y empieza, tú solo piensas en escribir las primeras tres líneas.
Focus sounds: lluvia, lofi, brown noise para crear el sound-cue del coding, sobre todo si el ambiente físico está lleno de distracciones.

Preguntas frecuentes

¿Tengo que decirle a mi empresa que tengo TDAH?

No es obligatorio en España. La Ley General de derechos de las personas con discapacidad protege la confidencialidad. Decirlo abre la puerta a ajustes razonables (bloques sin reuniones, escritura asíncrona, días de remoto extra) pero también puede generar prejuicios en equipos poco maduros. Decisión personal. Si lo planteas, hazlo en términos de necesidades de trabajo concretas, no de etiqueta diagnóstica.

Soy autónomo en tech, ¿es mejor o peor que estar en plantilla?

Distinto. Como autónomo controlas calendario y eliges clientes, lo que reduce el coste del ceremonial ágil; pero pierdes la estructura externa que muchos cerebros TDAH necesitan, y ganas facturar, perseguir cobros y gestionar el IRPF. La FEAADAH tiene material sobre TDAH adulto en el trabajo que vale la pena consultar antes de decidir.

¿Los stimulants me harían mejor developer?

Los estimulantes recetados (cuando son apropiados clínicamente) reducen los síntomas core del TDAH y muchas personas reportan mejoras en sostenimiento atencional. No son magia ni “doping productivo”: son tratamiento médico que requiere diagnóstico y seguimiento. Habla con tu médico de cabecera (que te derivará a Salud Mental del Centro de Salud Mental de tu área); nunca uses estimulantes de terceros.

¿Cómo pido ajustes razonables en una entrevista?

Mejor no pedirlos en la entrevista (riesgo de sesgo). En el primer mes, en un 1:1, plantea necesidades concretas: “trabajo mejor con dos bloques de focus sin reuniones”, “los cambios de contexto me hacen perder eficiencia”. Habla de output, no de diagnóstico.

Llevo tres años en tech y tengo burnout. ¿Cambio de sector?

Antes de cambiar de sector, prueba a cambiar de modalidad dentro de tech: de scaleup ruidosa a equipo distribuido asíncrono, de full-stack a un rol más especializado (datos, plataforma, DX), de in-house a freelance. Para muchos developers TDAH el problema no es el código, es el envoltorio organizativo. Si necesitas apoyo, tu médico de cabecera puede derivarte al CSM.

En resumen

Tech atrae a cerebros TDAH por buenas razones (novedad, problem solving, hiperfoco monetizable, jerarquías planas, remoto), pero también pone trampas concretas: sprints, ceremonial ágil, code review como trigger de RSD, context switching, burnout acelerado. Las ventajas son reales, las dificultades también; el equilibrio depende mucho del tipo de equipo más que del sector en sí.

Si te reconoces, prueba una sola cosa esta semana: bloquea dos slots de 2 horas de deep work sin reuniones en tu calendario, marcados con un nombre claro, y respétalos como respetarías una reunión con un cliente. Mira si después de cinco días te sientes menos fragmentado. No para “ser más productivo”: para ver si tu cerebro respira mejor.

Herramientas amables, no gurús de la productividad. DopaHop es gratis en Google Play, y Hop te espera siempre — incluso si vuelves después de una semana mala.

Este artículo es informativo y no sustituye la valoración de un profesional. Para diagnóstico, tratamiento o ajustes laborales, habla con tu médico de cabecera, con el Centro de Salud Mental (CSM) de tu área, o consulta a FEAADAH. En caso de emergencia sanitaria: 112. Si estás atravesando un momento de crisis: 024 (Línea de Atención a la Conducta Suicida).