10 preguntas que deberías hacerte antes de escribir una sola línea de código

El buen código no empieza en el teclado. Empieza en la cabeza.

Introducción: piensa antes de escribir

En programación, escribir código es solo la parte visible del iceberg. El trabajo real —el que separa a un desarrollador competente de alguien que sobrevive copiando soluciones sueltas— ocurre antes de escribir el primer import, la primera function o el primer console.log.

Demasiadas veces programamos en piloto automático. Entendemos a medias lo que se necesita, imaginamos una estructura vaga y empezamos a escribir como si fuéramos arquitectos colocando ladrillos sin plano. Luego llegan los bugs, los parches, el código ilegible y la frustración.

La causa casi nunca es puramente técnica. Suele ser esta: nadie se detuvo a hacer las preguntas correctas antes.

Las 10 preguntas críticas antes de escribir código

1. ¿Cuál es el problema real que estoy resolviendo?

No confundas síntoma con causa. Muchas peticiones llegan formuladas como solución: “hazme un dashboard”, “automatiza esto”, “crea una app”. Tu trabajo es descubrir qué necesidad hay debajo.

2. ¿Ya existe una solución parcial o completa?

Antes de construir, busca. Puede haber una librería, una API, una herramienta interna, una consulta existente o un proceso que ya resuelve parte del problema. No seas el héroe que levanta una catedral cuando bastaba una estructura prefabricada.

3. ¿Cómo encaja esto dentro del sistema mayor?

Ningún código vive aislado. Piensa en dependencias, integraciones, mantenimiento, permisos, datos, usuarios y efectos secundarios. Una solución local puede crear un problema global.

4. ¿Qué datos entran, qué datos salen y qué pasa entre medias?

Si no puedes describir entradas, transformaciones y salidas, todavía no tienes una solución. Tienes una intuición. Y las intuiciones, en producción, suelen convertirse en incidencias.

5. ¿Qué errores pueden ocurrir?

Piensa en datos vacíos, formatos incorrectos, permisos insuficientes, timeouts, duplicados, estados inconsistentes y usuarios haciendo cosas que “nadie haría”. Si puede pasar, tarde o temprano pasará.

6. ¿Cuál es la versión mínima útil?

Mínimo no significa pobre. Significa suficiente para validar valor sin cargar el sistema de complejidad prematura. Una primera versión buena resuelve lo esencial y deja margen para evolucionar.

7. ¿Cómo sabré que funciona?

Define criterios de aceptación antes de implementar. Qué debe ocurrir, qué no debe ocurrir, cómo se valida y quién confirma que el resultado es correcto.

8. ¿Quién tendrá que mantener esto?

Puede que seas tú dentro de seis meses. O alguien que no estuvo en la reunión. Escribe pensando en quien tendrá que entender la solución sin tener tu contexto mental.

9. ¿Estoy añadiendo complejidad por necesidad o por ego técnico?

No todo necesita arquitectura avanzada. No todo necesita patrones sofisticados. La mejor solución suele ser la más simple que cumple el objetivo sin comprometer el futuro.

10. ¿Puedo explicar la solución en lenguaje claro?

Si no puedes explicarla de forma sencilla, probablemente no la entiendes lo suficiente. La claridad verbal suele preceder a la claridad técnica.

Conclusión

Programar bien no consiste en escribir muchas líneas. Consiste en tomar buenas decisiones antes de escribirlas. Las preguntas correctas reducen deuda técnica, evitan trabajo inútil y convierten el código en una consecuencia de un razonamiento sólido.