En el día a día laboral, solemos encontrarnos con detalles visuales que parecen inofensivos o simples, pero que acaban consumiendo bastante tiempo y energía. Recientemente, mientras revisaba algunas secciones de mi portafolio directamente desde mi teléfono, noté que los textos grandes tenían "bordes raros" o parecían sobreponerse.

Lo más curioso de la situación no era el fallo en sí, sino cuándo ocurría: durante la animación inicial del elemento (usando la librería Framer Motion), la fuente se veía increíble, limpia y sin bordes. Pero una vez que la animación terminaba y el texto llegaba a su posición final estática, los bordes dentados y "sucios" volvían a aparecer.

El origen del problema

La mayoría de estos fallos no surgen porque el lenguaje ni el framework estén mal, sino porque a veces olvidamos cómo la combinación de reglas CSS puede chocar bajo la lupa de motores de renderizado en diferentes dispositivos.

El verdadero culpable de que mis fuentes se vieran así eran estas dos líneas escondidas en mi <body /> global:

-webkit-text-stroke: 0.3px var(--text-stroke);
text-shadow: 0px 0px 1px var(--text-stroke);

En navegadores de escritorio, esta combinación ayuda a darle una presencia definida a la tipografía. Sin embargo, en las pantallas de alta densidad de píxeles de los teléfonos móviles (High-DPI / Retina), las cosas cambian. Si a esto le sumas una variante pesada en la fuente (font-weight: 800), un tamaño de texto bastante grande (clamp(3rem, 8vw, 5rem)) y un letter-spacing negativo, le estás poniendo una prueba dificilísima al motor de renderizado de Safari o Chrome.

El subpixel rendering colapsa por la falta de espacio, provocando problemas de anti-aliasing. Básicamente, el navegador intenta procesar sub-píxeles sobre un trazo muy delgado produciendo el indeseable efecto de doble borde o solapamiento rasgado.

¿Y por qué con Framer Motion nunca sucedía esto durante las transiciones? La explicación es puramente técnica: al mover, escalar o cambiar opacidades durante una animaciós, el navegador toma el texto y lo mueve temporalmente a una "capa de composición asistida por la GPU" (Hardware Acceleration). En ese momento, en lugar de calcular vectores complejos y trazos continuos, procesa todo el elemento como si fuera una simple imagen plana 2D. Una vez que la animación concluía y la capa especial desaparecía, el DOM retomaba el renderizado estándar y el problema salía a la luz.

La solución

Mi primer instinto fue poner un "parche" directamente en la sección en donde lo encontré, modificando solamente el Título que estaba generando el error. Sin embargo, el objetivo como desarrolladores debe ser siempre mirar más allá: resolver el problema de raíz para que no vuelva a suceder nunca en ninguna otra página de la plataforma, no solamente parchar el presente.

La solución más sana e idónea fue regresar a las bases: anular estos estilos conflictivos para dispositivos móviles de manera global para dejar que el texto respirara por su cuenta.

Añadí esto directamente en la hoja o archivo global de estilos (GlobalStyles.ts):

@media (max-width: 768px) {
  body {
    -webkit-text-stroke: 0;
    text-shadow: none;
  }
}

Así de simple. Por la propia naturaleza de cascada que tiene CSS, todo el texto (títulos, subtítulos, tarjetas de proyectos y barras de navegación) dentro del body en celulares perderá la regla de -webkit-text-stroke, evitando el problema para siempre de forma unificada.

El engaño de las DevTools y la verdadera prueba

Algo que hizo que este bug fuera aún más escurridizo fue que, al intentar replicarlo en mi computadora utilizando las herramientas de desarrollador (DevTools) y simulando la pantalla de un celular, el texto se veía perfectamente bien. No había rastro de bordes superpuestos ni fallos de ningún tipo.

Esto es un engaño visual muy común del que rara vez se habla. El simulador de dispositivos móviles integrado en los navegadores de escritorio es una herramienta excelente para reajustar el tamaño de pantalla (el viewport), simular cambios en el User-Agent o emular respuestas táctiles. Sin embargo, no emula ni el hardware físico, ni la densidad real de píxeles, ni el motor interno de renderizado de un teléfono. Mi computadora continuaba dibujando la fuente con su propio y potente procesador gráfico y su método de alisado (anti-aliasing), ocultando el problema real que sufrían las pantallas de menor tamaño y mayor densidad en celulares.

Esta aventura reafirma una de las reglas de oro del desarrollo Frontend: hay que probar el software en su entorno real de uso.

No importa cuán fiable parezca ser el emulador en tu monitor; la única forma de garantizar que tu tipografía, tus interacciones y la estética del sitio sean verdaderamente impecables en todos lados es abriendo tu sitio web en un dispositivo físico real. Prestar atención a estos pequeños detalles técnicos y darse el tiempo de confirmar tu trabajo y salir del ecosistema perfectamente simulado de tu escritorio, es exactamente lo que separa a una interfaz de ser promedio a ser verdaderamente profesional.

Aun así, muchos desarrolladores comienzan un proyecto decidiendo el stack tecnológico: React, Node, PostgreSQL…

Y casi nadie define algo más importante: el stack de documentación.

¿Qué es el stack de documentación?

El stack de documentación es el conjunto de artefactos que utilizamos para responder tres preguntas críticas:

1. ¿Qué problema estamos resolviendo?

2. ¿Qué debe hacer el sistema?

3. ¿Cómo debe comportarse?

Ejemplos concretos de este stack:

• Visión de producto

• Catálogo de eventos

• Diagramas de estado

• Contratos de API

Esto abre preguntas inevitables:

• ¿Qué opciones existen para documentar?

• ¿Existen niveles?

• ¿Es necesario documentar todo?

Niveles de documentación

Documentación de negocio

Define el por qué y el qué del sistema. Su objetivo es entender el contexto del negocio, su alcance y sus límites.

Elementos clave:

• Visión del producto

• Objetivos

• Stakeholders

• Problema a resolver

Ingeniería de requisitos

Aquí se profundiza en lo que el sistema debe hacer. Existen múltiples formas de modelarlo:

No todos son igual de útiles: la elección depende del tipo de sistema y su complejidad.

Modelado del sistema

Es el puente entre los requisitos y el diseño técnico. Aquí se representan comportamientos y estructuras mediante herramientas como UML.

Artefactos comunes:

• Diagramas de secuencia

• Diagramas de estado

• Diagramas de actividad

• Diagramas de clases

Diseño técnico

Define cómo se construirá el sistema.

Incluye decisiones como:

• Arquitectura (MVC, microservicios, serverless, etc.)

• Decisiones técnicas clave

• Diseño de APIs

• Modelo de datos

Documentación operativa

Describe cómo el sistema se despliega, monitorea y utiliza en la práctica.

Ejemplos:

• Deploy

• Monitoreo

• Manuales de uso

No todos los artefactos son igual de útiles

Uno de los errores más comunes es asumir que todos los enfoques de documentación funcionan igual.

Por ejemplo: los casos de uso funcionan bien en sistemas simples pero escalan mal en sistemas con estados complejos

En estos casos, un catálogo de eventos es más cercano a la realidad del negocio, ya que modela lo que realmente ocurre: eventos, transiciones y respuestas del sistema.

¿Qué debería usar realmente?

No necesitas todo.

Una combinación práctica para la mayoría de sistemas de negocio:

• Catálogo de eventos → comportamiento del dominio

• Diagramas de estado → lógica compleja

• Diagramas de secuencia → flujos críticos

• Modelo de datos → persistencia

Guía rápida:

• Si tu sistema es CRUD simple:
  → Casos de uso + modelo de datos

• Si tu sistema tiene estados, pagos o procesos:
  Catálogo de eventos

La documentación como herramienta de pensamiento

El objetivo de la documentación no es generar artefactos, sino reducir ambigüedad.

Un sistema mal documentado no falla por código incorrecto, sino por interpretaciones incorrectas.

La documentación no es un entregable, es una herramienta para pensar mejor.

Elegir mal el stack tecnológico te cuesta tiempo.
Elegir mal el stack de documentación te cuesta entender el problema.

Y si no entiendes el problema, da igual qué tan bueno sea tu código.

En mi experiencia personal, desarrollé dos proyectos en mi tiempo extra-laboral que me ayudaron a optimizar mi flujo de trabajo y a entregar resultados más rápido y con mayor calidad.

📝 DocuTalk

Docutalk es una aplicación de escritorio multiplataforma hecha con Python. Su propósito es transformar un audio en documentación organizada. Para esto utiliza el modelo de AI Whisper, encargado de convertir el audio en texto, y luego emplea Gemini para generar la documentación final.

El proceso se muestra gráficamente y, antes de guardar, es posible editar el documento a conveniencia. El archivo resultante se almacena en una carpeta definida dentro de la configuración. Esta herramienta me ha ahorrado horas de transcripción y organización de notas.

⚙️repositorio github de DocuTalk

🎧 evidence_processor

Otro reto que enfrentaba era la calidad del audio en mis evidencias de trabajo, ya que mi micrófono no es el mejor. Para solucionarlo creé evidence-processor, un script en Linux que automatiza el tratamiento de un video: separa el audio y permite limpiarlo de manera automática o manual.

En mi caso, combino este proceso con Adobe Podcast, lo que me permite entregar audios más claros y profesionales como evidencia. Gracias a esto, ahora ofrezco un servicio más sólido y ahorro tiempo en tareas manuales.

⚙️repositorio github de evidence_processor

🔑 Conclusión

Automatizar no es solo una habilidad técnica, sino también una forma de pensar. La pregunta clave es: ¿qué tareas me estan quitando tiempo que podría invertir en actividades de mayor impacto o creatividad?

Cada automatización, por pequeña que sea, se convierte en un aliado silencioso que trabaja en segundo plano. Aunque al principio pueda requerir un esfuerzo extra, los beneficios se multiplican con el tiempo.

Al comienzo reboté entre diferentes ideas, ya que algunas me parecían muy quemadas, poco originales o poco definidas, pero sirviendo como borradores para llegar a un proyecto final. Los proyectos fueron:

PMS

Sistema PMS orientado a SCRUM con el diferenciador de que los clientes pueden tener un rol y ver en todo momento quién está haciendo qué y cómo va el avance del proyecto, con una serie de artefactos como las evidencias de cada tarea y diferentes gráficos.
Desechado por: Sentir que es un Trello con pasos extra, muy cerrado y sin gran diferenciación de otros PMS tipo Kanban.

Machina

Sistema de automatización de procesos en bases de datos con una interfaz de bloques, tipo Scratch, donde se pueden acumular pasos básicos y generar simulaciones de procesos reales de un sistema con el propósito de ser utilizado para hacer y automatizar pruebas. Esto facilitaría la realización de tareas al omitir pasos extra (simulados por el script) y permitiría que el desarrollador se enfocara en resolver el problema o agregar el incremento deseado.
Desechado por: No estar tan orientado a Programación Web II, además de tener muchos huecos y vacíos en el cómo implementarlo. Necesito sacar los requisitos funcionales y la implementación rápido.

Oratio

Sistema de apoyo al aprendizaje de inglés con dos módulos principales: una IA para traducir y conversar en el idioma, recibiendo retroalimentación y correcciones instantáneamente; y un módulo de aprendizaje con repetición espaciada mediante mazos de tarjetas, similar a Anki, con la facilidad de agregar tarjetas directamente desde las conversaciones con la IA. De esta manera se facilita tanto la práctica como la memorización del idioma.
Desechado por: Este proyecto no fue exactamente desechado, sino que, platicándolo y buscando retroalimentación con compañeros y profesores, decidimos darle otra orientación para que naciera Leairn.

Leairn

Última y definitiva idea de proyecto, orientada a un SaaS. Es un sistema de apoyo para el aprendizaje general de cualquier tema. Consta de tres módulos principales:

1. Inteligencia artificial: una IA con la que puedes conversar y resolver dudas sobre el o los temas de interés.

2. Aprendizaje: aprendizaje con repetición espaciada utilizando mazos de tarjetas, como Anki.

3. Mercado: un espacio donde algunas personas (autores) pueden publicar sus productos, los cuales constan de una configuración para la IA y un mazo. De esta manera, se pueden crear productos por temas de aprendizaje. Por ejemplo, si ya tengo una configuración para aprender sobre biología marina, puedo publicarlo y ponerle un precio (que puede ser gratuito) para que alguien más pueda adquirirlo desde el mercado.

Conclusión

La idea de ir definiendo proyectos hasta llegar a uno que realmente me apasione me parece increíble, porque cada uno sirve de borrador para otro, ayudando a definir mejor la diferenciación e impacto que se quiere lograr. Por ello, al final fue mejor crear Leairn, ya que representa a Oratio de una manera más abierta, no solo apegada al inglés, sino como una posible configuración. Así, Leairn se convierte en una herramienta usable tanto para personas autodidactas, personas que buscan apoyo en temas específicos, o directamente como una herramienta para instituciones como la SEP y otras instituciones académicas.