Feed RSS de Decodifique Blog

Mi Midpoint de Carrera, Parte II

Mon, 28 Sep 2026 00:00:00 GMT

Prólogo: Peritos y corsarios

En mi último año de universidad, conversando con una compañera de clase, ella me contó que había estado trabajando en una startup de tecnología de seguridad biométrica, y que estaban buscando un programador .NET para desarrollar software usando esa tecnología en totems de atención, sign-in de sistemas web y aplicaciones mobile.

En ese momento, yo ya estaba trabajando en la Policía Tecnocientífica de São Paulo como programador web, en un sistema de GED (Gestión Electrónica de Documentos) construido en CakePHP y MongoDB, aunque ya tenía mis dudas de que fuera a durar mucho ahí. Me explico: había dejado una consultora que tenía un framework propio para ahora trabajar con una tecnología tampoco muy atractiva para el mercado, como PHP.

Como la oficina en Faria Lima quedaba cerca de la Superintendencia, negocié con el gerente de la empresa de biometría trabajar part-time, en el turno de tarde/noche, conciliando así con la Superintendencia por la mañana y principio de la tarde.

Mi negociación fue positiva, y seguí en ese ritmo de doble jornada durante seis meses, hasta que, cierto día, viví en la Superintendencia un momento bastante peculiar del sector público: el proceso licitatorio. El contrato de la consultora de software tercerizada estaba por vencer, y se abriría una nueva licitación para elegir quién asumiría el servicio de ahí en adelante. Esa incertidumbre sobre quién ganaría la licitación llevaba semanas pesando sobre todos los tercerizados, generando toda clase de expectativas y temores, sobre todo el miedo a la falta de continuidad en el proyecto. Una nueva empresa ganó la licitación que se había abierto. La ganadora podía optar o no por recontratar a los tercerizados que ya estaban ahí, pero no fue lo que ocurrió. Ante eso, la empresa a la que yo estaba vinculado me dio dos opciones: enviarme a un proyecto en Alphaville, en Barueri, o mi despido. Opté por la segunda.

Por fin, el Tío Bill pagando las cuentas

Una vez liberado, pasé a trabajar fulltime en la startup, a inicios de 2016, mi primera experiencia también como autónomo (Persona Jurídica). Después de una mudanza de oficina a Vila Olímpia, estuve en el centro del boom de las startups e hice un gran networking con diversas empresas, de los sectores farmacéutico, hospitalario, fintech y de otros productos digitales en auge en la época, como criptomonedas, brokers de activos en el exterior y toda clase de plataformas de sharing economy, a la estela de Uber, en busca de convertirse en unicornios, con mucha inyección de capital de private equity.

Las empresas unicornio "son start-ups (empresas incipientes con un modelo de negocio repetible y escalable por medio de la tecnología) que alcanzaron un valor de mercado de US$ 1.000 millones, como mínimo" [1].

En ese período, también comencé un MBA (Master of Business Administration) en Ingeniería de Software en la Universidad de São Paulo, en la Escuela Politécnica, pero no entraré en más detalles para no abrir un enorme paréntesis en este prólogo; solo vale mencionar que el objetivo del MBA era obtener el título de posgrado lato sensu.

Durante mi tiempo en la startup, me encontré con desafíos mucho más interesantes que los anteriores: empecé a adoptar de verdad el uso de Git en mi workflow de trabajo y por fin pude trabajar con todo, y solamente, el stack Microsoft .NET: Windows Forms, en esa época en las versiones 4.6.x, C#, APIs REST (Application Programming Interfaces / Representational State Transfer) en ASP.NET MVC Web API, y WPF (Windows Presentation Foundation). Vayamos por partes:

Figura 1. El diseñador visual de WPF en Visual Studio, con el XAML de la MainWindow a la izquierda y la vista previa de la interfaz a la derecha.

.NET Framework: framework de desarrollo de Microsoft, exclusivo para Windows, base de las tecnologías de abajo.
Windows Forms: framework para la construcción de interfaces gráficas para aplicaciones Windows, estilo drag-and-drop.
C#: lenguaje de programación orientado a objetos de tipado fuerte desarrollado por Microsoft.
ASP.NET MVC: framework web para la construcción de páginas web mediante la sintaxis de marcado Razor; APIs SOAP (Simple Object Access Protocol), con la extensión WCF (Windows Communication Foundation), o REST, con la extensión Web API.
WPF: framework para la construcción de interfaces gráficas que vendría a sustituir a Windows Forms, también con estilo drag-and-drop, pero con una sintaxis de marcado mediante el lenguaje XAML (Extensible Application Markup Language), basado en XML.

Figura 2. La evolución del .NET Framework: cada versión fue apilando nuevas bibliotecas sobre el Common Language Runtime.

Fue exactamente ahí donde me encontré, trabajando con las herramientas por las que sentía verdadero interés, en un período de intenso aprendizaje en tecnología, tanto por trabajar en lo que me gustaba como por estar en un entorno donde, con prácticamente ningún equipo, solo estaba yo como programador backend y un colega responsable del desarrollo de las aplicaciones Android. Tenía total libertad creativa para decidir cómo aplicar técnicas de ingeniería nuevas para mí, como pruebas automatizadas (unitarias, de stress e integradas) y principios de diseño, como SOLID y proyectos con separación en capas. También fue en esos años que empecé a tener contacto con una mayor riqueza de lecturas, como la serie The Pragmatic Programmer, de Andy Hunt y Dave Thomas, y los libros de Robert C. Martin, The Clean Coder y Clean Code. También fue en ese período que participé en muchos eventos de tecnología, como el TDC (The Developers Conference) y varios meetups.

Pasados algunos meses, tras enfrentar ciertos obstáculos personales, de común acuerdo con la gestión de la empresa, optamos por rescindir el contrato de prestación de servicios que yo ofrecía, y volví una vez más a sondear el mercado . Con una experiencia y un bagaje considerablemente mayores, ahora con fluidez en el stack Microsoft, me reubiqué rápidamente, esta vez en una consultora cuya área principal de actuación era el sector de seguros, y así fui asignado a uno de sus mayores clientes.

Orquestando la sopa de letras

El cambio, a partir del segundo semestre de 2016, fue grande: salir del mundo de las startups para mi primera experiencia en el mundo corporativo, con burocracia, procesos, integraciones de sistemas con décadas de existencia, decenas de equipos solo en TI, y tecnología restringida a un selecto grupo de empresas, con un conocimiento igualmente secreto, como una secta. Aunque había desarrollado el conocimiento técnico de la experiencia anterior, la falta de equipo me dejó débil en habilidades políticas y de trabajo en equipo. Ahora tendría que trabajar con desarrolladores mucho más experimentados que yo y con un conocimiento ya consolidado en el área de negocio, especialmente en lo que respecta a las reglas de siniestros.

Por tener un buen dominio de .NET y aprender rápido, fui elegido para participar en un proyecto de gran visibilidad en la compañía: la implementación de la plataforma Oracle SOA Suite (Service-Oriented Architecture), gestionando y orquestando las integraciones entre los diversos módulos de siniestros, y la creación de una interfaz de workflows para que los analistas y la cadena de aprobaciones pudieran analizar, evaluar y resolver sobre procesos de siniestros e indemnizaciones.

Fue un proyecto bastante complejo, ya que implicaba migrar reglas de negocio de un sistema in-company monolítico, construido en parte en VB.NET y en parte en ASP (Active Server Pages, algo que ya pensaba que no volvería a ver, cosa de finales de los años 90), hacia los componentes de la plataforma Java J2EE (Java 2 Platform, Enterprise Edition), como servlets y EJB (Enterprise JavaBeans), y hacia el propio middleware: las interfaces ADF (Application Development Framework) para las Human Tasks (una versión de Oracle de las JSF, JavaServer Faces), los Mediators, para el enrutamiento, filtrado y transformación de datos entre diferentes componentes, los BPEL (Business Process Execution Language) y BPMN (Business Process Model and Notation) para la orquestación de servicios y tareas, y las Business Rules, para la elaboración de un conjunto de reglas ejecutadas en runtime, por separado del código de la aplicación. Sin hablar de la integración con sistemas heredados vía SOAP (Simple Object Access Protocol), el WCF de nuevo, y toda su especificación en XML: XSD, XSLT y XPath. Lo confieso: es una ensalada de letras y términos. Pero va más allá: todo esto interconectado a bases de datos on-premises Oracle 11c o 12c y versionado en parte en SVN (Apache Subversion) y en parte en Microsoft TFS (Team Foundation Server), ambos modelos centralizados de control de versiones.

Figura 3. Un proceso BPEL en Oracle JDeveloper, orquestando las llamadas entre servicios.

El salto de calidad

Me fue bien, y dominar rápido ese stack enterprise de Oracle me trajo reconocimiento. Mi situación mejoró: recibí una propuesta para pasar a planilla de la compañía, a mediados de 2017, dejando de ser tercerizado y pasando a disfrutar de un plan de carrera y mejores beneficios. Aprovechando esa mejora, llegó por fin el momento de dejar mi pequeño apartamento y alquilar mi primer apartamento de verdad. También terminé mi MBA y, cuando me sorprendía reflexionando sobre todo lo que había pasado, me daba cuenta de que, en ese momento, la vida realmente había dado un gran salto de calidad.

Figura 4. Una de mis fuentes de estudio teórico sobre las herramientas de Oracle Suite fue este pequeño manual de 900 páginas.

Pasé los dos años siguientes en una rutina continua de mucho trabajo en la aseguradora, en mi equipo de Workflows. Curiosamente, esa habilidad con la orquestación de APIs (Application Programming Interfaces) sería de gran valor en proyectos futuros. Las nuevas fases del proyecto SOA se fueron expandiendo hacia nuevas áreas: creé paneles gerenciales y actualicé algunas tecnologías de la compañía, a pedido de la casa matriz estadounidense.

Pero el trabajo no bastaba. Seguí firme en mi rutina de estudio, leyendo sobre Agile, Microservicios, Enterprise Integration Patterns y otros temas de arquitectura de software, hasta sentirme desafiado a sacar certificaciones de Microsoft. Para eso, armé una rutina de estudio basada en los libros de Exam Ref de la propia Microsoft y en materiales complementarios de Packtpub. En un año y medio, obtuve tres: la MCP (Microsoft Certified Professional), la MCSA (Microsoft Certified Solutions Associate) y la MCSD (Microsoft Certified Solutions Developer), en las áreas de C#, ASP.NET MVC y Windows Azure.

Figura 5. Mi insignia de Microsoft Certified Solutions Developer, obtenida en 2019.

Hoy en día tal vez esas insignias tengan poca utilidad práctica, pero el desafío de estudiar y profundizar en temas muchas veces descuidados es una forma riquísima de aprendizaje. Sin contar que, para mí personalmente, fue mi punto de partida para consumir material en inglés. Antes no recuerdo haber tenido la experiencia de leer y estudiar libros de 500 páginas en otro idioma. Estoy agradecido por haber tomado esa decisión.

De vuelta al principio y nuevas incertidumbres

Con todo ese conocimiento en desarrollo .NET, cloud de Azure y también en herramientas de SDLC (Software Development Life Cycle), como VSTS (Visual Studio Team Services), más tarde renombrado como Azure DevOps, me llamó, a inicios de 2018, mi primera empresa, para prestar una consultoría externa en una nueva solución que estaban desarrollando: un sistema de ventas omnichannel, desarrollado totalmente desde cero con tecnología Microsoft. Acepté el desafío y los impulsé en la creación de la arquitectura de esta nueva solución, basada en microservicios, ya en .NET Core 2.0.

Seguí manteniendo esos dos frentes de trabajo en paralelo, y en 2019 abrí uno nuevo: comencé una Maestría en TI en la PUC-SP (Pontifícia Universidade Católica de São Paulo, Pontificia Universidad Católica de São Paulo), presentando un proyecto de investigación de Internet de las Cosas aplicado al Saneamiento Básico de São Paulo, motivado por el deseo de, en el futuro, tener la oportunidad de dar clases en alguna universidad.

Ya llevaba 3 años y algunos meses en la aseguradora, y sentía cierta desconexión entre mi expectativa de carrera y mi valoración profesional. Decidí que en ese momento haría un nuevo cambio y, algunos meses después, cambiaría por completo de contexto una vez más, y, quién lo diría, volvería a una empresa con ambiente de startup, pero ahora en otra área: la de salud. Podría decir que ya era prácticamente un programador senior, al menos en la actitud, con mucho más bagaje y transmitiendo confianza en mis habilidades técnicas y de gestión del tiempo como colaborador individual, gracias a la extensa rutina de trabajo en dos proyectos completamente diferentes en tecnología, escala y desafíos.

Todavía no lo sabía, pero una vez más el tiro erraría el blanco. Y en un momento sumamente delicado, porque el año era 2020, pocos meses después del primer caso registrado de SARS-CoV-2, en China [2]. De ahí en adelante, nada volvería a ser como antes.

Lista de referencias

Mi Midpoint de Carrera, Parte I

Mon, 21 Sep 2026 00:00:00 GMT

Prólogo

En septiembre de 2026 cumplí 15 años de carrera en Tecnología de la Información, mis Bodas de Cristal. Fue tiempo suficiente para acumular historias y experiencias entre el mercado laboral y la vida académica. Decidí revisitar esos recuerdos y registrar aprendizajes e historias curiosas, preservando a los involucrados tanto como sea posible.

Figura 1. 15 años de carrera, mis Bodas de Cristal.

Podría abrir con un prefacio sobre el período anterior a mi primer empleo formal, el Curso Técnico de Informática y mis primeras experiencias con computadoras, pero ese capítulo queda para el futuro.

Esta historia tendrá tres partes principales, hitos que considero importantes de varios años cada uno, con un período de filler entre ellas: historias menores, pero no menos interesantes de recordar.

Como no podía ser de otra manera, comenzaremos con el llamado a la aventura.

Pasantes, empanadas fritas y cementerios

En junio de 2011, aceptado en el Programa Universidade para Todos (PROUNI) y con una beca garantizada en São Paulo para estudiar Sistemas de Información, tomé mi primera gran decisión: dejar la casa de mis padres, en el interior, para vivir en la capital, a los 17 años. Ya cursaba el primer semestre de Análisis y Desarrollo de Sistemas en mi ciudad natal, pero nada se compararía al cambio de rutina, escala y desafíos que llegaron ya en los primeros meses de esta nueva vida.

No bastaba con estudiar. Todos los días enfrentaba más de 100 km de traslado entre ida y vuelta, desde Tatuapé, en la Zona Este de São Paulo, hasta Cotia, en la Región Metropolitana de São Paulo (RMSP). En esos primeros meses, fui acogido por mi tía materna, Cida, a quien le tengo una inmensa gratitud. Ella sin duda trabajaba tanto como yo y, a pesar de ser estricta, es una persona extremadamente protectora.

Ese desafío de traslado, sumado a la rutina de la casa, me obligó a salir a buscar trabajo: aprovechar el trayecto diario entre casa y la universidad para ganar algún sustento, conquistar mi propio espacio y ahorrar horas de traslado.

Buscando en el añorado sitio APInfo, envié currículums para vacantes de pasantía ya en el primer mes de universidad. La primera entrevista, por suerte, me dio mi primer trabajo remunerado, en septiembre de 2011: una consultora de software de pequeño porte, pero con un gran contrato de un Enterprise Resource Planning (ERP), sistema de gestión empresarial, para una importadora y minorista de ropa, calzado y accesorios.

Como pasante, recibí un salario un poco por encima del mínimo de la época (R$ 545,00) y una ayuda de costo, una especie de vale de comida en efectivo. Para alguien de 17 años que antes no tenía nada, fue un gran logro.

Sin embargo, mi productividad y mi concentración, especialmente en las materias de cálculo y durante mi ramp-up en la empresa, en la que necesitaba dedicarme mucho más para absorber el conocimiento, se veían afectadas por los largos traslados: durante algunos meses, salía de casa a las 5:30 a. m. para llegar al trabajo, en la Zona Sur, a las 10 a. m., donde me quedaba hasta las 17 h. Antes de la universidad, hacía una parada obligatoria en un puesto de empanadas fritas frente a una iglesia: una simpática empanada con algún recuerdo de relleno, por unos R$ 4,00, siempre reforzada con snacks de fécula sabor guayaba en la mochila. Luego seguía hacia la universidad, en la Zona Este. En el camino de vuelta, la integración hacia la Línea 4 ya estaba cerrada, así que tomaba el autobús frente al Cementerio de la Consolación y bajaba a pie por toda la Cardeal Arcoverde, entre bares sospechosos y locales de dudosa reputación, hasta el Largo da Batata, donde abordaba uno de los dos últimos autobuses intermunicipales, a las 23:45 o a las 00:10. Llegaba a casa, me acostaba y, pocas horas después, todo volvía a empezar.

Más que el sueldo, sin embargo, fue el aprendizaje en aquel ambiente de consultoría, donde todos los desarrolladores hacían de todo un poco: creaban funcionalidades, encontraban y corregían problemas, se metían con bases de datos e infraestructura, conviviendo con gente de la misma franja etaria y mucha disposición para apagar incendios. La complejidad del negocio abarcaba todas las áreas de una empresa mediana: inventario, logística, temas fiscales, tablas de precios, ventas, Puntos de Venta (PDV) y contabilidad.

Windev, el Rapid Application Development francés

La tecnología que usábamos en esa época, Windev, ya parecía un poco anticuada: un entorno de desarrollo rápido de aplicaciones, el llamado Rapid Application Development (RAD), con el que desarrollábamos el ERP y las aplicaciones Point of Sale (PoS), los sistemas de punto de venta. La herramienta abstraía los frameworks más populares de la época, Java y .NET Framework, con un framework propio: IDE propio, lenguaje propio y base de datos propia, aunque contaba con conectores para otros proveedores. En nuestro caso, usábamos Microsoft SQL Server como Sistema Gestor de Base de Datos (SGBD).

Figura 2. Interfaz del IDE Windev.

Windev es un IDE creado por una empresa francesa, PCSoft, con un entorno integrado para desarrollo de aplicaciones de escritorio, web y móviles: lenguaje propietario, WLanguage, base de datos propia, HyperfileSQL (HFSQL), e interoperabilidad con otros lenguajes y bases de datos mediante APIs y drivers.

Algunas peculiaridades provienen de la propia elección de diseño del IDE, de gusto bastante particular, y del lenguaje propio, fruto de la época: un lenguaje de cuarta generación (Fourth-Generation Language, 4GL). La propuesta era acelerar el desarrollo generando artefactos automáticamente tras integrar una base de datos al proyecto: los metadatos se convertían en un modelo abstracto llamado Analysis, parecido al Entity Data Model de .NET Framework, y, a partir de él, reportes y pantallas salían con pocos clics, algo así como Crystal Reports, de SAP, o ADF, de Oracle, para interfaces ricas.

En la práctica, esto significaba que yo no necesitaba entender a fondo la base de datos para entregar una pantalla funcionando, lo cual, mirando hacia atrás, fue bueno y malo a la vez.

El lenguaje también ofrecía fetch de datos automático: bastaba iterar colecciones con bindings al modelo de datos, y el metamodelo se encargaba de traducir todo en consultas a la base de datos, fuera HFSQL u otra compatible, vía conectores OLE DB/ODBC.

Un ejemplo simple: una búsqueda de cliente por nombre, seguida de una iteración sobre la colección resultante, sin escribir una sola línea de SQL.

// Buscar primer cliente con nombre "João"
HReadSeek(Customers, Name, "João")

IF NOT HFound(Customers) THEN
    Info("Cliente no encontrado")
    RETURN
END

// Iterar sobre todos los registros encontrados
FOR EACH Customers
    sName = Customers.Name
    sEmail = Customers.Email
    nID = Customers.CustomerID
    Info(nID + " - " + sName + " (" + sEmail + ")")
END

Evidentemente, esto generaba problemas de rendimiento y comportamientos ocultos en la base de datos, ya que ese tipo de abstracción prioriza el best-effort incluso a costa del mal uso de índices y consultas poco optimizadas. El resultado eran situaciones caóticas en escenarios de escala, o donde había restricciones de rendimiento, como en aplicaciones de cara al usuario en las terminales de venta. En esos casos, recurríamos con frecuencia al uso de Stored Procedures escritas en Transact-SQL para ejecutar operaciones más costosas, como calcular flujos de caja, reprocesar inventarios o tablas de precios, y generar reportes de vendedores.

En ese período, el software que entregábamos tenía un carácter bastante artesanal: especificaciones y reportes de bugs recogidos en el pasillo, por teléfono, o en interminables hilos de correo electrónico. Esto nos obligó a crear y mantener, también in-company, un service desk para reunir issues y reportes de problemas. Yo, que siempre tuve una vena creativa, asumí el soporte de ese sistema para hacerlo evolucionar, creando funcionalidades, reportes y dashboards, y mejorando nuestro día a día de trabajo.

Aunque Git ya existía desde 2005, mi experiencia con la gestión de código fuente todavía era bastante rudimentaria: carpetas compartidas en la red, sin control de versiones, y después un sistema centralizado de control de versiones (CVS, Concurrent Versions System) del propio proveedor de Windev, que más de una vez corrompió el historial de los archivos y nos obligó a recurrir a copias de seguridad físicas. Los despliegues seguían la misma lógica artesanal: builds comprimidos, transferidos por FTP, con configuraciones de acceso en texto plano en archivos .ini. Fue nuestra realidad durante años.

PHP de la vieja escuela y otros proyectos

Además del ERP y su sistema de PoS, la consultora también trabajaba con proyectos más pequeños, como e-commerces y sistemas de gestión hotelera. En esos casos había más flexibilidad de tecnologías, y llegamos a usar PHP y MySQL en el paquete LAMP (Linux-Apache-MySQL-PHP), ya en sus últimos suspiros en el mercado, que seguía migrando hacia el paquete Node.js y nginx, aunque nosotros seguíamos con él.

En ese momento, el conocimiento de frameworks en el mundo PHP era totalmente experimental, al menos para mí. Recuerdo estudiar CodeIgniter en el libro de Ademir Gabardo y usarlo en mi TCC (Trabajo de Fin de Carrera), donde también tuve contacto con la cultura maker, usando Arduino y Raspberry Pi para prototipar un medidor de agua inteligente, proyecto que genuinamente obtuvo la nota máxima de evaluación. Profesionalmente, sin embargo, el PHP que yo usaba era el de la vieja escuela de los años 2000: archivos .php con bloques de script mezclados con HTML, compartiendo espacio con plugins icónicos de la época, como jQuery, para controlar el DOM, validaciones del lado del cliente y animaciones, morris.js y chart.js, para gráficos estilizados. Bootstrap todavía estaba en sus primeras versiones, incorporándose poco a poco en mis proyectos.

Figura 3. Libro de PHP y MVC (Model-View-Controller) con CodeIgniter, mi primer framework web.

Estudiando por cuenta propia: el mundo .NET

Pasados algunos meses, fui contratado de forma permanente como Analista Programador Júnior y, con un salario mayor, me mudé a un pequeño apartamento cerca de una estación de metro en la Zona Oeste. La calidad de vida mejoró de inmediato: por fin dormía noches completas.

Solo trabajar con Windev y PHP de la vieja escuela no me satisfacía. En conversaciones con mi gran amigo Mark, para mí una leyenda de la programación (especialmente, pero no solo, en Java), siempre al tanto de las mejores prácticas de ingeniería, quien me enseñó arquitectura de software incluso antes de que yo conociera el término, me di cuenta de que quedarme solo con las tareas del día a día me estaría alejando de los estándares del mercado. Empecé entonces a estudiar .NET por mi cuenta, adentrándome en C# y ASP.NET MVC a través de los enormes volúmenes de la serie Step-by-Step, del añorado John Sharp, y de libros de la también añorada editorial Casa do Código, como el fabuloso libro de TDD (Test-Driven Development) de Maurício Aniche, además de algunos libros de Windows Phone, ya que yo era un early adopter y entusiasta de la línea Nokia Lumia 💀. Todavía era temprano, pero esa inquietud por estudiar más allá de la rutina se convertiría en la base del repertorio que construiría de ahí en adelante.

Figura 4. Libro Visual C# 2008, de John Sharp — un volumen enorme.

Hora de seguir adelante

Cuando me di cuenta, habían pasado tres años y ya era Analista Programador Semi Senior. Hubo muchos despliegues de nuevas versiones del ERP, optimizaciones en el flujo de caja de grupos de marcas, aperturas de nuevas tiendas, funcionalidades creadas y eventualmente recreadas para diversos registros, integraciones con impresoras térmicas, e incluso el armado de stands de eventos en el Anhembi. Había hecho grandes amigos en ese trayecto y ya estaba a punto de terminar la carrera, en el último semestre.

Fue entonces cuando llegaron las ganas de buscar cambios: salir de la zona de confort y volver a arriesgarme en busca de nuevos desafíos. Sin mucha ceremonia, volví a sondear el mercado y, en mayo de 2015, recibí una propuesta que, en ese momento, me pareció la promesa de nuevos aires. Así llegó la hora de despedirme, en esta empresa, de los amigos que me acogieron y tanto me enseñaron en esta etapa inicial del camino (años más tarde regresaría para un nuevo y duradero proyecto).

De ahí pasé a una nueva consultora de software, pero esta vez en un proyecto totalmente diferente, ahora en la Policía Tecnocientífica. Todavía a punto de graduarme de la universidad, en ese mismo primer semestre de 2015, fue ahí donde conocí la doble jornada laboral, pero eso quedará para la próxima parte.

Dedico el cierre de esta parte a todos los que, en aquel momento, formaron parte de mi camino: a Mark, a Vê, a los hermanos Diego y Thiago, a Marcão, a Luiz XV, a Adrian 2, a Abel, a Dengo, y a tantos otros.

Mi Biblioteca Anual: Libros Leídos de 2021 a 2025

Thu, 26 Dec 2024 00:00:00 GMT

Presentación

Para mí, la lectura, antes de ser un trabajo, fue y siempre será un pasatiempo, desde el colegio, cuando leía cómics y revistas de videojuegos. Con la intención de cultivar esa disciplina, ya sea como ocio o para alcanzar objetivos personales y profesionales, creé una lista anual, desde 2021, con las lecturas que hice en esos tres ámbitos.

De esta forma, este registro me servirá a mí y a otros que busquen recomendaciones, como una manera de evaluar mis intereses pasados y presentes, que guían mis decisiones y mis objetivos de vida.

Libros Leídos por Año

2025

Categoría	Título	Autor(es)	Tema/Género	Capítulos Leídos / Completado
Ocio	El Hobbit	J.R.R. Tolkien	Fantasía	Completado
Ocio	Vidas secas	Graciliano Ramos	Novela	Completado
Ocio	La fábula del Estado de la Isla: Cómo funcionan la economía y los mercados	José Kobori	Finanzas	Completado
Desarrollo Personal	Proyecto de vida: Caminos hacia una vida que valga la pena	Clóvis de Barros Filho	Filosofía	Completado
Desarrollo Personal	Liderazgo: La inteligencia emocional en la formación del líder de éxito	Daniel Goleman	Negocios y liderazgo	Completado

2024

Categoría	Título	Autor(es)	Tema/Género	Capítulos Leídos / Completado
Ocio	São Paulo en las alturas: La revolución modernista de la arquitectura y el mercado inmobiliario en los años 1950 y 1960	Raul Juste Lores	Arquitectura	Completado
Ocio	El Señor de los Anillos: Volumen Único	J.R.R. Tolkien	Fantasía	Completado
Funcionales	Team Topologies: Organizing Business and Technology Teams for Fast Flow	Matthew Skelton; Manuel Pais	Negocios y liderazgo	1
Funcionales	Unit Testing Principles, Practices, and Patterns	Vladimir Khorikov	Desarrollo de software	1 ~ 11
Funcionales	Site Reliability Engineering: How Google Runs Production Systems	Jennifer Petoff; Niall Murphy; Betsy Beyer; Chris Jones	Desarrollo de software	1 - 3 - 4 - 6
Funcionales	El pipeline de liderazgo: El desarrollo de líderes como diferencial competitivo	Ram Charan; Stephen Drotter; James L. Noel; Kent Jonasen	Negocios y liderazgo	1 - 2 - 3 - 8 - 9
Desarrollo Personal	El caballero de la armadura oxidada	Robert Fisher	Aventura	Completado
Desarrollo Personal	Lo mejor del mundo: Sepa cuándo insistir y cuándo desistir	Seth Godin	Negocios	Completado

2023

Categoría	Título	Autor(es)	Tema/Género	Capítulos Leídos / Completado
Ocio	Inédita pamonha	Clóvis de Barros Filho	Filosofía	Completado
Funcionales	Sin reglas: Netflix y la cultura de la reinvención	Reed Hastings	Negocios y liderazgo	Completado
Funcionales	The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise	Gregor Hohpe	Desarrollo de software	1 ~ 17
Funcionales	El Programador Pragmático: De Aprendiz a Maestro	Andrew Hunt; David Thomas	Desarrollo de software	1 ~ 4
Funcionales	Code That Fits in Your Head: Heuristics for Software Engineering	Mark Seeman	Desarrollo de software	1 ~ 7

2022

Categoría	Título	Autor(es)	Tema/Género	Capítulos Leídos / Completado
Ocio	Fahrenheit 451	Ray Bradbury	Ciencia ficción	Completado
Ocio	Un país llamado Brasil: La historia de Brasil desde el descubrimiento hasta el siglo XXI	Marco Antonio Villa	Historia	Completado
Funcionales	El arte de la gestión: una guía práctica para integrar liderazgo y recursos humanos en tecnología	Camille Fournier	Negocios	Completado
Desarrollo Personal	El gran libro del bebé	Thatiane Mahet	Maternidad y paternidad	Completado

2021

Categoría	Título	Autor(es)	Tema/Género	Capítulos Leídos / Completado
Ocio	Los ingenieros del caos	Giuliano da Empoli	Política	Completado
Ocio	Filosofía para mortales: Pensar bien para vivir bien	Daniel Gomes de Carvalho	Filosofía	Completado
Ocio	Un mundo feliz	Aldous Huxley	Ciencia ficción	Completado
Ocio	La vuelta al mundo en 80 días	Julio Verne	Aventura	Completado
Funcionales	La cuarta revolución industrial	Klaus Schwab	Economía	Completado
Funcionales	El trabajo no tiene que ser una locura	David Heinemeier Hansson; Jason Fried	Negocios	Completado

En los próximos años, tengo la intención de mantener esta lista actualizada, con el objetivo de registrar mis lecturas y compartir mis experiencias con otros lectores. Además, espero que esta lista ayude a reflexionar sobre mis intereses y a mantenerme motivado para seguir leyendo y aprendiendo.

Hasta luego. 📚☕

Café Tecnológico: Principios Fundamentales de las Pruebas Unitarias

Sat, 07 Dec 2024 00:00:00 GMT

Presentación

Programación Asistida por IA: Acelerando el Desarrollo con Herramientas de Inteligencia Artificial

Sun, 10 Nov 2024 00:00:00 GMT

Contexto

Recientemente me encontré con una aplicación frontend de tamaño mediano escrita en Angular 6 (sí, cuyo EOL fue en 2019). La tarea era actualizar el proyecto a una versión LTS (Long Term Support) de Angular. Opté, como primer movimiento, por actualizar a la primera versión LTS disponible, la versión 16.2.X. Sin embargo, no soy especialista en frontend ni en el stack de Node.js, y necesitaría bastante tiempo o el apoyo de otro desarrollador con más conocimiento del framework.

El proyecto tenía 40 módulos y 175 componentes, distribuidos según la siguiente tabla:

===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 CSS                     6          334          271           20           43
 HTML                  180        11903        10206          693         1004
 JavaScript              4           78           49           19           10
 JSON                    2           22           22            0            0
 Sass                  247        12575         9431         1284         1860
 SVG                     2            4            4            0            0
 TypeScript            370        36123        27318         2904         5901
===============================================================================
 Total                 811        61039        47301         4920         8818
===============================================================================

La opción de contar con el apoyo de otro desarrollador no era viable, y tampoco podía dedicar semanas al proyecto de migración. Entonces decidí adoptar un enfoque que vi recientemente en canales de YouTube: experimentar con el uso de AI Code Assist en el IDE para que me ayudara. Aunque soy usuario de JetBrains IDEA y de GitHub Copilot para proyectos de backend, en este caso quería probar algo nuevo y más enfocado en mi objetivo: apoyarme en mi conocimiento elemental de frontend y del framework Angular, y trabajar en un estilo de pair programming tipo Driver and Navigator [1], alternando entre momentos en los que la IA generaba el código y yo lo revisaba, y viceversa.

Herramientas

Para esta tarea, opté por probar el editor de código Cursor [2], que cuenta con integración nativa de IA y promete un aumento de productividad con una serie de funcionalidades. A continuación, destaco las que usé, aunque existen otras más avanzadas descritas en la documentación [3].

Tab: para sugerir o editar código a partir de un fragmento existente o una descripción;
- Cursor Prediction: después de una edición realizada con Tab, Cursor predice fragmentos adicionales que pueden corregirse de la misma forma y salta automáticamente al siguiente fragmento con un nuevo tab ⇥;
Chat: para interactuar con la IA y entender un fragmento de código o pedir una sugerencia de implementación;
- AI Fix in Chat: donde se resalta un error detectado por el linter, y la IA abre un popup sugiriendo una solución;
- Apply: para aplicar las sugerencias de la IA directamente en el editor;

Para usar Cursor no es necesario tener una suscripción premium, aunque el uso es limitado [4]. En mi caso, opté por la suscripción Pro para garantizar el uso ilimitado de las funciones completions e instant apply.

Con Cursor, node en la versión 20.11 y el Angular CLI en la versión deseada instalados, comencé a trabajar.

Interactuando con la IA de Cursor

Lo primero que hice fue generar un nuevo proyecto con la versión 16 del Angular CLI y comparar las diferencias entre el proyecto antiguo y el nuevo. Noté que algunos archivos ya no eran necesarios, como angular-cli.json, mientras que otros necesitaban crearse o ajustarse, como angular.json, tsconfig.json, tslint.json y tsconfig.app.json. Le delegué a la IA la tarea de corregir esos archivos mediante interacciones con el siguiente formato:

Actualiza el archivo angular-cli.json (en el contexto) a la versión 16 de Angular.

Con el siguiente resultado:

Figura 1. Chat con la IA para actualizar el archivo angular-cli.json

Y el resultado de los cambios sugeridos por la IA se aplicaba directamente en el archivo deseado:

Figura 2. Resultado de los cambios sugeridos por la IA con la funcionalidad Apply

Una vez actualizados los archivos base del proyecto, pasé a las dependencias. Obviamente, muchas ya no existían, o habían cambiado de nombre. Por lo tanto, tuve que corregir manualmente algunas dependencias a partir de búsquedas en npm.js, como por ejemplo angular-http, que fue incorporado a angular-common, o angular2-fontawesome, que fue descontinuado y reemplazado por @fortawesome/angular-fontawesome.

Una vez actualizadas las dependencias, y después de muchos npm install, llegó la hora de intentar ejecutar ng build y empezar a encontrarme con los primeros errores.

Fase de build del backend

Los proyectos Angular se dividen en dos grandes partes: el backend, con componentes, módulos y servicios; y el frontend, compuesto por templates, directivas, pipes y módulos de interfaz de usuario.

En cinco años cambian muchas cosas, y en el caso de los proyectos frontend, los cambios fueron aún mayores.

Mi enfoque fue ejecutar primero ng build para compilar el backend, y, como era de esperar, ocurrieron muchos errores de build, especialmente por la configuración strict de tsconfig.json, que ahora exigía que todas las variables estuvieran tipadas. Aunque podría haber desactivado esa configuración, preferí, con la ayuda de la IA, corregir los errores de tipado en cada archivo, usando las funcionalidades mencionadas al inicio del artículo. Además, muchas dependencias cambiaron de namespace, siendo uno de los principales ejemplos la separación de los componentes de Angular Material, que antes estaban bajo el namespace @angular/material.

Cientos de Tabs después, ng build finalmente compiló sin errores, y pude pasar a la fase de build del frontend.

Fase de build del frontend

Ahora ng serve necesitaba compilar el frontend. Obviamente, muchas directivas habían cambiado, como el binding de propiedades y eventos, que tuvieron que corregirse.

La explicación que dio la IA de Cursor para un error durante la migración del binding de evento fue la siguiente:

El cambio que mencionaste en la directiva de Angular de maxlength='100' a [maxLength]='100' refleja una actualización en la forma en que se vinculan las propiedades en Angular, especialmente en relación con el uso del property binding.

Explicación del Cambio:

Property Binding:

Antes (Angular 6): La directiva usaba la sintaxis de atributo HTML estándar, donde maxlength se definía como un atributo HTML con un valor literal. Esto significa que el valor se trataba como una cadena de texto.

Ahora (Angular 16): La nueva sintaxis [maxLength]='100' utiliza el property binding de Angular. Esto permite que el valor se trate como una expresión de Angular, lo que significa que puedes pasar variables, expresiones o valores dinámicos.

La ventaja de contar con la IA proporcionando tanto la corrección como la explicación del cambio fue que pude usar la función de Search All and Replace para corregir de una sola vez todos los fragmentos similares que necesitaban modificarse.

Otro error frecuente era la falta de manejo de valores null al acceder a propiedades de objetos, algo que TypeScript no aceptaba y debía corregirse. Este es un problema recurrente en proyectos legados, y la IA fue capaz de corregirlo a partir de sugerencias de Tab.

Después de un tiempo, ng serve finalmente compiló sin errores, y pude acceder a la aplicación en el navegador.

Publicando la aplicación y creando el Pull Request

Con la aplicación funcionando, solo restaba actualizar el archivo de pipeline para usar una versión más reciente de Node.js y crear el Pull Request en el repositorio.

Este fue el resultado final de la rama enhancement/bump-up-angular-16:

 397 files changed, 20290 insertions(+), 19788 deletions(-)

Conclusión

El término "Programación Asistida/Guiada por IA", y otros similares, estarán cada vez más presentes en el día a día de los equipos de ingeniería de software. Estudios de Gartner prevén que, para 2028, el 75% de los desarrolladores usarán herramientas de IA para escribir código [5]. Este movimiento ya es perceptible en la industria del software; Mercado Libre, por ejemplo, ya utiliza herramientas de IA para apoyar a sus más de 9.000 desarrolladores [6].

En este breve relato, pude observar que, aunque no era un profundo conocedor de un stack específico, la productividad en la ejecución de la tarea aumentó significativamente. Un esfuerzo que antes habría requerido semanas se redujo a pocos días. Sin embargo, el conocimiento y la experiencia del desarrollador son indispensables, ya que, como demostré, muchas veces es el propio desarrollador quien debe decidir cuál es el enfoque más adecuado para resolver el problema. Así, el criterio, la sensibilidad y la experiencia del desarrollador fueron esenciales y no fueron sustituidos.

Lista de referencias

SPA: ¿Azure App Services o Static Web Apps?

Sun, 11 Aug 2024 00:00:00 GMT

Contexto

Recientemente me encontré con una aplicación SPA (Single Page Application) escrita en Angular que se venía distribuyendo desde hacía mucho tiempo en un App Service de Azure.

App Services son plataformas como servicio (PaaS) totalmente gestionadas, utilizadas para entregar aplicaciones web en diversos lenguajes, frameworks y sistemas operativos. Por ser gestionadas, ofrecen diversas configuraciones listas para usar, como escalado automático (scale up y scale out), dominios personalizados, SSL personalizado, integraciones de despliegue con GitHub Actions, Azure DevOps, entre otras capacidades.

Pero, ¿será que un PaaS con tantas capacidades es la mejor opción para distribuir una SPA? Probablemente sí, pero tal vez no sea la más eficiente. Cualquier SPA moderna se reduce a un conjunto de archivos estáticos, que normalmente el navegador del cliente descarga en su totalidad. Por eso existen métodos más eficientes para distribuir esos archivos estáticos, aprovechando las capacidades que ofrecen las CDN.

CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente, diseñada para entregar contenido estático de manera eficiente, acercando esos assets al cliente final.

CDNs como Akamai, Verizon, entre otras, son extremadamente cacheables y relativamente económicas, considerando el volumen de tráfico en comparación con la infraestructura de servidores web y el tráfico de salida de soluciones de almacenamiento, como S3 y Azure Blob Storage.

Con esto en mente, Azure creó una solución que combina algunas capacidades de un App Service con una red distribuida geográficamente para la publicación de assets: el servicio Static Web Apps.

Figura 1. ¿Static Web Apps o App Services para la distribución de estáticos?

Static Web Apps

Además de la capacidad de distribuir SPAs desarrolladas en frameworks como Angular, React, Vue, Blazor, o incluso en HTML simple con CSS y JavaScript, Static Web Apps también permite una rápida integración con Azure Functions, que funcionarán como backend para la SPA, facilitando las restricciones de CORS y simplificando la infraestructura, ya que no será necesario mantener un servidor web completo [1].

Algunas de las principales funcionalidades de SWA incluyen (consultar las cuotas del servicio [2]):

Fácil integración con GitHub Actions y Azure DevOps Pipelines.
Distribución global de assets.
Certificados SSL gratuitos.
Permite la personalización de dominios.
Primeros 100 GB de tráfico de salida/mes incluidos.
Integración con sistemas de autenticación como Microsoft Entra ID y GitHub.
Creación y publicación de múltiples entornos.
SLA del 99,95%.

Se puede argumentar que una solución de distribución usando Blob Storage y Azure Front Door puede lograr el mismo resultado, pero Front Door tiene un precio superior, por ser un producto más robusto y por ofrecer funciones avanzadas de distribución y enrutamiento entre regiones, que pueden ser innecesarias en casos de uso donde simplemente se desea entregar contenido estático de aplicaciones web.

A continuación, una tabla comparativa en relación con el costo de cada solución:

Solución	¿Tiene nivel gratuito?	Costo de contratación
Azure App Services	Sí	Desde USD 73,00 en el plan Standard
Static Web Apps	Sí	USD 9,00 por aplicación
Blob Storage + Front Door	No	(BS v2 LRS) Desde USD 22,00 + (FD) Desde USD 46,00 en el plan Standard

En síntesis, Static Web App es una alternativa simple, económica y confiable para la distribución de aplicaciones SPA en comparación con otros modelos ofrecidos por Azure.

Lista de referencias

Pipeline de Liderazgo — El Trayecto hacia el Nivel Táctico

Mon, 04 Mar 2024 00:00:00 GMT

Presentación

Cualquier empresa, independientemente de su sector, tamaño y ubicación geográfica, tiene dos características en común: una estructura, sea cual sea, y una cultura organizacional, construida o emergente. Estos dos temas se relacionan al definir cuán jerarquizada será la estructura de la empresa y cuántos niveles son necesarios para gestionar las distintas áreas, además de determinar qué áreas son responsables de qué vertientes de la compañía. Aunque en principio estas estructuras parezcan perennes y fundamentales, no siempre se consideran saludables o despejadas, ya que esto requiere una cuidadosa organización de las transiciones de liderazgo, con atribuciones y responsabilidades debidamente establecidas y, en la medida de lo posible, sin superposiciones.

Figura 1. Pipeline se refiere a la estructura secuencial y progresiva a través de la cual los individuos evolucionan en sus capacidades de liderazgo, desde funciones básicas hasta el más alto nivel de gestión dentro de una organización.

El libro "Pipeline de Liderazgo: El Desarrollo de Líderes como Diferencial Competitivo" [1], escrito por Ram Charan, Stephen Drotter y James Noel, presenta un modelo para entender y desarrollar las diferentes capas de liderazgo dentro de una organización. Sugiere que el desarrollo de liderazgos eficaces requiere un entendimiento claro de los requisitos, desafíos y transiciones asociados a cada etapa de la estructura.

Esta estructura, denominada "pipeline", se asemeja a una escalera que el profesional debe subir, compuesta por siete niveles. En cada transición de nivel ocurre una nueva transición de liderazgo, y cada nivel está representado por un determinado cargo dentro de una estructura organizacional, como se muestra en la Tabla 1.

Nivel del Pipeline	Cargo Representativo	Descripción Breve
1. Autogestión	Colaborador Individual	Foco en el desarrollo de habilidades técnicas y profesionales, gestionando el propio tiempo y tareas.
2. Gestor de Otros	Líder de Equipo / Supervisor	Responsable de gestionar el trabajo de otros, motivar al equipo y evaluar el desempeño.
3. Gestor de Gestores	Gerente de Gerentes / Director	Se enfoca en orientar a otros gerentes, desarrollando sus habilidades de liderazgo y estrategia.
4. Gestor Funcional	Gerente de Departamento	Supervisa un área específica de la empresa, como finanzas o marketing, implementando estrategias funcionales.
5. Gestor de Negocios	Gerente General / CEO de Unidad de Negocio	Responsable del desempeño general de una unidad de negocio, incluyendo rentabilidad y estrategia de mercado.
6. Gestor de Grupo	CEO de Grupo / Vicepresidente	Gestiona múltiples unidades de negocio o regiones, asegurando la alineación estratégica y operativa.
7. Gestor Corporativo	CEO / Presidente	Lidera la organización en su conjunto, estableciendo visión y estrategia corporativas, guiando la cultura organizacional.

Tabla 1. Niveles del Pipeline y el cargo correspondiente en una compañía tradicional.

Los niveles y sus respectivas transiciones de liderazgo son representados por los autores a través del pipeline ilustrado en la figura referenciada a continuación. La Figura 1 muestra la progresión de cada etapa dentro de la estructura organizacional.

Figura 2. Progresión de liderazgo en el pipeline. (Adaptado de: CHARAN, Ram; DROTTER, Stephen; NOEL, James, 2011, p.27)

En esta reseña, presentaré de forma resumida las ideas principales de las dos primeras transiciones, además de reflexionar sobre la necesidad de que cada una esté bien establecida.

Del Colaborador Individual al Nivel Táctico

La gestión empresarial establece desde hace tiempo que, en general, existen tres niveles organizacionales en las empresas: el operativo, relacionado con las tareas del día a día y de corto plazo; el táctico, que traduce directrices estratégicas en planes de acción de mediano plazo; y el estratégico, que define la dirección general y los objetivos de largo plazo de la organización.

Figura 3. Niveles organizacionales de una empresa.

Bien delimitados y con un inicio claramente definido, los profesionales al comienzo de su carrera pasarán sus primeros años en una organización como colaboradores individuales, normalmente encargados de tareas bien definidas, de corta duración y con objetivos muy bien determinados.

En este momento, el profesional se encargará de moldear sus habilidades, su gestión del tiempo y sus valores profesionales, entre otras características que demuestren la capacidad de asumir responsabilidades y respetar los valores de la empresa. Una vez comprobado que estos tres puntos se han desarrollado razonablemente, este profesional será, por lo general, promovido a líder o gerente de primer nivel.

"Para desarrollar líderes eficaces [...], las organizaciones necesitan identificar tempranamente a los candidatos a líder, ofrecerles tareas para su crecimiento, darles retroalimentación útil y asesorarlos. (p.31)"

Es importante señalar que la denominación del cargo puede variar de una empresa a otra — pudiendo ser líder, coordinador, gerente de primer nivel, entre otros —, pero lo esencial es enfatizar que, en esta primera transición de liderazgo, el nuevo líder estará gestionando no solo a sí mismo, sino también a otras personas, lo que exige una transición conductual y de habilidades y valores fundamentales para el éxito en el cargo.

Estas nuevas habilidades, descritas en la Tabla 2, incluyen planificar el trabajo, asignar tareas, motivar y evaluar críticamente el trabajo realizado por otras personas, es decir, no solo concluir el trabajo que se le asigna, sino también ayudar a otros a alcanzar el desempeño esperado. En este punto, es crucial que el trabajo gerencial sea valorado, y no solo tolerado, ya que dedicar tiempo a atender las demandas del equipo, resolver dudas, buscar contactos y diálogo con otros equipos, departamentos y proveedores es fundamental para alcanzar los objetivos de sus liderados y, en consecuencia, determinar su éxito.

Para los nuevos líderes, desprenderse de las tareas y habilidades que los llevaron a un cargo de liderazgo puede ser un desafío, pero es necesario comprender que, en este nuevo nivel, los resultados se obtienen a través de los demás. El éxito de los subordinados directos refleja el éxito del líder. Por lo tanto, es esencial verse a sí mismo como un gestor, que define el trabajo a realizar y permite que este sea ejecutado por sus subordinados, con confianza y responsabilidad, enseñando en lugar de solo corregir errores, y manteniéndose cerca de los problemas y fracasos que enfrenta el equipo. Los líderes en esta primera transición deben, ante todo, ser accesibles y estar disponibles, tanto física como emocionalmente, demostrando que, a través de la accesibilidad, dominan la gestión de su propio tiempo.

Aspecto	Colaborador Individual	Gerente de Primer Nivel
Habilidades	Dominio técnico/especializado, trabajo en equipo, desarrollo de relaciones para beneficio personal, uso de herramientas/procesos	Planificación, definición de cargo, selección, delegación, monitoreo, coaching/feedback, evaluación de desempeño, motivación, comunicación, desarrollo de relaciones para beneficio del departamento, adquisición de recursos
Gestión del Tiempo	Disciplina diaria, cumplimiento de plazos personales, administración del propio tiempo	Planificación anual, disponibilidad para subordinados, definición de prioridades, tiempo de comunicación con otras áreas
Valores Profesionales	Obtención de resultados por proficiencia, trabajo de alta calidad, incorporación de los valores de la empresa	Obtención de resultados a través de otros, éxito de los subordinados, éxito del departamento, integridad

Tabla 2. Características de la Primera Transición de Liderazgo. (Adaptado de: CHARAN, Ram; DROTTER, Stephen; NOEL, James, 2011, p.64)

Cuando los líderes carecen de aptitud para la gestión del tiempo, enfrentan problemas en la planificación de tareas y en la determinación de prioridades para el equipo. Como resultado, con frecuencia no tendrán tiempo para ayudar a sus subordinados, lo que obstruirá el flujo de trabajo y probablemente sobrecargará tanto a ellos mismos como a los demás. De igual manera, la ausencia de los valores profesionales adecuados lleva a dificultades para delegar actividades. Muchas veces, estos líderes optan por realizar las tareas por su cuenta, descuidando la planificación. Esto resulta en la falta de métodos gerenciales apropiados, volviendo caótico el ambiente de trabajo y poco estables o poco eficaces las relaciones y comunicaciones con otros equipos.

La segunda transición — de gestor a gestor de gestores — en el liderazgo debe marcar una transición completa del enfoque operativo hacia la gestión táctica de los equipos, además de priorizar el desarrollo de los nuevos líderes. Esto incluye mentoría, coaching, retroalimentación continua y evaluaciones, además de delegar tareas que los incentiven a practicar habilidades de gestión del tiempo adecuadas para liderar un equipo.

Cuando estos líderes están mal formados o instruidos, pueden surgir ciertos problemas de gestión, lo que indica que estos gerentes de gestores pueden estar en la posición equivocada o aún no han desarrollado plenamente sus habilidades, incluyendo la gestión del tiempo y los valores profesionales. Entre estos problemas se destacan la dificultad para delegar, la mala gestión del desempeño de los gerentes de primer nivel, la incapacidad de desarrollar un equipo fuerte — quizás el principal problema, especialmente cuando hay favoritismos y falta de evaluación adecuada por competencia —, un enfoque excesivo en la ejecución del trabajo, y la tendencia a seleccionar colaboradores que sean clones de sí mismos, en lugar de optar por diversidad y competencia.

Para que los gerentes de gestores desempeñen su papel con excelencia, deberían concentrarse en la selección y capacitación de nuevos gerentes altamente competentes, exigir a estos líderes que rindan cuentas por el trabajo gerencial realizado, asignar recursos entre las unidades según sea necesario, y administrar los límites entre cada unidad de acuerdo con la estructura organizacional establecida.

Se observa que, en el modelo de pipeline establecido por los autores, no ocurre superposición de roles. La clara definición de habilidades, gestión del tiempo y valores profesionales esperados en cada etapa del proceso proporciona un ambiente propicio para el surgimiento de nuevos liderazgos. Así, se elimina la necesidad de contratar exclusivamente a profesionales destacados, permitiendo potenciar los liderazgos internos para que desempeñen sus roles de forma adecuada, sin competencia entre líderes y liderados por una misma acción.

Finalmente, al establecer los requisitos apropiados para los diferentes niveles de liderazgo, se facilita el proceso de planificación de sucesión, reduciendo la tensión emocional para los nuevos líderes recién promovidos. Como destacan los autores, "cuando alguien salta etapas de liderazgo y se lo coloca en una posición para la cual no posee las habilidades, el dominio de la gestión del tiempo y los valores profesionales necesarios, el impacto emocional es significativo. El modelo de pipeline hace improbable el salto de esas etapas."

Consideraciones

Establecer roles en una estructura organizacional siempre es un desafío. Se vuelve aún más difícil cuando estas definiciones no son claras y objetivas, o cuando falta un plan formal de coaching y formación por parte de los niveles superiores, que, según los autores, serían los responsables de formar a los sucesores. La ausencia de estas definiciones crea vacíos en el pipeline, lo que lleva a superposiciones de funciones: la situación de gerentes realizando tareas operativas en lugar de gestionarlas es quizás el síntoma más evidente del descuido de las habilidades necesarias, la gestión del tiempo y los valores profesionales requeridos para alcanzar un desempeño excepcional en el cargo.

Aunque esta disfunción es común, combatirla es fundamental. La formación de líderes en los primeros niveles de una estructura organizacional, que cumplan con los requisitos mencionados, es indispensable. Al fin y al cabo, es en las capas operativa y táctica donde todas las empresas, independientemente de su tamaño y sector, generan sus ingresos mediante el desarrollo de productos y servicios. Además, estos niveles representan la puerta de entrada para nuevos talentos, ya sea mediante reclutamiento o formación interna.

Finalmente, la adopción de este modelo representa un paso estratégico vital para las organizaciones que buscan no solo mantener su competitividad en un mercado en constante evolución, sino también garantizar un legado de liderazgo fuerte y sostenible a lo largo de los años.

Lista de referencias

Libro "Pipeline de liderazgo" – Amazon

Enlaces adicionales

The Leadership Institute — Resources

Navegando por Grandes Números: Un Viaje Profesional en el Corazón del E-commerce

Sat, 17 Feb 2024 00:00:00 GMT

Presentación

Reseña de la parte II del libro "The Software Architect Elevator"

Wed, 03 May 2023 00:00:00 GMT

Parte II – Arquitectura

Las diversas definiciones de arquitectura de software recopiladas por el Instituto de Ingeniería de Software de la Universidad Carnegie Mellon [1] sugieren que esta expresión no tiene un significado obvio cuando se examina de forma aislada. Aunque los términos "arquitectura" y "software" tienen significados delineados con precisión, su combinación intrínseca depende del contexto específico en el que se aplican.

Figura 1. La arquitectura de software es más que dibujar diagramas de componentes.

Gregor Hohpe postula que todo software tiene una arquitectura, aunque no sea intencional. Esa arquitectura debería impulsar la eficiencia de los equipos de ingeniería al permitir el desarrollo en paralelo y la evaluación de los componentes creados. Además, sostiene que ninguna arquitectura es perfecta y que siempre existe una combinación de decisiones a considerar, siendo el contexto el principio organizador de todas ellas.

La documentación de arquitectura de software debe contener las decisiones no triviales y siempre ofrecer al lector el razonamiento detrás de cada elección realizada, observando el contexto que sirvió como catalizador. Además, la documentación debe enfatizar lo esencial, restar énfasis a lo innecesario y describir las limitaciones de una decisión arquitectónica. Es fundamental reconocer que toda decisión importante tiene sus desventajas.

El autor advierte que las decisiones demasiado costosas de revertir más adelante deben tomarse desde el inicio del proyecto, para evitar que el progreso se paralice debido al análisis de cada nuevo elemento introducido. Citando a Martin Fowler, Hohpe aclara que una de las tareas cruciales de los arquitectos de software es eliminar la irreversibilidad del diseño de software mediante abstracciones [2], patrones y paradigmas de desarrollo, con el fin de minimizar las decisiones irreversibles al principio del proceso. Si el nivel de conocimiento de las tecnologías por parte del equipo de ingenieros es insuficiente, es posible adoptar una arquitectura evolutiva, que se desarrolla a medida que crece la comprensión sobre esas herramientas.

La arquitectura de software abarca más que componentes y sus interrelaciones. Es necesario adoptar un enfoque sistémico, enfatizando las relaciones y cómo cada estructura actúa como medio para alcanzar un comportamiento deseado. En este sentido, técnicas como los ciclos de retroalimentación negativa pueden aplicarse actuando como una autorregulación de los sistemas mediante las relaciones entre los componentes diseñados. El foco en el comportamiento también debe reflejarse en la documentación producida, donde debe ser el aspecto más relevante, en lugar de las estructuras estáticas.

Controlar el software heredado también es un desafío en la arquitectura de software, y la clave para evitar la obsolescencia de estos sistemas es mantener su agilidad. Un sistema no es ágil si nadie puede modificarlo. Este temor a los cambios está justificado cuando no existen prácticas y técnicas de operación adecuadas, faltan métricas productivas y las implementaciones son esporádicas. Fowler afirma: "si algo duele, hazlo más seguido" [3]. En este contexto, las tareas problemáticas deben realizarse con frecuencia, de modo que se imponga la automatización.

Para una arquitectura de software en operaciones a gran escala, el autor enfatiza la necesidad de una amplia automatización, desde procesos burocráticos como aprobaciones de solicitudes de infraestructura, hasta pipelines para el despliegue de aplicaciones. Lo que no pueda automatizarse debe convertirse en sistemas de autoservicio, simplificando actividades rutinarias y predecibles. Una estrategia posible para la automatización de este tipo de sistema es la construcción de interfaces con validaciones integradas al ciclo de desarrollo de software, incluyendo el uso de código boilerplate para nuevas aplicaciones y la configuración de servicios de infraestructura. También debe codificarse el conocimiento tácito en scripts y herramientas, evidenciando estos procesos y facilitando la transferencia de conocimiento. Por último, los sistemas automatizados para procesos ampliamente estandarizados y explícitos facilitan la auditoría de cumplimiento.

La arquitectura de software implica tomar decisiones de diseño para evitar que los desarrolladores ejerzan una creatividad innecesaria. Esto significa que ciertos procesos deben establecerse previamente y mantenerse como estándares, con el fin de simplificar la operación del software y liberar a los equipos de ingeniería para aquello que aporta diferenciación de negocio a la empresa. La estandarización de componentes en TI simplifica las operaciones, permite economías de escala y ahorra recursos financieros gracias al aumento del poder de negociación con los proveedores.

Esta estandarización debe considerarse en dos niveles: el nivel inferior, donde debe buscarse el máximo reaprovechamiento, ya que no siempre es el diferencial de la empresa, y el nivel superior, con software desarrollado internamente, que aporta el verdadero valor y la diferenciación competitiva en el mercado. Existe un elemento de conformidad en el que ocurren pocos cambios en los niveles más bajos, lo que facilita la estandarización con un conjunto común de herramientas.

Al elaborar diagramas de arquitectura de software, ya sea utilizando modelos C4 [4] u otras notaciones gráficas, comúnmente se destacan los bloques que representan los componentes. Sin embargo, desde la perspectiva de Hohpe, estos diagramas deben diseñarse enfocándose en las funcionalidades y en las relaciones entre esos componentes, mediante líneas y flechas, para resaltar la comunicación entre los elementos que componen el sistema en diferentes niveles. Este enfoque contribuye a una comprensión más clara y eficiente de la arquitectura del software y de su dinámica.

Finalmente, al adoptar un conjunto de tecnologías de un proveedor, es crucial cuestionar los límites de cada herramienta y cómo se relacionan con el sistema en su conjunto. De esta forma, es posible establecer las fronteras de la solución propuesta y garantizar un enfoque más eficiente para la arquitectura de software.

Consideraciones

La dificultad para definir con precisión la arquitectura de software surge del intento de asociarla directamente con los componentes más fundamentales del software, como los datos y el código. Aunque temas como la arquitectura en capas, los patrones de diseño y el diseño del código fuente están relacionados con la arquitectura de software, esa asociación es solo parcialmente cierta. Como se observó, las estrategias formadas por el contexto en el que está inserto el arquitecto de software son indisociables de los principios que guían el diseño, la implementación y la evolución de esos sistemas.

Es fundamental establecer límites, responsabilidades y relaciones de cada componente seleccionado para conformar el mapa de la arquitectura, teniendo en cuenta todas las restricciones impuestas por el entorno y por el objeto observado, cuya representación sistémica se construirá. De esta forma, la arquitectura de software va más allá de los componentes básicos y abarca aspectos más amplios y complejos, que involucran las decisiones y estrategias específicas para cada contexto y proyecto.

Lista de referencias

Enlaces adicionales

Reseña de la parte I del libro "The Software Architect Elevator"

Wed, 25 Jan 2023 00:00:00 GMT

Contexto

La arquitectura de software ha sido objeto de acaloradas discusiones entre técnicos y gestores de TI durante décadas. Muchas obras de grandes autores, como Mark Richards, Sam Newman, Len Bass, George Fairbanks, Frederick Brooks Jr., entre otros, han contribuido a esclarecer este vasto tema.

En esta reseña se abordará la primera parte del libro "The Software Architect Elevator" [1], titulado en portugués como "El elevador del arquitecto de software", escrito por Gregor Hohpe [2], autor también del aclamado EIP, "Enterprise Integration Patterns" [3], un catálogo de patrones esenciales para integraciones entre sistemas.

Figura 1. Los arquitectos de software necesitan transitar por diferentes niveles organizacionales.

Parte I – Arquitectos

En esta primera parte, el autor enumera las habilidades y características deseables en un arquitecto de software, y qué funciones debería desempeñar dentro de una organización, como: visión estratégica de amplio alcance, liderazgo técnico y buena gestión de personas. El autor afirma que estos profesionales deben lidiar con discusiones que van más allá del ámbito técnico, como el contexto situacional en el que están insertos y ciertas suposiciones tácitas, que a veces ocultan información contextual fundamental, además de establecer comunicación entre diferentes niveles organizacionales.

Encontrar el equilibrio correcto en las decisiones de diseño de acuerdo con los objetivos y principios establecidos es fundamental, conectando los componentes de software para que puedan trabajar en conjunto y alcanzar el resultado esperado, sin dejar de lidiar con la complejidad mediante el uso de técnicas de gobernanza.

En cuanto a la comunicación, el autor utiliza la metáfora de un elevador de un edificio, que conecta los niveles inferiores, donde los ingenieros de sistemas trabajan en la creación y el mantenimiento de los sistemas de software del negocio, con los niveles superiores, donde se encuentran los ejecutivos responsables de la alta abstracción del negocio ofrecido por la organización. Esta conexión se representa mediante la metáfora de un elevador de un edificio. En este contexto, la función del arquitecto es transitar naturalmente por esos niveles, sin perder la esencia del mensaje, es decir, adaptando el lenguaje utilizado según las necesidades específicas.

En situaciones donde hay resistencia a la actuación del arquitecto de software en la comunicación entre diferentes niveles, el autor argumenta que es necesario trabajar para reducir esa resistencia. Una forma de lograrlo es haciendo que los niveles superiores se interesen y estén al tanto de los proyectos realizados por ingeniería. Además, es importante establecer ciclos frecuentes de retroalimentación.

En cuanto a las características técnicas, Hohpe describe que los arquitectos deben garantizar que las soluciones desarrolladas mantengan el equilibrio y la proporción de las ideas iniciales. Esta capacidad también la menciona Frederick Brooks Jr. en su libro "El mítico hombre-mes", donde se la denomina "integridad conceptual". Brooks destaca la importancia de que el arquitecto trabaje para unir las ideas que componen el sistema y mantener la cohesión del conjunto.

La experiencia del arquitecto en proyectos de diferentes tamaños es fundamental, ya que le permite tener la sensibilidad para identificar oportunidades de cambio que van más allá de los requisitos funcionales esperados en un sistema. Estos cambios pueden incluir la necesidad de soportar variaciones en el tráfico de datos procesado, cambios de entorno cuando el sistema se traslada a un nuevo proveedor de computación en la nube, o la necesidad de implementar funcionalidades de internacionalización para hacerlo disponible en varios idiomas.

Otro aspecto técnico importante es promover la construcción de herramientas para la construcción y entrega de software en producción, aumentando la velocidad de entrega de los cambios y reduciendo el riesgo de errores en operaciones manuales realizadas por los equipos de operaciones. El arquitecto de software debe garantizar que su criterio técnico esté libre de sesgos, por lo que debe procurar mantenerse en contacto con otros expertos que le brinden información que le permita ver más allá de las palabras de moda, y discernir si una solución es realmente nueva o simplemente "recalentada de forma inteligente". Esto es importante porque evita que el arquitecto se sienta cómodo siempre con el mismo abanico de soluciones, o que emplee nuevas herramientas de forma irracional, sin buenas razones para aplicarlas.

Según el autor, la arquitectura empresarial es la organización lógica de los procesos de negocio y de la infraestructura de TI que los soporta, uniendo los logros de los arquitectos de negocio y de TI. Existen diversas herramientas de mapeo de procesos empresariales utilizadas por los arquitectos. Según Hohpe, los arquitectos deben actuar con cautela al usar estas herramientas como meros documentadores, ya que pueden entregar un producto final desactualizado apenas se publica. Sin embargo, este enfoque estático plantea un dilema recurrente para los arquitectos, pues puede no reflejar con precisión las interacciones en constante cambio dentro del entorno empresarial.

Existen diferentes niveles de seniority para los arquitectos de software, que según Hohpe pueden identificarse aplicando el trípode de habilidad, impacto y liderazgo, donde la habilidad se refiere a la capacidad de resolver problemas reales con las herramientas adecuadas; el impacto mide cómo las habilidades del arquitecto benefician a la empresa, ayudándola a alcanzar sus objetivos estratégicos y de mercado; y el liderazgo determina la capacidad del arquitecto de promover el estado de sus prácticas, compartiendo conocimiento a través de charlas, blogs, publicaciones y al mentorizar a otros profesionales.

Por último, la habilidad de hacer las preguntas correctas e identificar quién toma las decisiones y cuáles son las motivaciones detrás de ellas es una competencia indispensable para el arquitecto de software.

Consideraciones

Las reflexiones presentadas por Hohpe en esta primera parte son fundamentales para entender la posición que ocupa el arquitecto de software dentro del complejo ecosistema organizacional, que involucra a diversos grupos de interés y va mucho más allá de las decisiones puramente técnicas relacionadas con aspectos de ingeniería u operaciones.

Sin embargo, es importante destacar que la capacidad de comunicación y toma de decisiones es el aspecto más importante para el éxito de una gestión, independientemente del área observada, ya sea para establecer un nuevo hito o para cambiar el rumbo de un proyecto que se ha desviado de lo planeado.

Lista de referencias

Actualizando Sleuth para Spring Boot 3.0

Sun, 08 Jan 2023 00:00:00 GMT

Contexto

Recientemente, mi equipo y yo estábamos trabajando en actualizaciones de bibliotecas de APIs que utilizan Spring Boot. Estas actualizaciones se realizaron en proyectos que usaban el framework en la versión 2.7.X, y quisimos aprovechar la ocasión para subir a la versión 3.0.1, disponible desde Generally Available a finales de noviembre de 2022.

La guía de actualización disponible en el repositorio oficial del framework transcurrió bien, con el build y las pruebas automatizadas ejecutándose sin problemas.

Sin embargo, al ejecutar el proyecto y observar los logs, notamos la ausencia del Trace Id y del Span Id en los registros, los cuales se enriquecen mediante el uso de la biblioteca Spring Cloud Sleuth.

2023-01-06T20:06:46.830-03:00  INFO [my-test-app,<TRACE_ID_HERE_BUT_EMPTY>,<SPAN_ID_HERE_BUT_EMPTY>] 29324 --- [nio-8080-exec-6] c.a.Loren : Loren ipsun

Problema

Una lectura rápida de la documentación de Sleuth nos indica que este proyecto fue absorbido por Micrometer Tracing a partir de la versión 3.0 de Spring Boot, por lo que aparentemente quedó descontinuado a partir de la versión 3.1. Esto también lo confirma el GitHub oficial de Micrometer, donde se presenta una guía de migración.

Sin embargo, la guía de migración no parece estar completa, ya que seguirla no dio como resultado la correcta impresión de los datos de trazabilidad.

Por lo tanto, el objetivo del siguiente paso a paso es ayudarlos con esta migración.

Solución

Verifique que el proyecto esté usando la versión 3.0 de Spring Boot;

plugins {
    id("org.springframework.boot") version "3.0.1"
}

Elimine la dependencia de Sleuth;

implementation("org.springframework.cloud:spring-cloud-starter-sleuth")

Agregue la dependencia de Micrometer Tracing con el bridge para Brave, responsable de la creación de los tracers;

implementation("io.micrometer:micrometer-tracing-bridge-brave")

Si no la tiene, agregue la dependencia de Spring Actuator. Es necesaria para la autoconfiguración de Micrometer;

implementation("org.springframework.boot:spring-boot-starter-actuator")

Finalmente, siguiendo la guía de migración de Micrometer, agregue la propiedad de log pattern en el archivo .properties o .yml para que el Trace Id y el Span Id se impriman correctamente;

logging.pattern.level=%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]

Al ejecutar nuevamente el proyecto, los Ids de Trace y Span volverán a funcionar correctamente.

2023-01-06T20:16:46.830-03:00  INFO [my-test-app,63b8a986c713b025bfcb74bfc7c64a77,bfcb74bfc7c64a77] 29324 --- [nio-8080-exec-6] c.a.Loren : Loren ipsun

Para cualquier duda, estoy disponible a través de mis contactos.

Buen código para todos. 😎