Primeros 90 días: Guía paso a paso para ingenieros de software
Has estado en las trincheras.
Puliste tu currículum hasta que brilló. Mejoraste tus habilidades y tus certificaciones.
Pusiste a punto tu GitHub, estudiaste preguntas de diseño de sistemas hasta que se mezclaron en tu cabeza y pulsaste “aplicar” más veces de las que prefieres admitir.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Superaste la serie de entrevistas: pizarras, tareas para llevar a casa, silencios incómodos y todo lo demás. Mejoraste tus habilidades y mantuviste la compostura.
Y entonces… llegó la carta de oferta. ¡Conseguiste el trabajo! Ahora comienza el verdadero trabajo.
Porque aunque contratar es difícil, integrarse de forma efectiva lo es aún más. Aquí es donde pasas de ser candidato a contribuir de verdad, y donde las primeras impresiones se vuelven duraderas. Tus primeros 90 días sentarán las bases para todo lo que venga después.
En esta guía, te acompañaré paso a paso para que arranques con éxito como nuevo ingeniero de software, con consejos prácticos de dos profesionales veteranos del sector tecnológico que saben de lo que hablan. Pero primero, empecemos con una mirada realista sobre lo que realmente significa ser ingeniero de software hoy en día.
¿Qué es un ingeniero de software?
Vaya, ¿por dónde empezamos? En serio, podrías escribir un libro sobre este tema, en parte porque el término a veces se utiliza como comodín para múltiples posibles roles que abarcan todas las fases del ciclo de vida del desarrollo de software. Como resultado, otros títulos podrían ser relevantes aquí, como desarrollador o programador. Usamos 'ingeniero de software' como un término paraguas.
Aquí tienes una definición concisa de ingeniería de software, cortesía de la Universidad Tecnológica de Míchigan, para mantenernos enfocados: “La ingeniería de software es la rama de la informática que se ocupa del diseño, desarrollo, prueba y mantenimiento de aplicaciones de software. Los ingenieros de software aplican principios de la ingeniería y conocimientos de lenguajes de programación para construir soluciones de software para los usuarios finales.”
Si reduces todo a lo más simple, sería algo así: los ingenieros de software crean cosas digitales para que las usen personas y máquinas. En vez de usar martillo y clavos, utilizan código, junto con una variedad de herramientas como Git y otros componentes.
También debemos mencionar una de las razones por las que muchas personas quieren dedicarse a la ingeniería de software: el trabajo puede estar bien remunerado. El sitio de empleos Glassdoor sitúa la paga total media para los ingenieros de software en $147,000 al año (última consulta: 28 de abril de 2025), aunque los números reales variarán en función de la experiencia, la ubicación y el sector.
Ahora, vamos a profundizar en algunos consejos e ideas accionables para empezar con el pie derecho.
Los primeros 30 días
En nuestro artículo complementario sobre carreras en ciberseguridad, señalamos que los primeros 30 días básicamente se reducen a aprender. Eso significa desde bases de código y herramientas hasta nuevas caras y nuevos lugares. Y eso sigue siendo cierto aquí, aunque con algunos matices.
Consejo nº 1: No todos los stacks tecnológicos son iguales
Navegar por tu nuevo rol debe implicar aprender tanto sobre las personas y los procesos como sobre la base de código o el stack tecnológico.
“Por mi experiencia en grandes empresas, es más importante entender a las personas [y] los procesos que la arquitectura del código,” dice Justin Garrison, Jefe de Producto en Sidero Labs. Antes de su puesto actual, Justin trabajó como Senior Developer Advocate en AWS y en varios roles de ingeniería en Disney, incluyendo ingeniero sénior de software.
Consejo nº 2: Entiende cómo la empresa genera ingresos
Para maximizar tu valor, debes entender cómo la organización genera su valor.
“Además de aprender el stack técnico y los requisitos, los ingenieros deben averiguar cómo la empresa crea valor y cómo cobra,” cuenta Chris Carter, Principal Product Manager en NetApp Instaclustr. Antes de asumir su puesto actual, Chris comenzó en la compañía como ingeniero sénior de desarrollo y líder de equipo de ingeniería. Continúa:
“¿Suscripciones directas? ¿Equipo de ventas de campo y acuerdos personalizados? ¿Vistas y publicidad? Averigua cómo se mide la empresa a sí misma y cómo se pasa del código al KPI.”
Construye ese entendimiento cuanto antes. Los ingenieros de software que pueden conectar los puntos entre su código y las finanzas de la empresa rara vez pasan de moda.
“Al comprender cómo la empresa mide su propio éxito, puedes posicionarte para ser parte de la generación de ese éxito y contribuir a los resultados,” dice Chris.
Consejo #3: Clona el repositorio, pero no apresures el commit
Claro, tienes ganas de hacer ese primer PR. Pero trata la base de código como un organismo vivo: observa sus patrones, comprende su anatomía y haz preguntas antes de operar. Usa las funciones de navegación de código de tu IDE, comandos grep o búsqueda en el repositorio para seguir cómo fluyen los datos y la lógica por el sistema.
¿Y si te atascas? Intenta reproducir el comportamiento localmente y luego rastrearlo paso a paso. Los depuradores están subestimados, y hablarle a un pato de goma sigue funcionando.
Consejo Pro: Mira los PRs fusionados recientemente para entender el estilo de código, la cultura de revisión y cómo es realmente un trabajo “terminado”.
Los primeros 60 días
Una de las mejores maneras de ponerse al día rápidamente es ser curioso, no solo sobre qué hace el código, sino por qué lo hace de esa manera.
Consejo #4: Pregunta “¿Por qué se construyó de esta manera?”
El código heredado puede parecer un espagueti, pero a menudo hay sustancia en la salsa. Restricciones de un servicio ya retirado, una compensación de rendimiento, un requisito comercial de una función ya eliminada: estas decisiones tienen historia. Aprender esa historia te ayuda a evitar sugerir algo que ya se probó (y fracasó), y fortalece tu credibilidad.
Empieza con la documentación interna (aunque esté desactualizada). Luego pide a un compañero que te explique algo confuso, y trátalo como coautor de la historia del sistema.
“¿Qué decisiones están codificadas en este código?” es una mejor pregunta que “¿Por qué este código apesta?”
Consejo #5: Identifica las “reglas no escritas” de tu equipo
Toda organización de ingeniería las tiene. Tal vez el equipo prefiere RFCs en Notion en vez de tickets en Jira, o que todos despliegan los jueves, o que las pruebas unitarias son opcionales, pero las pruebas e2e son sagradas.
Estas normas no siempre estarán en un manual, pero darán forma a tu éxito tanto como tus habilidades de programación. Observa los patrones en Slack, estudia los mensajes de commits en Git y pregunta a tus compañeros qué les hubiera gustado saber cuando se unieron.
Consejo #6: Sigue reuniéndote con personas (y aprendiendo de ellas)
Justin de Sidero Labs sostiene que reunirse con personas ayuda a los ingenieros a entender cómo los sistemas funcionan juntos más allá del código: “Al final de esas reuniones, era mucho más fácil comprender por qué los sistemas son como son.”
Eso tiene muchos beneficios en cascada, incluyendo reducir tu presión arterial cuando lees código que al principio no parece tener sentido. Si un humano lo escribió, probablemente tenía una razón para hacerlo así, y esas pueden incluir variables organizativas, presión de tiempo, y demás.
Este tipo de comprensión holística ayuda en cuanto a cultura de equipo y comunicación, pero también aporta empatía y diplomacia cuando llega el momento de buscar y sugerir mejoras.
Los primeros 90 días
Ya has crecido: “En 90 días, deberías haber encontrado tu lugar y, con suerte, ser capaz de asumir tareas más grandes,” dice Chris de NetApp Instaclustr.
Esta última fase trata realmente de planificar y empezar a ejecutar. ¿Dónde
puedes empezar a tener un impacto real?
Consejo #7: Comienza a optimizar con propósito e impacto
A los 90 días, ya no eres solo el “nuevo ingeniero”: te estás convirtiendo en un contribuidor emergente. Eso significa que es hora de buscar oportunidades para mejorar las cosas. Pero hay una trampa: no toda mejora vale la pena, y no todos los bugs merecen ser corregidos.
“No se trata de hacer una lista interminable de cosas rotas,” dice Chris. “Se trata de comprender el negocio, el cliente y el contexto, y luego usar ese conocimiento para identificar formas significativas de mejorar.”
Así es como Chris y su equipo aplican esa mentalidad:
- Pensar aguas arriba: No saltes directamente a las soluciones—empieza escribiendo tickets claros que describan el problema.
- Prioriza sabiamente: Aprende cómo tu equipo valora impacto, esfuerzo y urgencia. ¿Un bug trivial de interfaz en una pantalla obsoleta? Probablemente no sea urgente.
- Mentalidad enfocada al cliente: Pregúntate siempre, “¿Esto le importará a un usuario real?” Si no, archívalo y sigue adelante.
Una vez que hayas aprendido los sistemas y la cultura, empieza a buscar tareas de mayor impacto—cosas que reduzcan fricción, mejoren la entrega o eleven la experiencia del cliente.
“Al entregar constantemente trabajos que hacen avanzar los objetivos del negocio, rápidamente te reconocerán como alguien que ‘entiende’—y en quien se puede confiar con cosas más grandes,” dice Chris.
Consejo #8: Entrega algo. Lo que sea. Pero hazlo tuyo.
Para el día 90, no necesitas haber reescrito un servicio central o haber lanzado una nueva funcionalidad en solitario. Pero deberías poder señalar al menos una cosa, por pequeña que sea, que hayas entregado y de la cual te hayas hecho responsable de principio a fin.
Eso podría ser:
- Una corrección de error que redujo la fricción para el usuario
- Un ajuste en la pipeline de CI/CD que aceleró los builds
- Una renovación del README que ayudó a la próxima nueva incorporación
- Una optimización en el backend que redujo 50ms de una consulta común
No tiene que ser llamativo—tiene que ser útil. El impacto no se trata de brillo; se trata de función.
Mantra del ingeniero: “¿Hice la vida del equipo un 1% mejor esta semana?”
Consejo #9: Crea un backlog personal de aprendizaje
No vas a dominar toda la base de código, la infraestructura y la lógica del negocio en 90 días. Está bien. Lo que importa es lo que haces después.
Crea un “backlog” personal de habilidades y vacíos de conocimiento. Anota:
- Áreas del sistema que aún no comprendes
- Herramientas o frameworks que quieras aprender en profundidad (por ejemplo, Kubernetes, gRPC, Terraform)
- Deuda técnica o rarezas que quieras volver a revisar
Luego, prioriza una cosa por sprint y márcala como hecha. No solo estás aprendiendo el sistema—estás diseñando tu propio roadmap de crecimiento.
Suscríbete al boletín de The CTO Club para recibir más playbooks para tus primeros 90 días en cualquier puesto tecnológico.
