Sobre mí
Soy Juan Pablo Castro, Software Engineer y AI Product Engineer especializado en TypeScript, Node.js, AWS y productos con IA. Llevo cerca de ocho años construyendo software, los últimos entre arquitectura, liderazgo técnico y desarrollo hands-on.
Trabajo desde el problema hasta producción: producto, arquitectura, código e infraestructura, sin alejarme del desarrollo por el camino. Ahora de forma independiente y con productos propios.
01 — QUORSUM
Construir software sí, pero ¿para qué?
Antes de elegir tecnología quiero saber qué merece la pena construir y qué valor va a dejar. Todo producto se sostiene sobre tres cosas: el valor que aporta, el coste de existir y el tiempo que va a vivir.
02 — CÓMO PIENSO
No me basta con que funcione.
Una solución puede funcionar hoy y seguir siendo una mala decisión. Me importa entender qué estamos construyendo, qué compromisos estamos aceptando y qué consecuencias tendrá cuando el sistema crezca, cambie o llegue a producción.
03 — INGENIERÍA
La simplicidad se trabaja.
Las soluciones sencillas casi nunca aparecen a la primera. Llegar a ellas exige entender el sistema a fondo: primero sale lo que funciona y, con insistencia, después lo que se entiende de un vistazo.
04 — CRITERIO
Programar rara vez es la parte más difícil.
Las decisiones importantes ocurren antes del código: qué construir, qué no construir y qué consecuencias estamos dispuestos a aceptar. El código en sí tiende a valer cero; lo que sostiene un sistema es haber entendido por qué es así.
05 — RESPONSABILIDAD
El trabajo no termina en el merge.
Mi responsabilidad no acaba cuando el código entra. Me importa qué ocurre en producción y cómo responde el sistema ante usuarios reales.
06 — PERSONAS
Las mejores ideas sobreviven al debate.
No protejo mis ideas. Las explico, las discuto y las cambio cuando aparece una solución mejor. Espero lo mismo de quien trabaja conmigo.
07 — CURIOSIDAD
Necesito saber cómo funciona por dentro.
Desmonto mentalmente lo que uso hasta entender lo suficiente para construir algo mejor. Esa manía es la que sostiene el criterio cuando aparece una herramienta nueva.
08 — ORIGEN
Entré por resolver problemas de otros.
Con algo de creatividad y bastante optimismo. Ayudar a quien tengo al lado sigue siendo parte del trabajo, no un extra.
09 — EXPERIENCIA
Las herramientas cambian. El criterio se acumula.
Cuando producir código es barato, la diferencia está en qué decides construir y qué consecuencias aceptas. Ocho años dejan pocas certezas y bastantes cicatrices útiles.
10 — DISCIPLINA
Hago bien el trabajo que nadie mira.
Las pruebas, los registros, la documentación y el detalle aburrido deciden si el sistema aguanta seis meses después. El resultado llega por acumulación.
11 — OFICIO
Cuido lo pequeño igual que lo grande.
Quien se preocupa por las cosas cuando hay poco también lo hace cuando hay mucho. El nivel de cuidado no depende del tamaño del proyecto.
12 — EMPRENDER
Mi primer proyecto fue solidario.
Yodono: crowdfunding para costear tratamientos médicos, con donaciones y merchandising. Me dejó claro que un producto solo existe por las personas a las que sirve.
13 — COMUNICACIÓN
Los riesgos se dicen pronto.
Un problema visible hoy sale mucho más barato que una sorpresa dentro de tres meses. Digo lo incómodo a tiempo, con el trade-off encima de la mesa.
14 — ARQUITECTURA
Una arquitectura se gana en el código.
No separo diseñar de construir: sigo con las manos dentro del repositorio. Y no sobrearquitecturo, porque la complejidad que añades hoy la paga el equipo durante años.
15 — REQUISITOS
No ejecuto requisitos a ciegas.
Cuando veo un riesgo o una alternativa mejor, lo digo con argumentos. Después ejecuto la decisión que se tome, sea la mía o no.