Yo siempre quise ser programador. Por eso en la universidad hice todas las asignaturas de programación, algorítmica y bases de datos. No me interesaba mucho la seguridad informática - por eso no la cursé - y era normal. Ya sabéis que comencé con 12 años a programar en BASIC tras ver la película de TRON de la que tanto os hablo por aquí.
Lo cierto es que me picó el veneno del hacking y la ciberseguridad, y ya es difícil cambiar eso, pero sigo amando a esa "rara avis" que existe es nuevo mundo como nombre antagonista a "Hacker": "Developer". Por eso cuando conozco algún developer quiero saber más de él.
Este es el caso de Alejandro Acosta, que tras comenzar cobrando 300 € - yo comencé programando gratis en mi beca -, se fue a Silicon Valley a pasarse el juego, y lograr cobrar 1.000.000 de USD como desarrollador en Microsoft. No está mal. Puedes saber todo lo que hace hoy en día, en Engineer Game.
Como creo que su historia es curiosa, le he hecho una entrevista, pero diferente. Le he dejado diez temas abiertos para que él conteste de ellos, y aquí están las respuestas. Si quieres conocer más de él, puedes contactar con él a través de su buzón de MyPublicInbox o solicitarle directamente una clase gratuita, si quieres ser un desarrollador que haga "las américas".
1. El mito de las 1.000 entrevistas vs. la contratación en la era de la IA
Los fundamentos son hoy más importantes que nunca. En una entrevista no se evalúa únicamente si una persona puede completar un ejercicio de live coding o diseñar un sistema, sino su capacidad para analizar problemas reales, razonar bajo presión y encontrar soluciones aplicables a producción.
La inteligencia artificial es una gran aliada, pero resolver un ejercicio con su ayuda no demuestra por sí solo que alguien sea un buen ingeniero. La diferencia aparece cuando el entrevistador introduce nuevas restricciones, cuestiona una decisión o complica progresivamente el problema. Es en ese diálogo donde se comprueba si el candidato entiende realmente lo que está haciendo.
Por eso, especialmente en el mercado de Silicon Valley, prepararse sigue siendo fundamental. La constancia, el estudio y el dominio de áreas como live coding y system design continúan siendo determinantes para acceder a las mejores oportunidades y alcanzar una compensación elevada. Esa es también la razón por la que en EngineerGame acompaño a ingenieros de software que quieren dar un salto en sus carreras.
2. SRE y ciberseguridad: cuando el sistema cae a las 3:00 AM
El error más común es diseñar la arquitectura pensando que los incidentes pueden evitarse por completo. En las grandes empresas se asume que, tarde o temprano, habrá una caída crítica. La diferencia no está solamente en prevenirla, sino en la capacidad de detectarla, contenerla, recuperarse y aprender de ella.
La cultura es decisiva tanto antes como después del incidente. Antes, porque deben existir mecanismos de prevención, observabilidad y respuesta. Después, porque hay que realizar un análisis sin culpabilizar a las personas, identificar las causas y aplicar cambios que impidan que el mismo problema vuelva a repetirse.
Prácticas como Chaos Engineering permiten comprobar qué sucede cuando falla una dependencia, una región o un componente crítico. No todas las empresas necesitan aplicarlo con la misma profundidad, pero todas deberían diseñar sus sistemas partiendo de una idea básica: cualquier componente puede fallar.
3. AIOps y el dilema del self-healing
Confío en la inteligencia artificial como apoyo durante el ciclo de desarrollo y en las operaciones diarias. Puede ayudar a investigar incidentes, relacionar señales y reducir considerablemente el tiempo necesario para resolver problemas críticos.
Sin embargo, la autorremediación ya existía antes de la IA. Muchos incidentes pueden resolverse de manera más segura y predecible mediante automatizaciones tradicionales: reiniciar un servicio, escalar recursos o ejecutar un procedimiento previamente validado. No hace falta introducir un modelo de IA donde un sistema determinista ya resuelve bien el problema.
La frontera debe establecerse en función del riesgo. Un agente puede recomendar acciones o ejecutar operaciones reversibles dentro de unos límites muy definidos, pero no debería disponer de permisos ilimitados sobre producción. Cuanto mayor sea el impacto potencial de una decisión, mayores deben ser la supervisión humana, la trazabilidad y los mecanismos de aprobación. La IA debe potenciar al equipo, no sustituir los controles operativos y de seguridad.
4. Emprender con open source
Hoy el open source ya no es una alternativa marginal: forma parte del ciclo de desarrollo de prácticamente cualquier empresa tecnológica. Lenguajes como Go, Python o Rust y plataformas como .NET muestran hasta qué punto la innovación actual se construye de manera abierta y colaborativa.
Que el código sea visible puede facilitar que un atacante estudie sus vulnerabilidades, pero también permite que muchas más personas lo auditen, detecten errores y propongan mejoras. La seguridad no depende únicamente de que el código sea abierto o cerrado, sino de cómo se mantiene el proyecto, cómo se revisan las contribuciones y con qué rapidez se corrigen las vulnerabilidades.
Mi apuesta seguirá siendo la innovación abierta, acompañada de una gestión responsable de dependencias, auditorías continuas y procesos claros de actualización y respuesta ante incidentes.
5. El bug cultural: Madrid vs. Silicon Valley
La diferencia principal es de mentalidad. En Estados Unidos, y especialmente en Silicon Valley, es habitual encontrar desarrolladores que buscan crecer constantemente, asumir retos y aumentar el impacto de su trabajo. Es un entorno en el que la innovación necesita talento y donde existe una competencia muy intensa por progresar.
En el ecosistema español, a veces echo en falta algo más de ambición y predisposición a asumir riesgos. Es una diferencia cultural que he observado trabajando y conversando con profesionales tanto en Estados Unidos como en España.
El parche pasa por dejar de concentrarse en la queja y empezar a tomar decisiones. Hay que aceptar que crecer implica incomodidad, aprendizaje continuo y exposición al fracaso. No se trata de copiar Silicon Valley, sino de adoptar una mentalidad más activa: querer más, prepararse mejor y actuar en consecuencia.
6. Shadow IT y la tentación del desarrollador en la era de la IA
La solución no consiste en enfrentar la velocidad del desarrollador con el control del equipo de seguridad. Ambos objetivos deben integrarse en el mismo ciclo de desarrollo.
Cada vez veo más empresas incorporando herramientas de seguridad y controles de compliance directamente en los repositorios y los procesos de CI/CD. Esto permite detectar dependencias vulnerables, revisar configuraciones, aplicar parches y bloquear cambios de riesgo antes de que lleguen a producción.
El equipo de seguridad debe ofrecer mecanismos rápidos y fáciles de utilizar, no convertirse en un obstáculo que los desarrolladores intenten evitar. Cuando los controles están automatizados y aparecen en el momento adecuado, por ejemplo durante la revisión de una pull request, es posible mantener la velocidad sin trasladar toda la remediación al final del proceso. Lo digo también desde la experiencia de haber participado en proyectos donde ha sido necesario conciliar ambos mundos.
7. La newsletter diaria y el valor de la comunicación directa
La clave está en la personalización. En un entorno saturado de contenido automático, las personas valoran saber que detrás de una respuesta hay alguien que ha leído su caso y se ha tomado el tiempo de comprenderlo.
Por eso mantengo abiertos mis canales de comunicación y trato de responder personalmente a quienes contactan conmigo. Para mí no es solo una estrategia de marca personal, sino una manera de ayudar de forma directa a profesionales que quieren mejorar su carrera.
La tecnología permite llegar a muchas personas, pero la confianza se construye conversación a conversación. Esa cercanía es difícil de sustituir con respuestas masivas, por muy sofisticadas que sean.
8. La seguridad en el pipeline CI/CD
Los primeros síntomas aparecen cuando desplegar rápido se convierte en la única métrica de éxito. Si cualquier dependencia puede incorporarse sin validación, los secretos aparecen en configuraciones o repositorios, los permisos del pipeline son excesivos y los controles de seguridad se realizan únicamente después del despliegue, existe un problema claro.
La seguridad debe formar parte del CI/CD desde el principio: análisis de dependencias, detección de secretos, revisión de permisos, escaneo de imágenes y artefactos, validación de cambios y protección de ramas y entornos críticos.
Estos controles deben diseñarse con suficiente flexibilidad para no bloquear innecesariamente al desarrollador. En ese punto, la automatización y los agentes pueden ser muy útiles: permiten detectar riesgos durante la pull request, explicar el problema y proponer una remediación antes de que el cambio llegue a producción.
9. Move fast and break things frente a la realidad del ciberriesgo
Aunque este lema se ha asociado durante años con empresas como Meta, no representa el funcionamiento de toda la industria tecnológica. Muchas compañías son mucho más cautelosas, especialmente cuando gestionan datos sensibles o infraestructuras críticas.
Sí es cierto que en Silicon Valley los cambios se producen a gran velocidad. En SRE, por ejemplo, he visto evolucionar una misma infraestructura desde Mesos y DC/OS hasta Kubernetes, EKS, AKS o Cluster API en un periodo relativamente corto. Esa velocidad puede exigir rediseños profundos, pero no significa que la seguridad deba ignorarse.
La interpretación correcta no debería ser «avanza rápido y rompe cualquier cosa», sino «aprende y evoluciona rápido dentro de unos límites seguros». La ciberseguridad debe estar presente desde el día cero, con equipos y procesos capaces de acompañar la innovación. Cuanto más rápido se mueve una empresa, más importantes son los controles que permiten hacerlo sin asumir riesgos inaceptables.
10. El hotfix mental para el ingeniero moderno
Aplicaría un hotfix muy concreto: dejar de pensar que una buena carrera se construye únicamente escribiendo buen código. Un ingeniero debe dominar los fundamentos técnicos y saber resolver problemas, pero también necesita aprender a comunicar, negociar, mostrar su valor y tomar decisiones estratégicas sobre su trayectoria.
La inteligencia artificial no elimina esa necesidad. Puede acelerar muchas tareas, pero no sustituye el criterio, el conocimiento técnico ni la responsabilidad sobre las soluciones que se llevan a producción.
Si pudiera abrir una pull request para actualizar la mentalidad de cualquier desarrollador, incluiría estos elementos: consistencia, persistencia, capacidad de comunicación y venta, marca personal, negociación y un dominio técnico sólido, incluidos live coding y system design. En definitiva, tratar la carrera profesional como un proyecto del que uno mismo es responsable.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
No hay comentarios:
Publicar un comentario