Lo que aprendí después de 13 años trabajando en proyectos privados

Cuando alguien me pide el enlace a mis proyectos, siempre hay un momento incómodo.

No tengo ninguno que mostrar. Todo lo que he construido desde 2012 vive detrás de logins, NDAs y dominios corporativos que no me pertenecen.

Durante mucho tiempo lo viví como una desventaja. Ahora entiendo que fue exactamente lo contrario.

Lo que pierdes trabajando en privado

Seré directo: pierdes visibilidad. No acumulas stars en GitHub. Nadie linkea tu trabajo en Twitter. Los recruiters no encuentran un portfolio brillante cuando buscan tu nombre.

Eso es real y tiene coste, especialmente en los primeros años.

Lo que ganas a cambio

Presión de producción real

Cada línea de código que escribí fue a producción. Con usuarios reales, datos reales, consecuencias reales.

Eso te enseña cosas que ningún proyecto personal puede replicar: cómo se comporta tu código bajo carga, qué pasa cuando un despliegue de madrugada — para no afectar al negocio del cliente — sale mal y acabas arreglándolo a las 3am, o por qué la solución elegante del viernes falla el lunes con datos edge-case que nadie anticipó.

Criterio, no solo habilidad

Trabajar en productos con presupuesto y stakeholders te obliga a tomar decisiones de trade-off constantemente. ¿Hacemos esto bien ahora o lo suficientemente bien para lanzar? ¿Esta deuda técnica es aceptable? ¿Vale la pena refactorizar esto antes de añadir la feature?

Nadie te enseña a responder esas preguntas. Las aprendes tomándolas, equivocándote y cargando con las consecuencias.

La capacidad de trabajar con otros

El código solo es fácil. El código en equipo es donde está la dificultad real.

Más de una década de pull requests, discusiones de arquitectura, code reviews y decisiones en grupo me han dado algo que ningún proyecto solo puede darte: sé cómo comunicar una idea técnica, cómo defender una posición sin generar fricción, y cuándo ceder porque el otro tiene razón.

La conclusión

No tener proyectos públicos no significa no tener nada que mostrar.

Significa que tienes que ser mejor explicando lo que hiciste, por qué lo hiciste así, y qué aprendiste. Que tienes que demostrar criterio en lugar de pantallazos.

Este blog es mi intento de hacer exactamente eso. Cada post que escribo aquí nace de una decisión real, un problema concreto o una opinión formada a base de años de proyectos que no puedo enlazarte pero que han dejado huella en cómo pienso y cómo trabajo.