Escrito por Rodrigo de Miguel
Aprende a tomar decisiones y vivir con ello
(pero recuerda… en software nada está escrito en piedra)
Decidir sin certezas es parte del trabajo en software: compromete, tiene consecuencias y toca asumirlas. La clave es hacerlo con pragmatismo y revisar el rumbo cuando el contexto cambia, porque casi nada está escrito en piedra.
Decidir cuando no hay certezas
Si algo marca el trabajo en software —sobre todo cuando construyes producto propio, tiras de bootstrapping o vas justo de recursos— es esto: tienes que decidir sin tener toda la foto completa.
No decidir no es una opción.
Esperar a que todo esté cristalino, tampoco.
Y aun así, cada decisión trae su mochila:
- más o menos tiempo de desarrollo
- más o menos coste
- más o menos deuda técnica
- más o menos margen para maniobrar mañana
Aprender a decidir y convivir con lo decidido es una de esas cosas que separa bastante rápido a un perfil junior de uno senior.
Una frase que se te queda grabada (y por qué importa)
Recuerdo muy bien mi primer proyecto profesional.
Recién salido de la universidad, cargado de teoría, con ganas a raudales y experiencia real… la justa.
Un equipo de dos, íbamos a productizar una POC de ingesta de datos en tiempo real con Apache Flink y Kafka. Yo estaba deseando ponerme a picar código cuanto antes.
Oscar, mi primer senior y mentor, me soltó el primer día, casi sin contexto, sentados en la oficina de Indizen:
Es importante que entiendas que vamos a tener que tomar decisiones, y esas decisiones tendrán consecuencias, y tendremos que aceptarlas.
En ese momento me sonó dramático.
Con los años entendí que no era exagerado, era una lección clave.
No hablaba solo de código.
Hablaba de hacerse cargo de lo que eliges. De acerse adulto.
Decidir duele porque compromete
Tomar una decisión implica:
- cerrar puertas
- asumir un coste
- apostar por un camino concreto
Y eso aprieta, sobre todo al principio.
Muchos problemas en proyectos de software no vienen de malas decisiones, sino de decisiones que nadie se atreve a tomar:
- arquitecturas en tierra de nadie
- responsabilidades poco claras
- el clásico “ya lo veremos”
Ese “luego lo vemos” suele acabar en:
- más complejidad
- más fricción
- más desgaste mental
Al final, no decidir también es decidir.
Aunque, como casi todo en esta vida, depende: a veces lo más sensato es no decidir todavía y dejar que el contexto, el producto o el mercado maduren un poco antes de mojarse.
Cuando emprendes, las consecuencias pesan más
Esta idea se vuelve crítica cuando:
- sacas adelante un producto propio
- haces bootstrapping
- no hay presupuesto infinito
- no tienes un equipo enorme detrás
En ese escenario:
- cada semana cuenta
- cada decisión técnica se nota en tu energía
- cada error se paga con horas personales
Aquí no hay red.
No te puedes permitir decisiones muy finas en teoría pero inútiles en la práctica.
Tampoco quedarte bloqueado por miedo a fallar.
Pensar antes de actuar (porque todo tiene consecuencias)
Antes de tomar una decisión técnica conviene hacerse preguntas incómodas:
- ¿Qué problema real estoy atacando?
- ¿Qué pasa si me equivoco?
- ¿Cuánto me va a costar mantener esto dentro de 6 meses?
- ¿Quién va a cargar con esta decisión? ¿yo mismo?
No es papeleo.
Es instinto de supervivencia.
Ejemplos de consecuencias reales
| Decisión | Consecuencia posible |
|---|---|
| Elegir una tecnología “de moda” | Complicaciones para mantenerla |
| Sobre-arquitectar | Más tiempo, menos producto |
| Infra compleja | Coste y desgaste mental |
| Mala separación de responsabilidades | Refactors caros |
Nada de esto es teoría.
Todo se paga aprende con el tiempo.
Pero aquí viene la otra mitad de la verdad
Y esta es la parte que muchos pasan por alto —o prefieren no decir en voz alta—:
Estamos en software. No construimos puentes ni rascacielos.
Eso cambia bastante las reglas.
En software:
- se puede refactorizar
- se puede cambiar de rumbo
- se pueden deshacer decisiones
Con coste, claro.
Pero se puede.
No es una excusa para decidir mal.
Es un recordatorio de que las decisiones no son eternas.
El equilibrio del compromiso sin dogmatismo
Aquí está el matiz importante, y donde aparece la experiencia de verdad.
Un perfil junior suele caer en uno de estos extremos:
- miedo a decidir
- rigidez total (“esto es así y punto, lo dice el manual”)
Un perfil senior entiende que:
- hay que decidir
- hay que asumir consecuencias
- y hay que revisar decisiones cuando el contexto cambia
El contexto siempre cambia:
- requisitos nuevos
- más usuarios (o menos)
- menos recursos
- más complejidad de la prevista
No revisar decisiones puede ser tan peligroso como no tomarlas.
Decisiones técnicas ≠ decisiones morales
Un error muy común es apegarse emocionalmente a decisiones técnicas
…y a productos también (me ha pasado más de una vez)
“He elegido esto, así que lo defiendo pase lo que pase”.
Eso no es profesionalidad.
Eso es ego.
Una decisión técnica no define quién eres.
Define una hipótesis en un momento concreto.
Y como me decía el bueno de Oscar:
Tomaste las decisiones que pudiste con los datos que tenías entonces. Acéptalo.
Las hipótesis se validan… o se descartan.
Cuándo revisar una decisión
Revisar no es rehacer todo desde cero.
Es volver a evaluar con datos.
Revisa una decisión si:
- Los requisitos han cambiado de forma clara
- El coste de mantenerla crece más rápido de lo previsto
- Genera fricción constante en el equipo (o en ti)
- Ya no cumple el objetivo original
- Hoy existe una alternativa claramente mejor
Si se cumplen varias, no es traicionar el diseño inicial.
Es madurez técnica.
Cómo cambiar de dirección sin romperlo todo
Cambiar una decisión no es darle a un botón.
Pero se puede hacer con cabeza.
Pasos prácticos (cuando toca)
- Identifica qué decisión concreta quieres revertir
- Entiende por qué se tomó en su día
- Evalúa el coste real de cambiarla ahora
- Define un plan incremental
- Aprende del proceso, no solo del resultado
No todo se puede deshacer.
Pero casi todo se puede mejorar.
Un ejemplo real en ADOPTA: decidir, fallar y corregir sin drama
Voy a contar un caso concreto de ADOPTA.
Es simple, incluso algo ingenuo visto con perspectiva, y justo por eso resulta útil.
(Esto le pasa tanto a juniors como cuando pruebas librerías nuevas o poco conocidas.)
La decisión inicial (rápida y lógica)
En el registro de un animal necesitaba:
- datos básicos
- varias fotos (5 o 6, por ejemplo)
La solución inicial fue directa:
- un endpoint
- un POST “grande”
- datos e imágenes en una sola llamada
Probé desde el navegador.
Funcionaba.
Se despliega, se valida y a otra cosa.
Decisión tomada.
La realidad aparece (y rompe tu hipótesis)
Cuando probé el flujo desde móvil, todo empezó a torcerse.
No era un bug raro.
No era un caso rebuscado.
Era algo mucho más mundano:
- el móvil enviaba fotos grandes
- varias imágenes juntas superaban el límite del body parser de Express
Resultado:
el endpoint fallaba siempre.
La decisión inicial tenía consecuencias.
Y tocaba asumirlas… o cambiarlas.
Cambiar la decisión (sin reescribir medio sistema)
La solución fue práctica:
- separar responsabilidades
- un endpoint para crear el animal
- otro para añadir imágenes, una a una, a la galería
Menos bonita sobre el papel.
Mucho más sólida en el día a día.
Problema resuelto.
Seguimos.
El segundo golpe (producción siempre enseña)
Tiempo después apareció otro problema, más serio esta vez.
La librería de procesado de imágenes (sharp) tenía una fuga de memoria en ciertos entornos.
En producción el rendimiento caía.
Había varias opciones:
- mirar a otro lado
- parchear
- escalar servidores
- cambiar el enfoque
Opté por cambiar el enfoque.
La corrección madura: tocar solo donde duele
En lugar de rehacer todo:
- llevé el procesado de imágenes a AWS Lambda
- dejé el resto del backend tal cual
El efecto fue inmediato:
- adiós a la fuga de memoria
- mejor rendimiento
- sistema más estable
Desde entonces, ese flujo no ha vuelto a dar guerra.
La lección real
La primera decisión no fue “incorrecta”.
Fue una hipótesis razonable con la información disponible.
Cuando dejó de tener sentido:
- se cambió
- se aprendió
- se mejoró el sistema
Eso es justo a lo que me refiero cuando digo que en software:
las decisiones tienen consecuencias, pero no son sentencias perpetuas.
La diferencia entre software y hormigón
Un puente mal diseñado puede matar gente.
Un sistema de software mal diseñado:
- se refactoriza
- se migra
- se reescribe
(si haces software para aviones, piénsatelo todo dos veces, por favor)
Esto no quita responsabilidad.
Quita bloqueo.
Tener miedo a fallar es normal.
Tener miedo a decidir puede matar un proyecto.
Lo que realmente enseña la experiencia
Con el tiempo aprendes que:
- ninguna decisión es perfecta
- todas tienen trade-offs
- casi todas son temporales
Y que el valor no está en:
- acertar siempre
- elegir “la mejor” tecnología
Está en:
- entender el contexto
- decidir con intención
- asumir consecuencias
- aprender
- ajustar
Eso es, para mí, lo que mejor define el seniority.
Aprender a decidir y convivir con ello no va de ser inflexible.
Va de ser responsable.
Decidir con lo que sabes hoy.
Aceptar las consecuencias.
Y recordar que, en software, casi nada está escrito en piedra.
Eso no te hace débil.
Te hace profesional.
