De “Hola Mundo” a la IA: una vida programando

Programador recorriendo la evolución de la programación desde C++ y Linux hasta la inteligencia artificial

Tenía 14 años y estaba en el aula de informática, en el colegio donde estudié. En el grado noveno debías elegir un área de especialización: biología, matemáticas e informática, o comercio. Mi hermano mayor había elegido matemáticas e informática, y mis tíos, que habían pasado por el mismo colegio, biología. Ese día caluroso, en el aula de informática, el profesor nos enseñaba el famoso “Hola Mundo”. No recuerdo el lenguaje de programación, pero recuerdo perfectamente mi alegría al ver en la pantalla del computador:

“Hola Mundo”

No esperé la siguiente instrucción del profesor cuando cambié el string por “Hola Saúl” y funcionó. Me sentía el rey del mundo. No tenía nada que pensar: sería ingeniero de sistemas. La sensación de tener el control, de sentir que el computador hacía lo que yo le decía, era de felicidad absoluta.

Tres años después, en mi primer semestre de universidad, iba perdiendo “Fundamentos de Programación”. Todo se me hacía tan difícil —arreglos, variables, condicionales—  no sabía por qué, pero no entendía nada. Hasta que recordé ese día en el aula de informática del colegio. Fue como cuando Neo aprendió Kung Fu. Estuve a punto de perder la materia, pero logré sacarla adelante en el último corte. En esa época nos enseñaban C++. En los semestres posteriores aprenderíamos colas, filas, apuntadores (nos decían que era súper peligroso porque ingresábamos directamente a la memoria del computador), listas y funciones recursivas. En primer semestre nos dijeron que la recursividad era lo peor del mundo, que mal diseñada se podía comer toda la RAM; en algoritmia nos dijeron que era lo mejor del mundo. Nos hacían entrar a páginas de problemas y resolverlos, y en esa época no solo importaba que funcionara: tenía que ser rápido y consumir poca RAM. Esas páginas de ranking evaluaban el código y lo calificaban; competías con “programadores” de todo el mundo.

Llegó el mundo Linux. Todo era tan complejo al principio —los drivers no existían como en Windows, los juegos no existían como en Windows— y aun así era feliz creando particiones en el disco duro para tener booteando Windows y Linux juntos. Otra vez el peligro de dañar las cosas, el ponerle overclocking a la CPU: teníamos el control de todo y eso nos hacía sentir poderosos. Con Linux llegaría el odio a Windows y a todo lo privativo. Soñaba con ser alguien grande, con desarrollar una aplicación que llegara a todos, con ser colaborador del kernel de Linux.

El poder y el código espagueti

Como todos en la carrera, arreglábamos computadores de vez en cuando —entiéndase como formatear o hacer mantenimiento: desfragmentar, pasar el antivirus, ejecutar otras herramientas, limpiar el registro de arranque y esas cosas. Eran tiempos donde se pirateaba Windows, programas y juegos. Entré en foros y listas de correos de crackers, a buscar ese “if” donde se validaba el serial de la licencia y a saltarlo con assembler. No me duró mucho la etapa de cracker; eran los inicios de internet y ya había información por todas partes. Mi primera gran idea fue desarrollar una imagen de Windows que se autoinstalara; descubrí que alguien ya lo había hecho, una versión de Windows desatendida y sin algunos programas, y de inmediato se volvió la preferida mía y de mis amigos. Luego quise crear un instalador con todas las cosas que usaba para el mantenimiento, pero no sabía cómo, y el proyecto nunca lo saqué adelante. Seguíamos programando en C++, haciendo aplicaciones para Windows, cuando de repente llegó Java. Prometía crear ejecutables tanto para Windows como para Linux, hasta para lavadoras; su programación era “empresarial” y más ordenada, pero al mismo tiempo más compleja. Duró poco mi aprendizaje en Java, cuando conocí PHP: un cambio del cielo a la tierra. Para hacer un “Hola Mundo” en Java debías crear cuatro clases; en PHP mezclabas HTML, PHP y hasta JS. Un gran poder conlleva una gran responsabilidad: odiado por muchos, querido por otros, ese código espagueti inundó la web.

Gmail acababa de estrenar su chat, y AJAX salía al mundo con jQuery. Diseñé mi primer framework, uno con login y un scaffold influido por Ruby on Rails; crear módulos CRUD era sencillo, la vista de editar y crear se reutilizaba, y todas las peticiones se hacían por JS. Sin saberlo, estaba creando SPA (Single Page Applications); años después un amigo me enseñaría Angular y entendí que era el mismo principio. Me interesé en los frameworks de PHP, y aunque nunca los usé, mis favoritos eran Cumbia y Falcon PHP. Poco a poco fui investigando; quería que mi framework creciera y fuera popular. Yo era un puritano del rendimiento y criticaba que los frameworks tenían muchas cosas que uno no usaba y que no sabía cómo funcionaban, eran cajas negras para mí. Así que quise hacer un framework ligero que fuera muy rápido. Después de investigar y darle prioridad a la seguridad, descubrí cómo funcionaban los otros frameworks, y ante la imposibilidad de sacar adelante el mi propio framework, abandoné el proyecto y me pasé a Laravel. En esa época, Zend —la empresa a cargo de PHP— tenía su propio framework, pero era una locura, me recordaba a Java, y Laravel era el framework “para artesanos”, así nos gustaba llamarnos: le daba valor a nuestro “trabajo”.

La guerra de los frameworks

El tiempo siguió evolucionando hacia la web. El boom de JS comenzó con Node y Express, luego llegó Mongo, y todo el stack LAMP (Linux, Apache, MySQL, PHP) pasó a ser MEAN (Mongo, Express, Angular, Node). Me resistí al cambio inicialmente, no quería abandonar PHP, pero un amigo me enseñó que en nuestro ámbito no es bueno casarse con ninguna tecnología, cosa que le agradezco hasta el día de hoy. Comenzó la batalla de los frameworks de JS —Angular, Vue, React— y era cosa de locos, como ahora con la IA: cada tres meses salía un framework nuevo, una actualización. Lo más loco ocurrió cuando Angular pasó de su versión 2 a la versión 5: cambiaron absolutamente todo, el código era cero compatible, tocaba reescribirlo todo a la versión 5. Odiaba sobremanera el “npm install” y la cantidad de librerías que nos facilitaban la vida, pero que hacían que el proyecto fuera extremadamente pesado y, a mi modo de ver, ineficiente. Pero eran otros tiempos: el problema ya no era la RAM, los “programas” se ejecutaban en el navegador, no había peligro de dañar el computador, el navegador hacía de sandbox manteniendo todo seguro. El hardware aumentó muchísimo y ya nadie se preocupaba por el rendimiento.

En mi trabajo tuve retos para mejorar la velocidad de la aplicación. Hice un par de refactorings que, a mi modo de ver, mejorarían la app en mínimo el doble; me sentía casi orgulloso de antemano, pensaba ponerlo de ejemplo ante los demás programadores. Cuando vimos los resultados, el software solo respondió unos 300 milisegundos mejor. Al principio fue frustración pura. Después vino la resignación, y con ella un aprendizaje: no tenía que pelear contra el framework, podía actualizarlo y aprovechar sus nuevas funcionalidades; tocaba ser práctico. Entendí que era una guerra perdida —en vez de gastar dos semanas en esos refactorings, era mejor poner un servidor más grande, y los resultados eran similares—, y entendí también que yo ya no era solo un desarrollador peleando por su código: era el líder de desarrollo, el que ponía las pautas de cómo se creaba y se mantenía el código de otros.

El artesano contra el ingeniero

Aparecieron los bootcamps. Ya no era necesaria una carrera de cinco años para programar; con solo seis meses salían personas capacitadas y con mejores herramientas. En el trabajo contratamos a uno recién salido, sin experiencia pero muy bueno. Me enseñó cosas sobre Visual Studio Code, y bien guiado era un buen recurso. Su debilidad, al igual que la de todos cuando salimos, era la perfección: quería el mejor algoritmo y se demoraba mucho, muchas veces haciendo sobreingeniería a problemas sencillos.

Poco a poco los nuevos programadores hacían menos código: encontraban una librería que solucionara todo y simplemente la instalaban. Muchas veces esas librerías hacían muchas cosas más y pesaban mucho, pero el problema se solucionaba. “No mates una mosca con un cañón”, creo que esa frase nunca la oyeron. Se fue al diablo, poco a poco, eso de ser “artesanos” del código. Quise retomar las buenas prácticas, leyendo sobre guías de codificación. En el trabajo, por fin pudimos separar el frontend del backend. ¿Cómo lo hicimos? Saliendo de PHP: nuestro lenguaje de frontend fue Angular y nuestro lenguaje de backend, Golang. Hicimos aplicaciones interesantes para la empresa, diseñamos un ecosistema complejo de “microservicios”, hicimos cosas muy buenas.

Ahí tuve otro dilema con el performance, esta vez con la arquitectura hexagonal y su montón de archivos y funciones separadas. No podemos negar que llamar tres funciones de forma secuencial es más lento que tener solo una. Pero de a poco fui haciendo acuerdos conmigo mismo: sigo tan obsesionado con el rendimiento como siempre, pero ahora primero pienso que funcione, y después hacemos el refactoring. Ya no pienso tanto en el performance puro; pienso más en la calidad del software, en que tenga buenas prácticas y sea fácil de leer. Si el código está bien hecho, puedo sacrificar un poco de latencia a cambio. Creo que esa es la enseñanza más grande de todos estos años: no quedarme estático, aunque no esté de acuerdo con el cambio.

La máquina que programa

Llegó la IA, y Copilot empezó pegando duro. Una de las personas con las que trabajaba comenzó a pagar la suscripción, y se veía cómo mejoraba su productividad. Yo tenía mis dudas, pero cuando lo probé junto con Q de AWS, comprobé yo mismo que, bien guiada, era una buena herramienta: completaba código de forma óptima, claro está, cosas pequeñas como un loop o una función bien descrita.

Hicieron su entrada los LLM, y murió un grande: Stack Overflow. Claro que más de una vez me salvó el culo, pero era mucho más fácil decirle a la IA que algo no funcionó y darle el error para intentarlo de nuevo, que buscar entre las respuestas de Stack Overflow. Ahora estamos “programando” con agentes. Sin ir tan lejos, en la empresa donde trabajaba, una de las personas que no hace parte de los desarrolladores es quien más módulos saca a producción; es el orgullo del área de IA y la vergüenza del área de tecnología. Una vez más, la lección es no casarnos con ninguna tecnología: debemos aprender y fluir con las tendencias. A algunos negocios no le importa la calidad del código que está en producción, le importa que solo fueron cuatro horas creándolo y que, obviamente, funciona.

Me siento un poco como cuando pasamos de las aplicaciones de escritorio a la web con PHP: mucha gente aprendió PHP sin saber programar, y por eso se veían cosas de tan mala calidad, pero la web se inundó de páginas —creo que hasta hoy sigue siendo el lenguaje con más páginas en internet—. Creo que lo mismo pasará con la IA: es una herramienta al alcance de todos, la web se va a inundar de proyectos, y la gente ni siquiera va a saber distinguir si están hechos con IA o no, si están bien hechos o no. Pero eso no será el problema real, porque la IA en manos de un buen desarrollador va a ser un buen producto. Lo que sí no puedo negar es que me da un poco de rabia que todo el esfuerzo de estos años se vea resumido en pocas horas, aunque sé que esa misma IA se alimenta del código y los textos que gente como yo escribió antes.

Neo

Hace poco regresaba de un viaje en avión y puse Matrix. Todo este artículo nace de esa película, tal vez sean los cuarenta que me respiran en la nuca, o el haber vivido la evolución de todo. Volví a ver a Neo aprendiendo Kung Fu en segundos, el mismo hacker que quería ser yo aquel día del “Hola Mundo”, ahora siento envidia por la nueva generación salarios bien pagados, la IA trabajando para ellos, el sueño de todo pensionado.

El rol del CTO en las empresas tecnológicas

Comencemos hablando del C-level, en palabras cortas y contundentes el C-Level son todos esos cargos que comienzan con la C (Chief), alguno de ellos son:

CEO – Chief Executive Officer: El pluma blanca o gerente de la empresa, responsable de la gestión y dirección administrativa de la empresa.

CMO – Chief Marketing Officer: Responsable de la estrategia y acciones de marketing.

CHRO – Chief Human Resources Officer: Su objetivo está en captar, desarrollar y retener el mejor talento digital del mercado.

COO – Chief Operations Officer: Con sus acciones se rediseñará la cadena de valor, dotándola de mayor tecnología con el objetivo de mejorar la ventaja competitiva.

CPO – Chief Product Officer:

CIO – Chief Information Officer: Es responsable de la infraestructura tecnológica interna de una empresa y sus operaciones.

CTO – Chief Technology Officer: Podría definirse como el nexo de unión entre estrategia y tecnología, su objetivo es mejorar la experiencia de cliente tanto a nivel interno como externo, apoyándose en los nuevos modelos y avances tecnológicos.

¿Qué hace un COO ?

El COO generalmente lo asociamos a la producción y entrega del producto, por lo tanto sus principales áreas donde se verá involucrado serán Finanzas (Llevar control de gastos, compra de materia prima etc), Logística (entrega del producto al usuario, recibimiento de material de los proveedores etc) y Recursos Humanos (Mantener a la gente contenta).

En empresas tecnológicas por otro lado el COO:

El rol de director de operaciones es responsable de crear operaciones y estructuras que respalden la entrega diaria de los productos y servicios de su organización. Eso generalmente significa arquitectura, procesos comerciales, desarrollo de productos, soporte, estructura de equipo, etc. Las organizaciones tecnológicas, las operaciones permiten la creación y el desarrollo sostenibles de un producto de software, lo que significa que las operaciones tienen que ver con la estructura, la gestión de personas, la atención al cliente, el desarrollo de productos, el producto. gestión y apoyo. Aquí, es crucial que las organizaciones vean a toda la organización como un producto, que el director de operaciones debe supervisar.

El CEO es el encargado de crear y dirigir la visión y la estrategia. El director de operaciones debe ser su socio, trabajando directamente para actuar y hacer realidad esa visión y estrategia. Si el director ejecutivo es “qué”, el director de operaciones es “cómo”.

En muchos sentidos, esto significa que el director de operaciones ideal para su organización es aquel cuyas habilidades y personalidad complementan las del director general. Entonces, si el CEO tiene ideas pero no una forma práctica de escalarlas, el COO intervendrá para escalar. O, si el CEO tiene experiencia en operaciones, el COO podría operar como un socio comercial, compartiendo trabajo e ideas en una puesta en marcha temprana.

¿Qué hace un CPO?

El CPO examina el mercado para determinar la mejor manera de abordar y lograr los objetivos comerciales clave. Con base en su investigación, idea estrategias para alcanzar la visión de producto que responda a los desafíos y demandas del mercado.

¿Qué hace un CTO?

Al ser una posición con conocimientos tecnológicos se piensa que el CTO debe venir del área de desarrollo, y no siempre un buen desarrollador será un buen CTO, se deben tener habilidades blandas para generar un buen liderazgo, para que el equipo este motivado y se cumplan los objetivos, una de las diferencias entre el CTO y los desarrolladores es la forma de abordar los problemas, podemos decir que el CTO analiza como un problema puede ser solucionado con la tecnología, es decir, primero identifica el problema, la necesidad, el dolor del usuario y luego planifica que herramientas usar para dar una solución, por otro lado los desarrolladores por lo general se especializan en una cosa, pueden ser frontend seniors en react o backend juniors en Gonlang, y de esta forma están siempre viendo como desde su especialización pueden solucionar un problema que tal vez ni siquiera exista, los desarrolladores somos vanidosos y muchas veces queremos mostrar/demostrar como solucione esto con mi intelecto y la herramienta en la que soy experto, se nos alza el ego cuando podemos hacer algo que otros no.

Entonces la función principal de un CTO se vuelve hacer software que le de valor a la compañía, de nada sirve tener un equipo capacitado sacando funcionalidades muy frecuentemente sino estamos resolviendo nada, sino le estamos aportando algo al usuario, sino le generamos valor a la compañía, en resumen un CTO es un líder que guiá un equipo para crear software que genere valor a la compañía.

Así el mundo del CTO esta entre el negocio y la tecnología, debe analizar hacia donde orientar el producto con base a la visión, a la estrategia del negocio y traducir eso en una estrategia de tecnología, debe crear un roadmap donde pueda medir y validar los objetivos que cumplen la estrategia.

Pero la labor del CTO no se queda solo en crear la estrategia tecnologia, debe implementarla y evaluar si los resultados fueron los esperados para tomar las correcciones en caso de que haya, pero ello debe hacer uso de sus conocimientos tecnologicos para escoger las herramientas adecuadas para cada una de las soluciones implementadas en el roadmap, no basta con planear, se debe ejecutar y medir resultados.

Finalmente toda la estrategia debe estar apalancada en 6 pilares:

  • Producto
  • Equipo
  • Data
  • Developers
  • Devops
  • Seguridad

Debemos tener 4 cosas en cuenta en nuestro roadmap, área de impacto, estrategia a implementar, plan de implementación y ejecución

Podemos ver la estrategia “Que queremos hacer” siempre apuntando en dirección a los objetivos de la empresa, el plan es “como lo vamos hacer” y la ejecución serán metas medibles sobre si logramos hacerlo o no, ejemplo:

StrategyPlanExecution Goal
Mejorar el performance del portalAumentar la velocidad de respuesta del portal.1. Disminuir la latencia en 0.2 segundos.
2. Disminuir el número de imágenes en los artículos a 3.
Lograr mayor nivel de recirculación entre los usuarios.Crear un módulo con noticias sugeridas para el usuario.1. Lograr que el usuario al menos vea dos artículos más.
Ganar autoridad como portal.Buscar alianzas con medios reconocidos para que enlacen nuestro portal.1. Lograr que dos portales de renombre creen 1 enlace semanal a nuestros contenidos.

¿Porqué la confusión con el CPO?

A medida que la empresa crece, ya sea orgánicamente o mediante adquisiciones, los líderes de la empresa a menudo contratan un CPO para manejar la mayor complejidad que conlleva, por ejemplo, tener múltiples líneas de productos y un conjunto diverso de clientes.

Por lo general, encontrará que las empresas más establecidas invierten en ambos roles. Sin embargo, en las empresas emergentes, el CTO puede tener la responsabilidad total de liderar los esfuerzos para diseñar, desarrollar y construir un gran producto.

Estrategia

El CPO es responsable del “por qué” del producto: el enfoque estratégico de lo que se construirá. El CPO se asegura de que la dirección del producto esté al servicio de la visión general de la empresa y se ajusta según sea necesario a las condiciones cambiantes. Tácticamente, el equipo de producto es el propietario de la construcción y el intercambio de la hoja de ruta. El plan del producto explica a la organización por qué están construyendo el producto, qué características y requisitos se incluyen y cuándo vencen las fases y tareas.

El CTO es responsable del “cómo” del producto: el enfoque estratégico para el desarrollo y la entrega. El CTO determina cómo el equipo utilizará la tecnología para mejorar los productos y servicios. Tácticamente, este trabajo incluye análisis de costo-beneficio y retorno de la inversión para determinar qué plataformas y soluciones tienen las mejores posibilidades de dar sus frutos.

Innovación

El CPO estudia a los clientes y el mercado y busca qué dirección puede y debe tomar el producto en el futuro. Significa respetar la visión y la estrategia del producto mientras se consideran nuevos enfoques para ofrecer valor a los clientes. El objetivo final sigue siendo crear una mejor experiencia para el cliente.

El CTO estudia las soluciones tecnológicas para hacer recomendaciones para la arquitectura empresarial y la mejor manera de realizar el trabajo. No se trata de invertir en tecnología emergente porque es más nueva de lo que se utiliza actualmente. Se trata de mejorar la capacidad del producto para resolver problemas reales para los clientes y mejorar la capacidad del equipo para ejecutar sus compromisos.

Clientes

El CPO tiene un conocimiento profundo de los deseos y comportamientos de los clientes porque pasan mucho tiempo con ellos y con las personas que los atienden internamente (por ejemplo, equipos de ventas y soporte). Representan al cliente internamente, comunicando el aprendizaje a través de la investigación y el análisis, compartiendo conocimientos con socios internos, como líderes de marketing y ventas, y animando al equipo de producto a hablar directamente con los clientes.

El CTO también debe comprender al cliente, aunque a menudo confían en la investigación y los aprendizajes del CPO. El CTO también debe aplicar sus conocimientos técnicos para garantizar que las aplicaciones tecnológicas reflejen la forma en que los clientes desean interactuar con el producto.

Metricas

El CPO analiza las métricas desde el punto de vista de la experiencia del producto. Realizan un seguimiento de una amplia variedad de KPI de productos para medir qué tan bien le está yendo a la empresa en la entrega de un CPE, como los ingresos y el crecimiento, la participación y la retención de los clientes.

El CTO analiza las métricas desde el punto de vista del rendimiento del producto. Quieren saber qué tan bien el producto hace lo que se supone que debe hacer. También quieren observar las interacciones del cliente con el producto para comprender cómo se está utilizando. Internamente, los mejores CTO realizan un seguimiento de métricas como la velocidad del equipo, los defectos del producto y el tiempo de ciclo para mejorar el proceso de desarrollo.

Resolviendo dudas, como se relacionan los roles

Supongamos que estamos en una empresa grande como Facebook, en este caso el CEO, se encargaría de cosas como la adquisición de nuevos productos, como la compra de WS, o IG, las demandas multimillonarias por parte de la Unión Europa, crear estrategias para mantener el valor de la empresa en la bolsa. En esta empresa, nuestro CEO, se apalancaría seguramente en algunos COO, de pronto repartidos geográficamente mantener la operación en latinoamerica, asia etc o mantener la operación por producto ( Facebook no solo es la red social, tiene cosas como realidad aumentada, react, streming de video juegos etc), seguramente nuestro COO tendría un CPO el cual le ayudaría viendo como agregar valor a la empresa a través de nuevas funcionalidades para el usuario, así el COO se encargaría de temas contractuales, apertura de nuevas oficinas, en fin, todo lo necesario para que la operación de la empresa funcione, y finalmente nuestro CPO se ayudaría de un CTO para implementar toda la estrategia tecnológica, “como” hacer posible la dirección o visión del CPO.

Ahora porque la confusión, ¿porqué si soy CTO, a veces ejecuto cosas que debería hacer el COO o el CPO? Comencemos porque no todas las empresas tienen que implementar todos los cargos. El cargo de COO es usado en empresas muy grandes donde el CEO no alcanza a realizar ciertas funciones, pero en la mayoría de las empresas no tiene sentido tener un COO, lo mismo ocurre con el CPO, normalmente en las startups, la labor del CTO adquiere funciones del CPO, buscar darle valor a la empresa, crear la estrategia, conocer el producto, tener contacto con los clientes, por eso en las startups tecnológicas en un comienzo es mas fácil buscar un CTO que tenga esos conocimientos, que un CPO que sepa de infraestructura, buenas practicas de programación etc… es decir con el tamaño de la empresa se van fusionando cargos de tal modo que el CTO puede ser a su vez, CPO y COO.

Fuentes:

https://thevalley.es/blog-talento/los-perfiles-c-level-funcion-la-digitalizacion/

https://www.linkedin.com/pulse/cto-versus-coowhats-difference-technology-company-leon-ginsburg

https://www.visiontovalueframework.com/blog/2019/10/what-is-the-tech-coo-role/

https://www.bairesdev.com/blog/cio-vs-cto-vs-cpo/