#2 - 6 estrategias que aceleraron mi carrera como ingeniero de software
Las decisiones que más impacto tuvieron en mi desarrollo como ingeniero.
En esta entrega te cuento las 6 estrategias que más aceleraron mi carrera como ingeniero de software, y de cómo me ayudaron a pasar de sufrir en empresas locales a poder trabajar para empresas americanas y llegar a senior.
1. Proyectos personales desde el primer día
Nunca fui una eminencia en los estudios. Siempre me costó muchísimo concentrarme en clase y estudiar para los exámenes (lo cual se veía reflejado en mis notas xD)
Me metí en Ingeniería Informática por una simple razón: Me gustaban los ordenadores y solucionar problemas. Y una de las mejores cosas de esta carrera es que puedes crear lo que quieras casi desde el primer día, a diferencia de otras ingenierías clásicas o carreras de ciencias. Sólo necesitas un portátil y ganas.
Y algo que me sorpende, es que muy poca gente toma ventaja de esto. No es criticable, pero es algo que marca la diferencia. En mi caso, siempre estuve liado en algún side project. Por ejemplo:
Juego que llegó a 100k descargas en Android. Lo creé en Navidad en segundo año de carrera, en lugar de estudiar para los exámenes de enero xD.
Web de noticias de NFL.
Incubadora de huevos con Raspberry Pi.
Mis cursos de Udemy.
Y el más reciente, Deep Focus, la app para bloquear distracciones.
Y muchos más!
La mayoría de estos proyectos no me hicieron ganar ni un sólo euro. Pero sí me ayudaron a crecer, y no sólo técnicamente. Te obligan a pensar en una visión, planificación, implementación end to end e incluso algo de marketing si quieres llevarlo un poco más allá.
Y además, en entrevistas de trabajo siempre me preguntan por alguno de ellos. En Salesforce, por ejemplo, un antiguo compañero se descargó mi juego de fútbol y lo estuvo probando antes de entrevistarme.
2. Generalista primero, especialista después
Mucha gente se enfoca en especializarse lo antes posible, pensando que eso les ayudará a crecer rápido y ganar más. En mi opinión, esto es un error cuando estás empezando.
Si te especializas demasiado pronto, pierdes la oportunidad de ver el resto del stack, de descubrir qué te gusta realmente y de mejorar técnicamente en otras partes del desarrollo. Además te encasillará para futuras ofertas laborales.
Ejemplos típicos son los desarrolladores de una única plataforma (Android / iOS), quienes sólo trabajan en una única parte del stack (frontend, backend, QA...), o el caso extremo, gente que sólo quiere trabajar con un lenguaje o framework concreto.
Un generalista puede aportar valor en muchas áreas diferentes, mientras que un especialista sólo en una. Seguramente el especialista rinda mejor en su nicho, pero el generalista tiene más flexibilidad, entiende mejor el sistema completo y puede desbloquear más frentes.
La clave es llegar a ser un buen Ingeniero T-shaped. Alguien capaz de aportar en varias áreas, pero con profundidad en una concreta.
Esto lleva años, y es mucho más difícil llegar ahí si te especializas demasiado pronto.
3. Mentalidad de producto
En mis primeros años de carrera solo pensaba en ejecutar. Me centraba en escribir buen código que cumpliera los requisitos que me pedían mis superiores. No entendía, ni me interesaba el producto en sí, y eso frenó muchísimo mi crecimiento.
Era muy bueno generando output, pero no tanto generando outcomes.
Entender a fondo el producto que estás desarrollando es clave para tomar decisiones técnicas. A veces lo vemos como un problema de Product Managers, pero no lo es. Muchos problemas que parecen puramente técnicos, se resuelven mucho mejor si entiendes qué intenta conseguir el usuario y para qué existe esa funcionalidad.
Un desarrollador con mentalidad de producto:
Entiende el producto a fondo y lo usa si puede.
Conoce a los usuarios y por qué lo usan.
Sabe que lo que genera dinero es el producto, no el código.
Tiene criterio para decidir qué aporta y qué no.
Valida ideas con pruebas de concepto antes de querer implementar media plataforma.
Con esta mentalidad puedes aportar valor más allá del código, lo que mejorará la comunicación con PMs y el equipo de diseño, y te dará mejores oportunidades laborales. Te percibirán como un ingeniero más completo, no como alguien técnico que recibe Jiras y los cierra.
El primer punto que traté también ayuda con esto. Al crear un side project estás obligado a pensar en tus usuarios y en cómo evolucionar tu producto para que tenga más oportunidades de éxito.
Por ejemplo, en Deep Focus tengo un pequeño bug con el modo pomodoro en usuarios Pro. Mi instinto como desarrollador es ponerme a investigarlo y solucionarlo ya mismo. Pero viendo los datos, sólo el 10% de los usuarios es Pro, y sólo una fracción utiliza la funcionalidad que tiene el problema. Con mi tiempo limitado, sé que arreglar el bug aporta mucho menos que otras mejoras que afectan a todos los usuarios.
4. Preparar entrevistas técnicas
Este es un punto polémico que ya he tratado muchas veces en Twitter. Mucha gente ve preparar entrevistas como “perder el tiempo”. Y en parte lo entiendo: las pruebas de Live Coding son estresantes, algo repetitivas y no representan del todo el trabajo real.
Aun así, creo que demonizarlas es un error. La realidad es que la mayoría de empresas extranjeras (y sobre todo las que mejor pagan y mejor talento tienen) siguen usándolas.
Invertir en ello me dio muchas ventajas:
Fortalecer mis fundamentos en algoritmos y estructuras de datos.
Entrar en Salesforce, multiplicando x5 mi sueldo en 1 año, y tres años más tarde conseguir trabajo full remote en MongoDB.
Tener “acceso” a una densidad de talento muy alta. Al haber tanta competencia por entrar, todos los compañeros eran muy buenos, y aprendí un montón.
Mejorar mi comunicación y mi tolerancia a la presión.
Es cierto que no fue un camino de rosas. Muchos meses invirtiendo 2-4 horas al día después del trabajo, y más horas aún durante los fines de semana. Pero ha sido sin lugar a dudas la decisión que más impacto ha tenido en toda mi vida, y no sólo a nivel profesional.
Finalmente, desde un punto de vista puramente técnico, prepararme para entrevistas técnicas mejoró mis fundamentos, tanto de algoritmos y estructuras de datos como de diseño de sistemas. Y, al menos en mi caso, eso me ha ayudado muchísimo en mi día a día como ingeniero.
5. Dar la milla extra de forma estratégica
En mi primera empresa, hacer horas extras era lo normal. Había una cierta presión social por demostrar que “tenías puesta la camiseta”. Y lo peor es que muchos ni siquiera estaban trabajando, sólo “esperando” a que el resto se levantase para irse.
El extremo contrario también me parece negativo. Negarse siempre a dar un minuto más de tu tiempo, incluso cuando tu equipo está en problemas.
La estrategia que siempre me funcionó es la de “dar la milla extra” cuando tiene sentido, cuando hay un beneficio real por hacerlo.
Por ejemplo, al entrar en un nuevo equipo. Las primeras impresiones pesan mucho y un esfuerzo extra al principio te da “crédito” para el futuro.
Otro ejemplo es cuando tu equipo, o un compañero, tiene problemas. Ofrecer tu ayuda para salir de una crisis tiene un gran impacto en tu imagen dentro del equipo.
Esos esfuerzos puntuales valen mucho más que hacer horas extra por hacer, sin un propósito claro. Encontrar ese equilibrio es difícil, pero marca una diferencia enorme.
Gracias a esto, siempre se me ha visto como un jugador de equipo, resolutivo y fiable. Y mis managers siempre han respondido ofreciéndome mucha autonomía y flexibilidad para trabajar como a mí me gusta.
6. No tener miedo a salir de la zona de confort
Esto es muy cliché, lo sé xD. Pero realmente ha sido un punto en el que siempre me he esforzado, y que me ha dado grandes resultados.
Siempre he sido un chaval tímido. Cosas como hablar con desconocidos, presentar en público, o viajar sólo me daban pánico. Por eso me obligué a enfrentarme a esas situaciones: me fui de “mini erasmus” al acabar la carrera, me apunté a actividades donde tenía que hablar en público y salí más de fiesta para hablar con desconocidos (a ver qué otro creador de contenido te recomienda eso xD). Poco a poco, dejé de ver estas cosas como algo imposible.
Con las entrevistas me pasaba igual. Me ponían nervioso, y en inglés todavía más. Para mejorar, hice decenas de entrevistas con empresas que ni me interesaban, sólo para practicar.
Intento mantener siempre esa mentalidad: recibir el cambio con los brazos abiertos y adaptarme rápido. En nuestro sector y en la vida en general, la pregunta no es si algo te va a incomodar, sino cuándo. Cuanto más entrenado estés para enfrentarte a ello, menos sufrirás cuando llegue el momento en el que de verdad importe.
Para terminar
Yo no soy ningún prodigio. Empecé como cualquiera, cobrando poco, sin contactos y sin tener mucha idea de informática. Pero estas 6 estrategias me llevaron a donde estoy hoy.
Ojalá alguna de ellas te ayude a avanzar un poco más rápido. Y si te apetece, cuéntame qué puntos han marcado más tu carrera. Me encantará leerte!
Buenas Daniel! Eres una inspiración para mí, y este año me pondré a estudiar entrevistas técnicas en profundidad. (He comprado ese curso tuyo, entre otros). Y coincido contigo, siendo un junior tengo todos los días una necesidad constante de profundizar en stacks y ser más ágil, pero de hace dos meses para aquí he tomado más actitud de esponja y a aprender conceptos mucho más allá del software. Al principio solo te enseñan que backend, frontend y despliegue pero el mundo del desarrollo de software es tremendo!
Un abrazo, mucho apoyo con el substack
Gracias por el post, recientemente he estado viendo como mejorar y crecer como ingeniero, aunque no he tenido la oportunidad de trabajar fuera de mi zona de confort, recientemente empezar a hacer side projects para mejorar en las skills que considero importantes para el futuro.
Harías un post de como creciste profesionalmente y las skills en la que te enfocaste para tener tu primer trabajo?