Cuando entré a mi primer trabajo de desarrollador venía con una idea muy clara de lo que iba a hacer. Patrones de diseño, arquitectura, UML, escribir código limpio desde cero. Llegué con la mochila llena de cosas que aprendí en la escuela y en cursos.
A los pocos días me di cuenta de que la realidad era otra.
No estoy diciendo que lo que aprendí no sirviera. Sirve, y mucho. Pero el trabajo del día a día no se parecía a los proyectos personales ni a los ejercicios de clase. Era otra cosa.
Lo que te comparto aquí está basado en mi experiencia. Son cosas que viví, errores que cometí, y aprendizajes que fui agarrando con el tiempo. Si vas entrando a tu primer trabajo o llevas pocos meses, espero que te sirva para no chocar con los mismos muros que yo y para crecer más rápido de lo que yo lo hice.
Resumen rápido: aprende a leer código ajeno, propón cambios con argumentos, escribe pruebas útiles, documenta lo que aprendes, pregunta antes de programar, entiende el negocio, pide ayuda rápido, habla en los meetings, lleva registro de lo que haces y únete a comunidades. Suena obvio, pero nadie te lo dice antes.
1. Aprende a leer código ajeno
Cuando entré a mi primer trabajo pensé que iba a diseñar sistemas desde cero. Arquitectura hexagonal, Clean Code, patrones de diseño. Pasé semanas leyendo código que escribió alguien que ya ni trabaja en la empresa, intentando entender por qué tal función hacía lo que hacía.
Al principio me frustré. Después entendí que eso era el trabajo.
La mayor parte del tiempo vas a mejorar lo que otras personas ya hicieron. Agregar un pedacito, arreglar lo que está roto sin romper lo que sí funciona. Y mientras más rápido aprendas a leer código ajeno, más rápido vas a entender el sistema completo y más valor vas a aportar.
Esa habilidad, leer código, es lo que te diferencia en los primeros meses. No el framework que conoces ni los patrones que estudiaste.
Acción: cuando entres a un proyecto nuevo, dale dos o tres días solo a leer. Sin tocar nada. Toma notas, dibuja diagramas a mano, anota dudas. Vas a avanzar más rápido cuando empieces a programar.
2. Aprende a proponer cambios con argumentos, no con opiniones
Cuando llegué a una empresa me encontré con proyectos legacy enormes. Monolitos de los que dependían muchas otras cosas y muchos otros equipos. Yo quería proponer migrar a microservicios, actualizar el framework, modernizar todo.
Nadie me hizo caso. Y tenían razón.
Mover un sistema así puede tomar meses. A veces años. Y mientras tanto el negocio sigue corriendo, los clientes siguen pagando. Nadie va a detener eso para esperar a que termines de migrar.
Lo que aprendí es que la diferencia entre un JR que propone cosas y uno que las ve implementadas es cómo las presenta. Una opinión es "deberíamos actualizar esto". Un argumento es "esta versión tiene una vulnerabilidad de seguridad conocida, migrar nos tomaría dos sprints, y si no lo hacemos corremos este riesgo".
Acción: antes de proponer una actualización o migración, prepara tres cosas: el problema concreto que resuelve, el costo estimado en tiempo, y el riesgo de no hacerlo. Con eso tienes una conversación real con tu equipo.
3. Escribe pruebas que de verdad prueben algo
Yo venía con la idea de que las pruebas unitarias eran sagradas. Llegué pensando que iba a encontrar suites de tests bien hechas, con cobertura útil, validando edge cases.
Lo que me encontré fue otra cosa. Pruebas que validan cosas obvias. Pruebas con mocks tan cargados que terminan probando el mock y no el código. Pruebas escritas únicamente para llegar al 80% de cobertura que pide el pipeline. Y nadie las entiende porque las escribió alguien que ya se fue.
Aquí está la oportunidad. Cuando el equipo tiene esa cultura, tú puedes destacar haciendo lo contrario. Escribe pruebas que cubran los casos donde el código se puede romper. Que un compañero pueda leerlas y entender qué están validando.
Va a tomar más tiempo que copiar el patrón malo del repo. Pero te va a salvar de bugs en producción, y poco a poco la gente del equipo se da cuenta y empieza a hacer lo mismo.
Acción: la próxima vez que escribas una prueba, hazte esta pregunta antes de terminar: "¿si alguien rompe esta función, mi prueba lo detecta?" Si la respuesta es no, reescríbela.
4. Documenta lo que aprendes, aunque nadie te lo pida
He trabajado en proyectos donde el README dice cosas que dejaron de ser ciertas hace dos años. En otros, el README es solo el comando de instalación. Y en algunos, no hay nada.
Eso es una oportunidad.
Cuando eres el nuevo y te toca entender el sistema desde cero, cada cosa que descubres tiene valor. Por qué tal servicio hace lo que hace, cómo se conecta con el otro, qué pasa si falla. Escríbelo. En una wiki interna, Confluence, Notion, donde sea, pero que todo el equipo pueda verlo.
Esto te sirve a ti porque dentro de seis meses no te vas a acordar. Le sirve a la persona nueva que va a entrar. Y cuando la gente ve que tú escribes documentación, algunos empiezan a hacer lo mismo.
No te desanimes si al principio nadie la lee. La vas a usar tú primero, y eso ya justifica el esfuerzo.
Acción: esta semana, cuando resuelvas algo que no estaba documentado, escríbelo. Una sola entrada. Dónde está, qué hace, por qué funciona así. Cinco minutos. Eso es todo.
5. Pregunta antes de programar
A mí me pasó muchas veces que recibí un ticket con pasos detallados, lo hice al pie de la letra, y al final el usuario decía "no, eso no era lo que necesitaba". Es frustrante para los dos.
El problema no era el código. Era que nunca pregunté para qué servía lo que estaba construyendo.
Los tickets ambiguos son normales. "Agregar botón de exportar" sin decir qué exporta, en qué formato, quién lo va a usar. Una lista de pasos sin contexto del problema que están tratando de resolver. Eso va a pasar siempre. La diferencia está en si arrancas a programar de inmediato o si primero entiendes qué estás resolviendo.
Cuando un ticket no tiene contexto suficiente, pregunta. ¿Para qué se va a usar esto? ¿Qué problema resuelve? ¿Qué pasa si no lo hacemos? Muchas veces salen detalles que el ticket no decía, y a veces descubres que la solución que pedían no era la que necesitaban.
Acción: la próxima vez que recibas un ticket, antes de abrir el editor, escribe en dos oraciones qué problema resuelve y para quién. Si no puedes, el ticket está incompleto y hay que preguntar.
6. Entiende el negocio detrás del software
Esto está conectado con el punto anterior, pero va más allá.
Conocer el negocio te hace mejor desarrollador. Suena raro, pero es cierto. Cuando entiendes para qué se va a usar lo que estás construyendo, qué clientes lo van a tocar, cuánto vale para la empresa, tomas mejores decisiones técnicas.
Te pongo el caso del ticket. Si el ticket sí tiene una definición completa, igual vale la pena cuestionar. ¿Esto es bueno para el usuario final? ¿Hay otra parte del sistema que se va a ver afectada con este cambio? ¿Existe una solución más simple que la que están proponiendo?
Cuando haces estas preguntas dejas de ser solo el que ejecuta tickets y empiezas a aportar al producto. Eso es lo que te diferencia. Tu manager se va a dar cuenta. Tu equipo también.
Y para entender el negocio no tienes que meterte en cursos de business ni leer libros de estrategia. Solo platica con la gente de producto, con soporte, con ventas. Pregúntales qué problemas tienen los clientes. Mete la nariz en las métricas del producto si tienes acceso. En poco tiempo vas a ver resultados.
Acción: agenda una llamada de 30 minutos con alguien de producto o soporte. Solo para escuchar. Pregúntales qué es lo que más les reportan los clientes. Esa conversación te va a cambiar cómo ves tu trabajo.
7. Pide ayuda rápido
Este es el punto que a mí me hubiera gustado escuchar más temprano.
Yo soy bastante necio con los problemas. Me encanta resolverlos por mi cuenta, sentir el placer de cerrar las 45 pestañas de Stack Overflow después de horas peleando con un bug. Pero esto a veces juega en contra.
Pasa así. Te trabas en algo, te das cuenta de que no avanzas, pero te sientes mal pidiendo ayuda. Entonces sigues intentando. Pasan dos horas. Cuatro. Un día. Y al final pides ayuda y resulta que alguien del equipo lo había visto antes y te lo resolvía en quince minutos.
Lo que hago ahora es ponerme un timebox. Una o dos horas máximo intentándolo solo. Si no resuelvo, pido ayuda. Eso le ahorra tiempo al equipo y a mí.
Y cuando pidas ayuda, hazlo bien. No llegues con "no me funciona". Llega con "estoy intentando hacer X, probé Y y Z, esperaba que pasara A pero pasa B, aquí está el error". Eso le ahorra tiempo a quien te ayuda y aprendes a estructurar problemas.
Acción: pon un timer de una hora la próxima vez que te trabes. Si suena y no resolviste, para y pide ayuda. Sin culpa.
8. No tengas miedo de hablar en los meetings
Cuando entré a trabajar me quedaba callado en las llamadas. Esperaba a que alguien con más experiencia hablara y yo solo asentía. Tenía miedo de equivocarme, de decir algo tonto, de que la gente pensara que no sabía.
Después de un tiempo le pregunté al senior del equipo qué me hacía falta para crecer. Una persona con la misma experiencia que yo había sido promovida y yo no. Me dijo: "casi no hablas en las llamadas".
Me explicó que no se trataba de hablar por hablar. Era dar mi opinión, cuestionar cuando no estaba de acuerdo, proponer ideas. No solo aceptar todo lo que decían los demás.
Esto fue duro de aceptar. Pero tenía razón.
Empecé a forzarme a hablar. Aunque tuviera miedo. Aunque pensara que mi idea no era tan buena. Y la verdad es que muchas veces me equivoqué. Pero también muchas veces aporté algo útil que nadie había considerado.
Hoy en día sigo sintiendo nervios antes de hablar en juntas grandes. Sigue ahí ese miedo. Pero también recuerdo que cada vez que aporto, construyo confianza con mi equipo. Y eso es lo que hace que la gente te tome en serio.
Acción: en tu próxima junta, di una cosa. Una opinión, una pregunta, una duda. Solo una. No tienes que resolver todo, solo participar.
9. Lleva un registro de tus contribuciones
Este punto no me lo enseñaron nunca y es probablemente el más importante para destacar.
Tu equipo y tu manager necesitan saber qué haces. Suena obvio, pero no lo es. Por más que pensemos que los demás se acuerdan de lo que hicimos, no es así. La gente tiene su propio trabajo, sus propios problemas, sus propias prioridades.
Lleva un documento, en Word, Notion, Notes, donde sea, y anota tus contribuciones cada semana. No tiene que ser elegante, solo tiene que existir.
La forma en que lo escribas importa. Si solo anotas tareas, te sirve poco. Si lo enfocas en impacto, te sirve mucho.
Compara estos dos:
- Llamada con Juan
- Apoyé a Juan a resolver un error en el sistema de pagos.
Esto desbloqueó el proceso de cobros que llevaba 2 semanas
fallando para 200 clientes.
Las dos describen la misma reunión. Pero la segunda te ayuda en performance reviews, en conversaciones con tu manager, en negociaciones de aumento. Cuando llega el momento de demostrar tu valor, este documento es oro.
Cuando te llamen para una entrevista futura, vas a tener un registro real de lo que hiciste. Sin tener que pensar "¿qué hice los últimos dos años?".
Acción: abre un documento ahora y escribe tres cosas que hiciste esta semana, enfocadas en impacto. Si no recuerdas tres, escribe una. El hábito empieza con una entrada.
10. Únete a comunidades
Todo lo anterior pasa dentro de tu equipo. Pero crecer rápido también pasa por la gente que conoces fuera de él.
Las comunidades son ese espacio donde aprendes cosas que en tu empresa nadie usa, ves cómo otras personas resuelven los mismos problemas que tú, y conoces gente que después se convierte en tu red. Esa red te abre puertas que un CV nunca te va a abrir. Recomendaciones, oportunidades de trabajo, mentores, amigos que la pasaron mal con el mismo bug que tú.
¿Pero dónde encuentro comunidades? Una opción es AWS Builder Center. Ahí encuentras grupos de usuarios por ciudad, student builder groups que son comunidades lideradas por estudiantes, y eventos donde puedes ir a aprender o presentar.
No tienes que llegar a hablar en un meetup el primer día. Empieza yendo a escuchar. Después haz una pregunta. Después platica con alguien al final del evento. Y un día te das cuenta de que ya conoces a varias personas y aprendiste cosas que ni en el trabajo ni en cursos ibas a aprender.
Acción: entra a AWS Builder Center, busca un grupo en tu ciudad o un student builder group, y anótate al próximo evento. Solo ir ya cuenta.
Cierre
Si tuviera que resumir todo en una idea, sería esta. Ser un buen JR no es saber más que los demás. Es leer código con paciencia, hablar con la gente, escribir lo que aprendes y llevar cuenta de lo que haces.
Lo demás llega con el tiempo.
Cada punto de este artículo tiene una acción concreta. No tienes que hacer las diez esta semana. Elige una, aplícala, y cuando ya sea hábito agrega otra. Si me preguntas por dónde empezar, empieza por el registro de contribuciones. Es el de menor fricción y el que más rendimiento te va a dar a largo plazo.
¿Cuál de estos puntos te resuena más? ¿O hay algo que tú hayas aprendido en tu primer trabajo que no está aquí? Déjamelo en los comentarios, me interesa leerlo.
Y si quieres seguir la conversación, me encuentras en Instagram como @fromchiapasdev.
