La Trampa del Título pregunta: ¿qué es lo que realmente estamos pagando? Este ensayo lo responde definiendo tres prácticas sustancialmente distintas en el trabajo del conocimiento. El problema no es que la gente use “ingeniero,” “tecnólogo” y “técnico” de forma intercambiable. Es que hemos hecho imposible llamar a alguien de otra manera.

I. La Profesión Que Perdió Sus Nombres

En medicina, la distinción es clara y la ley la impone. Un médico y una Enfermera Especialista son ambos valiosos. Ambos son profesionales capacitados. No son intercambiables. Tienen diferente formación, diferentes alcances de práctica, diferentes responsabilidades legales. El sistema está diseñado para que no puedas confundirlos.

En software y datos, esta distinción ha desaparecido. Todos son “Científicos de Datos.” Todos son “Ingenieros de Datos.” Todos son “Ingenieros de Software.” Los términos se han convertido en puro ruido—un perchero de títulos donde cualquiera puede agarrar lo que suene más impresionante.

El resultado: empresas contratan un “Ingeniero de Datos” para hacer trabajo de técnico de datos: cargar CSVs, escribir pipelines de ETL desde una especificación. Pagan la prima por alguien que pueda diseñar sistemas de datos, pero lo asignan a ejecución. La persona desperdicia su capacidad o se va. O peor: acepta el título y el trabajo, y lentamente deja de intentar resolver problemas novedosos. Se convierte en un técnico cobrando salario de tecnólogo, y todos pretendemos que esto es normal.

La versión honesta de la mayoría de puestos de “ingeniería de software”: es trabajo de programación. Programar es trabajo de técnico—implementar desde especificación, resolver problemas definidos con herramientas conocidas. Es trabajo valioso. No es ingeniería. Pero hay vergüenza en decir “soy programador” o “soy técnico,” así que lo llamamos “ingeniería de software” y pretendemos que la distinción no existe.

II. El Técnico

Un técnico es alguien que aplica soluciones conocidas a problemas definidos. Trabaja desde especificaciones, planos o normas. Su trabajo es ejecución con precisión. Es responsable de hacer la cosa correctamente, no de decidir qué debe ser la cosa.

Los técnicos siguen el manual. Implementan la especificación. Ejecutan el procedimiento. El problema ya está delimitado. La solución ya existe. Optimizan dentro de ese límite. Su responsabilidad es la calidad y corrección de la ejecución—velocidad y confiabilidad dentro del alcance.

Piensa en un cirujano siguiendo un protocolo, un administrador de red desplegando una configuración estándar, un desarrollador implementando un ticket detallado. Los técnicos son invaluables. La civilización moderna funciona gracias a técnicos. Un puente no se desmorona porque hay demasiados técnicos en la construcción; se desmorona porque no hay suficientes, o los técnicos recibieron una mala especificación.

La mayoría de programadores que trabajan son técnicos. La mayoría de personas que trabajan con datos son técnicos. La mayoría de personas que trabajan en tecnología son técnicos. Esto no es un fracaso. Es lo que el trabajo es. Si estás implementando tickets desde una especificación, si estás escribiendo código que resuelve un problema definido, si estás corriendo scripts para extraer, transformar y cargar datos, si estás siguiendo patrones y mejores prácticas establecidas para construir lo que alguien más diseñó—eres un técnico. Eso es honesto. Es necesario.

Un tecnólogo es alguien que adapta, integra o inventa soluciones a problemas novedosos. Trabaja desde principios y creatividad. Su trabajo es resolución de problemas bajo incertidumbre. Es responsable de encontrar el camino cuando el camino no es obvio.

Los tecnólogos preguntan “¿por qué de esta manera?” Proponen alternativas. Integran sistemas dispares. Inventan nuevos enfoques cuando el libro de texto no lo cubre. El problema es claro, pero la solución no. Definen el cómo cuando el qué es conocido. Su responsabilidad es elegir el enfoque correcto, evaluar compensaciones, hacer que las soluciones funcionen en contextos nuevos donde las respuestas viejas ya no aplican.

Piensa en un arquitecto diseñando un puente para un sitio desafiante, un desarrollador diseñando un sistema que aún no existe, un investigador ingenierizando un nuevo enfoque a un problema antiguo. Los tecnólogos son el tejido conectivo. Toman el conocimiento existente y lo hacen funcionar en contextos nuevos.

IV. El Ingeniero

Un ingeniero es alguien que diseña sistemas con responsabilidad ética, legal o existencial. Trabaja desde primeros principios y responsabilidad. Su trabajo es asegurar que lo que se construye no fallará de maneras que importen. Es responsable de la viabilidad a largo plazo de lo que crea.

Los ingenieros aseguran seguridad. Previenen fallas sistémicas. Toman responsabilidad por todo el sistema, no solo una parte. Deben considerar no solo “¿funciona esto?” sino “¿fallará? ¿Qué pasa cuando falla? ¿Quién paga el costo?” Su responsabilidad es la integridad del sistema, la seguridad de los usuarios, la sostenibilidad de lo que construyen.

Un ingeniero civil firma planos sabiendo que la responsabilidad legal sigue. Un cirujano-investigador desarrolla una técnica nueva y debe probarla con seguridad. Un arquitecto de software diseña infraestructura que, si falla, quiebra toda la empresa. Estas personas cargan peso diferente.

V. La Jerarquía Está Al Revés

La industria de tech trata esto como una escalera: Técnico → Tecnólogo → Ingeniero. No es una escalera. Es un cambio de tipo de trabajo, no una progresión en antigüedad o inteligencia.

Algunas de las personas más valiosas del mundo son técnicos. Un gran cirujano es un técnico ejecutando un protocolo con tal precisión que el paciente vive. Un gran ingeniero de red aplicando patrones establecidos es un técnico, y sin esa precisión, internet no funciona. La confusión viene de mezclar tres ejes diferentes: nivel de responsabilidad, antigüedad y pago. Puedes tener un tecnólogo junior y un técnico senior. Puedes tener un técnico bien pagado y un ingeniero en dificultades. Los tres son independientes.

Una empresa que contrata un “Tecnólogo Senior” para hacer trabajo de técnico no está ahorrando dinero—está desperdiciando la costosa capacidad de resolución de problemas de esa persona en ejecución. Una empresa que necesita un ingeniero pero contrata un tecnólogo no está ahorrando dinero—está construyendo un sistema que fallará de maneras que importen, y el costo de la reparación será ruinoso.

La versión honesta: contrata el tipo correcto de practicante para el problema que tienes, y págales por el tipo de responsabilidad que cargan, no por el título que tienes miedo de explicar.

VI. La Reflexión Honesta

La persona que se llama a sí misma “Ingeniero de Software” mientras escribe código según especificación está siendo honesta sobre su valor para la empresa. No está siendo honesta sobre su rol. Es una programadora. Llamarlo “ingeniería” no cambia el trabajo; solo infla el título para que coincida con la banda salarial.

Esto no es vergonzoso. Vergonzoso es pretender que la distinción no existe. Un técnico bien pagado y capacitado es la columna vertebral de cada sistema que funciona. El problema no es que la gente sea técnica. El problema es que mentimos al respecto, luego nos sorprendemos cuando un técnico se quema porque aceptó el título de “ingeniero” y la promesa implícita de que resolvería problemas novedosos—y en cambio implementó tickets durante toda su carrera.

Llámarte lo que eres. Si eres programador, dilo. Si eres técnico, dilo. Si a veces resuelves problemas novedosos, también eres tecnólogo. Si diseñas sistemas con responsabilidad existencial, eres ingeniero. La mayoría de la gente está en la primera categoría. Está bien. Es necesario. Pero requiere honestidad.

En algunos países, la broma es explícita. En Colombia, todos son “doctores”—el título ha perdido todo significado. Cuando la inflación se vuelve absurda, la gente simplemente llama a todos “HP” (o en inglés, un nombre mucho más colorido)—una abreviatura cínica que dice: somos todos gente que reclama importancia. La industria de software se acerca a este punto de saturación. Pronto, todos serán “Senior Principal Staff Engineer,” y la distinción habrá colapsado completamente. La palabra no significará nada porque nos negamos a distinguir qué cosas realmente son. En ese punto, el único lenguaje honesto que queda es el cínico.

Y sin embargo: conforme los LLMs comienzan a generar repositorios de cien mil líneas en una tarde, un nuevo problema emerge. Nadie entiende el todo. Nadie puede. Es demasiado grande. Alguien tiene que navegarlo, depurarlo, encontrar la podredumbre, dirigirlo cuando se quiebra. El técnico no puede—la especificación se fue, enterrada bajo capas de código generado que nadie escribió a propósito. El tecnólogo puede parchar problemas pero no puede ver el bosque. Entonces, ¿cómo se llama a la persona que llega cuando el sistema falla, que lee código que no escribió, que habla tanto el lenguaje de la máquina como la intención del negocio, y arregla lo que nadie más puede diagnosticar? ¿Nuestro asistente? ¿Nuestro traductor? ¿Nuestro equipo de búsqueda y rescate?

El nombre va a importar pronto.

Lecturas recomendadas