Uncategorized

Una decisión de 10 minutos que casi cuesta un proyecto

Hace tiempo, un cliente me pidió ayuda para desbloquear el desarrollo de una aplicación móvil. El problema radicaba en la persistencia de datos: la app debía permitir recopilar inspecciones en zonas sin cobertura, lo que obligaba a almacenarlas temporalmente en el dispositivo. Inicialmente, se optó por una base de datos relacional, una decisión que técnicamente parecía acertada.

El problema: Los datos eran estructuralmente más parecidos a documentos que a tablas rígidas. Esto, sumado a los constantes cambios en los requerimientos, convirtió la arquitectura en una pesadilla. Cada vez que se añadía un campo o se modificaba un formulario, el equipo debía realizar migraciones de base de datos complejas y transformaciones manuales que consumían mucho tiempo y generaban errores constantes.

La solución que propuse: almacenar los datos en ficheros JSON, más que suficiente para almacenar la información temporalmente hasta el momento de transmitirla.

El código es un pasivo, el producto es el activo

Un desarrollador móvil con mentalidad de CTO no solo escribe código que funciona; escribe código que construye una empresa. La diferencia radica en pasar del «¿cómo lo implemento?» al «¿por qué lo hacemos y a qué coste?«.

Así es como piensa un perfil estratégico:

• El código como deuda: Entiende que cada línea de código escrita es algo que habrá que mantener y pagar en el futuro. Quien sabe cuándo no programar es tan valioso como quien sabe hacerlo.
• Tecnología «aburrida» pero sólida: Aunque le apasione la innovación, prefiere tecnologías maduras. ¿Por qué? Porque es más fácil encontrar talento, tienen menos errores inesperados y garantizan que la app siga viva en dos años.
• Visión de «App Store»: A diferencia de una web, una app móvil no se actualiza instantáneamente. Un error en producción puede tardar días en corregirse por los tiempos de revisión de Apple o Google y las actualizaciones en los dispositivos de los usuarios. El pensamiento de CTO implica una gestión de riesgos mucho más rigurosa antes de cada lanzamiento y valorar el uso de técnicas (p. ej. feature flags) que permitan modificar el comportamiento de la app sin tener que publicar una nueva versión.
• Equilibrio entre velocidad y deuda: Sabe que en un MVP (Producto Mínimo Viable) se pueden tomar atajos para validar el mercado, pero identifica exactamente cuándo hay que «limpiar la casa» para que la app no se derrumbe bajo su propio peso meses después.

Errores comunes que matan startups y PYMES

• Ignorar la incertidumbre técnica crítica: Si el valor depende de una innovación técnica o de unas prestaciones exigentes, no construyas toda la app de golpe. Haz una prueba de concepto de tres días. Si la tecnología no responde, no habrás perdido tres meses.
• Esperar demasiado para validar el modelo de negocio: Especialmente critico si nuestra app propone una funcionalidad muy innovadora que quizás el mercado no acabe valorando nunca.
• Sobre-ingeniería: Las arquitecturas de software y los patrones de diseño son herramientas poderosas que conviene usar juiciosamente. Tan pernicioso es ignorarlas como aplicarlas ciegamente.

Cómo detectar (o entrenar) esta mentalidad

Desarrollar esta visión no sucede de la noche a la mañana; es una transición de enfoque. Si quieres saber si tu equipo tiene este «chip» o quieres ayudarles a desarrollarlo, busca estas señales:

Enfoque tradicional	Enfoque «thinking like a CTO»
«Necesitamos refactorizar este módulo.»	«Si invertimos 2 días en limpiar este módulo, las próximas funciones saldrán un 30% más rápido.»
«Usemos la última librería que salió ayer.»	«¿Esta librería tiene comunidad? ¿Habrá soporte en 2 años? ¿Es segura?»
«He terminado la tarea según el ticket.»	«He visto que esta función no ayuda al objetivo de retención de usuarios de este mes, ¿seguro que la queremos así?»

Enamorarse del problema, no de la solución. Si el problema de un usuario se resuelve con una pantalla sencilla en lugar de una animación 3D compleja, y eso ahorra 40 horas de presupuesto, el «Developer-CTO» siempre elegirá el ahorro para reinvertirlo en lo que realmente genera ingresos.

---

¿Sientes que tu equipo técnico y tus objetivos de negocio hablan idiomas distintos?

En un proyecto reciente para una startup en etapa temprana, me tocó ir más allá del desarrollo móvil y asumir el desarrollo backend con Firebase.

Stack actual:

• Firestore como base de datos
• Firebase Functions para lógica backend
• Migración de un código base en JavaScript hacia TypeScript

Lo interesante del proceso:
Venir del mundo frontend me dio herramientas que pude aplicar directamente:

• Mantener buenas prácticas con TDD y arquitectura limpia
• Reutilizar patrones async que ya conocía bien
• Pensar en la experiencia de desarrollo de forma integral, no dividida en “front” y “back”

Además, la IA fue un gran copiloto:

• Me ayudó a cerrar gaps con nuevas librerías
• A plasmar ideas en TypeScript más rápido
• Y a reducir el tiempo en tareas repetitivas

Este proyecto fue un recordatorio de que salir del rol habitual puede abrir muchas puertas, sobre todo cuando te apoyas en principios sólidos.

La deuda técnica es peor que la financiera (y más fácil de adquirir)

Si pides dinero al banco o usas tu tarjeta de crédito, sabes (deberías) cuándo tendrás que devolverlo.

Pero con la deuda técnica, no.

No sabes cuándo vas a tener que pagarla. A veces es mañana. A veces dentro de años.
Y eso la hace más peligrosa.

Lo peor es que muchas veces no somos conscientes de que la estamos introduciendo.
Arrancas un proyecto sin definir principios, valores, metodologías, buenas prácticas…
Y sin darte cuenta, la deuda técnica empieza a colarse.
Silenciosa. Persistente. Acumulativa.

Además, no toda deuda técnica es igual.
Depende de dónde la introduces.

No es lo mismo hacer “trampas” en una zona periférica del sistema, que en el núcleo, en la capa de dominio.
Cuando la deuda está en el core, es mucho más costosa de pagar.

¿Mi postura? Haz siempre las cosas bien.
No sabes cuándo vas a tener que volver a ese código.
Y si vas a tener que devolver esa deuda…
Mejor que sea poca.

Si en tu empresa la deuda técnica empieza a doler, hablamos.

Trabajar como ingeniero de software freelance implica mucho más que programar: Propuestas, reuniones, tareas administrativas, marketing, creación de contenido… y todo lo que se te ocurra.

Aunque uso intensivamente la IA para programar, también me apoyo en otras herramientas para esas tareas más periféricas, pero igual de importantes. Aquí van las que más utilizo hoy por hoy:

🤖 LLMs (Modelos de lenguaje)

• ChatGPT. Mi primera opción para redactar contenidos, pulir copies o generar imágenes. Versátil y rápido.
• Gemini. Muy útil para búsquedas generales. Su función Deep Research es una joya: ideal para recopilar información actualizada desde internet. Es mi recurso estrella cuando quiero profundizar en un tema sin perderme en mil pestañas.
• DeepSeek (R1). Perfecto para tareas complejas. Me encanta cómo desglosa el razonamiento paso a paso. Últimamente lo uso menos, porque modelos como GPT-4 o Gemini también están mejorando en este sentido, pero sigue siendo una gran alternativa.
• Claude. Lo uso cuando quiero aplicar un estilo concreto al escribir. Tiene una función interesante: puedes pedirle que copie el estilo de un texto dado. Aunque suelo preferir mantener mi propio tono, es útil para casos específicos.

🧠 NotebookLM

Una herramienta que sorprende. Puedes subir textos, PDFs, documentos de Google Drive, incluso vídeos de YouTube. Te permite:
• Resumir contenido
• Hacer preguntas sobre éste
• Crear informes, esquemas mentales… ¡hasta podcasts!

Lo uso para:

• Saber de qué va un vídeo largo sin verlo entero
• Analizar documentos complejos
• Consolidar conocimiento de un proyecto

Y sí, es gratuita. Por ahora. Aprovechala.

📝 Transcripción de reuniones

En reuniones estructuradas, tomo notas. Pero en una reunión exploratoria reciente con un potencial cliente, quería estar 100% presente. Pedí permiso para grabarla en audio.

Estuve probando herramientas para transcribirla y me quedo con Taqtiq:

• Extensión de navegador
• 10 reuniones al mes en su plan gratuito
• Tambien transcribe audios grabados

¿Lo mejor? Transcripción lista y cargada en NotebookLM para sacarle todo el jugo.

Hoy quiero compartir una técnica que me ha ayudado a mantener constancia y calidad al escribir posts.

1️⃣ Empiezo por la idea

Cuando quiero escribir un post, lo primero que hago es definir el tema. A veces le pongo un título provisional solo para orientarme.

Enseguida me vienen ideas sueltas… y las anoto tal cual. No me preocupo por la forma, solo por capturar lo esencial. En esta etapa, lo importante es la calidad de las ideas, no cómo están escritas.

2️⃣ Le pido ayuda a la IA

Con esa lluvia de ideas, lanzo un prompt muy sencillo a mi LLM favorito: «Crea una publicación con las siguientes ideas. Sugiere cinco versiones diferentes.»

El objetivo no es que la IA escriba por mí, sino que me ayude a estructurar mejor el mensaje y hacerlo más claro.

3️⃣ Selecciono, mezclo y afino

Leo las 5 versiones que me devuelve y elijo la que mejor refleja lo que quiero transmitir. A veces mezclo partes de otras versiones. Le doy mi toque final, y voilà.

También le pido a la IA ideas para títulos y llamadas a la acción. Elijo las que más encajan y ¡post listo para publicar!

Confesión: Cuando empecé a publicar con regularidad, probé a delegar todo el post en la IA. ¿El resultado? Correcto, sí… pero sin alma. No transmitía mi forma de pensar ni mi estilo. Era impersonal.

En cambio, cuando las ideas son mías y la IA solo me ayuda a contarlas mejor, el resultado es radicalmente distinto: más auténtico, más potente, más yo.

En resumen: No se trata de si usamos IA o no. Se trata de cómo la usamos para potenciar lo que solo nosotros podemos aportar: nuestras ideas, experiencias y visión.

A veces me cuesta recordar cómo se declara un cliente Retrofit o cómo se define una base de datos con Room en Android. Y no me preocupa demasiado.

Después de más de 20 años trabajando con C++, MFC, POSIX, Java, Kotlin, PHP, C#, wxWidgets, Android, Flutter y más, he aprendido algo: los detalles concretos cambian, los fundamentos perduran.

Los paradigmas, las estructuras de datos, la orientación a objetos, la arquitectura de software, el pensamiento crítico… eso es lo que realmente da solidez profesional. Lo demás lo buscas en Google o lo preguntas a GPT.

Con la irrupción de la IA, el rol del ingeniero de software tiene que estar más arriba: tomar decisiones, entender el contexto, razonar, abstraer. Lo duradero se vuelve diferencial.

No estoy diciendo que no haya que conocer los detalles de cómo funciona una tecnología concreta. Al fin y al cabo, el software se ejecuta sobre ordenadores y esos detalles importan. Pero no confundamos los medios con los fines. Los fundamentos no caducan.

Si estás formando un equipo sólido que necesite pensamiento crítico y fundamentos sólidos, estoy interesado en colaborar. Escríbeme.

Es una cuestión a la que sigo dándole vueltas.

Por un lado, la teoría del Test Driven Development (TDD) sigue siendo sólida: primero los tests, luego el código y después refactorizar.

Sus beneficios son innegables:

• Código más modular y desacoplado
• Documentación viva a través de tests
• Regresiones detectadas al instante
• Refactorización más segura

Por otro lado, llega la IA como ese nuevo compañero que parece hacer la vida más fácil: «Déjame generar todo ese código aburrido», «Aquí tienes tanto la implementación como los tests», «¿Para qué pensar tanto si puedo hacerlo por ti?». Luego solo revisas y ajustas.

Es tentador, terriblemente tentador.

A simple vista, el camino 2 parecería el más óptimo: más rápido, más eficiente. Pero ¿realmente lo es?

Aquí está el meollo del asunto: cuando pides a una IA que genere código y tests en un solo paso, estás saltándote la fase más valiosa del TDD: el proceso de pensamiento.