Mis 10 Lecciones de 10 años en Tech
Es interesante como la perspectiva y opiniones en tecnología cambian demasiado rápido, al igual que ella.
En TI pasamos de decir que eras un honorable y orgulloso webmaster a la ahora conocida posición de DevOps, o incluso se habla de posiciones de Data Engineer, Backend Developer o incluso Cloud Engineer, todas posiciones — entre una larga lista — que durante los últimos años han sido creadas para especificar un rol en la industria.
Esto es solo parte de la pequeña retrospección que hice cuando hace algunas semanas me dí cuenta de que cumplía 10 años profesionalmente en el ámbito de tecnología y me dí cuenta de como he ido cambiando de opiniones, de techstacks, de intereses, de toolsets y de visión, a lo largo de estos 10 años.
Dejo estos escritos por si a alguien le sirven, pero más que nada, por si en 10 años los leo y digo “vaya, realmente no sabía nada de tech”.
1. Evoluciona o muere
La parte más sencilla y más fácil de entender de tech y que contínuamente escucharás afuera es que evoluciones, pero a mi forma de ver esto se puede convertir en la tarea más difícil de realizar.
Estar en tecnología es entender que estarás en un proceso de constante evolución y aprendizaje para poder mantenerte relevante ante una ola, o mejor dicho, un tsunami de tecnologías que vendrán.
¿Aprendiste Node.js 14? Perfecto, ahora agárrate porque ya viene la versión 16… Ah, ¿lo hiciste sin Typescript? Hora de introducirlo en tu proyecto… pero ¿cómo? ¿Deployeaste tu proyecto con Heroku? Estamos utilizando AWS ya… ¿Cómo que tienes tus pruebas unitarias en Jasmine? Todo el equipo ya está utilizando Cypress…
Esta será tu carrera independientemente del techstack que utilizes, de la especialización que busques y yo ya entendí que nunca existirá el tiempo suficiente para aprender todo, que la tecnología y todo a lo relacionado a ella avanza mucho más rápido que mi interés y disponibilidad de aprender y que mantenerme con un plan dentro de lo que parece un tsunami, suena fácil, pero no lo es… así que lo mejor de todo es enforcarse en qué quieres lograr en tu carrera en tech y nadar lo más hábilmente que se puede en este caos.
2. Sin plan de carrera (o de vida) la vida te arrastrará
Ya lo dije, en tech es tan fácil que te arrastre como un vil tsunami arrastra una varita de madera pero si a esto le añades otro elemento: la vida, se hace una combinación peligrosa.
Es muy fácil dejar que la vida te ofrezca las oportunidades laborales, sobre todo en esta industria donde el talento es escaso podrá llegar un punto donde tu inbox puede estar recibiendo invitaciones a entrar en un proceso de reclutamiento.
Pero la pregunta del millón para mi no es si puedo encontrar un trabajo, sino ¿es lo que quiero? ¿es la cultura de la compañía lo que busco? ¿qué lograré profesionalmente al unirme a esta compañía? ¿será equitativo lo que ellos buscan de mi y ofrecen vs lo que yo ofrezco y el valor que agrego?
Entiendo que a lo mejor para aquellos y aquellas empezando su carrera, puede que no se relacionen del todo con estas preguntas o situación y que podría no ser su prioridad cuando lo único que te urge es experiencia y un poco de dinero extra para afrentar los gastos del día a día, lo entiendo totalmente porque yo estuve ahí.
Sin embargo, si sigues expandiendo tu conocimiento y evolucionando (punto #1) y enfocándote en desarrollarte a ti mismo, en algún momento tendrás suficiente experiencia para poder empezar a tomar tus propias opciones laborales y empezar a preguntarte que estás buscando, y las preguntas que listo arriba me ayudan a saber que decisiones tomar (o que preguntas hacer para la compañía).
Siento que a veces los reclutadores siguen pensando que todos estamos solamente esperando que llegue un reclutador salvador para que podamos cambiar de trabajo, y pues… no, realmente no. Cuando eres el reclutador #18 que se acerca en un solo mes debes de darte cuenta que un ofrecimiento para trabajar en una empresa ya lo veo como algo normal.
Por otro lado, si solo sigo aceptando y considerando las opciones que avientan los reclutadores a mi inbox de LinkedIn, entonces estoy dejando que los reclutadores dicten mi siguiente paso en mi carrera profesional en vez de yo preocuparme de mis propios pasos y crear mis propios logros profesionales.
Aquí es cuando un plan de carrera te ayuda a saber si estás haciendo lo que realmente pensabas que querías hacer y a donde estabas buscando llegar (y claro, ten encuenta que este evoluciona conforme tu avanzas y es perfectamente normal que algo que creías querer, al tenerlo no es lo que pensabas que querías).
3. Nunca tendrás tiempo suficiente
Otro de los errores de mi carrera técnica fue el posponer aprendizaje, desarrollos y productos propios pues seguía con la idea de que en algún momento llegaría el tiempo suficiente y en el momento indicado para poder sentarme con calma a crear mi producto deseado o incluso tomar ese curso de una tecnología con la calma del mundo…
La realidad es de que uno termina viendo como avanza el calendario sin que llegue ese momento perfecto, por ende es siempre mil veces mejor tener algo, malecho, con bugs, mal diseñado, o un curso tomado a la mitad, que simplemente no hacer nada.
En esto caso yo soy un fan del motto: mejor avengorzarse por lo que creaste, tal cual lo dice Reid Hoffman:
Por ende, si estás pensando en especializarte en alguna tecnología, tomar un curso o lanzar un producto, la mejor manera de hacerlo — para mí — es ponerle fecha y hora en tu calendario y empezar con lo que se pueda hacer dentro de un set de tiempo específico… Trabaja bajo timeboxing y logra lo que puedas, y como en un sprint: itera y ve mejorándolo, y claro, ten una meta específica de qué quieres lograr con este tiempo dedicado.
4. Ninguna tecnología es para siempre, no te cases con ninguna
Uno de los errores más garrafales de esta industria son las discusiones sin sentido de si un lenguaje de programación es mejor que el otro o si una tecnología es mejor que la otra. Las he visto por +10 años (algunas con mejores insultos que otras) aunque creo que lo único que ha cambiado es que ahora incluyen más memes, porque los egos heridos sin sentido de devs siguen a la orden del día…
Existen lenguajes de programación que buscan solucionar cierto problemas, existen bases de datos que solucionan problemas en específico, algunos frameworks han evolucionado de su plan original, pero lo que si cierto es que como dev lo peor que puedes hacer es casarte con una tecnología o lenguaje de programación y venderlo siempre como la solución adecuada, peor aún, enfrascarte en una discusión con extraños sobre esto.
¿Necesitas analizar datos de una DB donde existen relaciones entre los datos y quieres meter MongoDB porque es tu DB favorita?
Error, para existen sinfín de bases de datos relacionales que te permitirán hacer esto fácilmente.
¿Estás creando un proyecto de machine learning y necesitarás de librerías específicas pero te sientes cómodo con PHP?
Yo escogería Python debido a sus librerías ya creadas y validadas por su misma comunidad para propósitos de ML.
¿Crees que Javascript estará por siempre porque no ha habido ningún lenguaje parecido? Tal vez, pero en mis tiempos todo el rage y mejores empleos eran por aquellos que sabían Actionscript para Flash y los que sabían Java… Y pues ya sé en qué termino la historia del primero y el mercado se ha reducido para los segundos.
La mejor manera de ver esto no es ¿cómo me siento más cómodo? sino
¿cómo puedo lograr un mejor resultado para este proyecto *en específico* por medio de la tecnología?
Lo difícil de esto es que la respuesta a esta pregunta la tienes que ir contestando, investigando y evolucionando constantemente a lo largo de de tu carrera profesional.
5. Peer programming es una poderosa herramienta para aprender
El peer programming es una de las herramientas más importantes que veo a la hora de mejorar tus habilidades de programación y que al principio de mi carrera profesional desdeñé, pensando que era una “invasión de la privacidad”… Qué equivocado estaba…
El sentarte con un co-worker y hablar del problema así como de la solución técnica te permite no solo el poder exponer tus ideas técnicas y de solución de problemas (donde puedes caer en el el famoso caso del “rubber duck debugging”).
Pero no solo esto, sino que el sentarte con alguien más te permite aprender de sus workflows, línea de pensamiento para solucionar problemas, shortcuts, líneas de comandos, setups de IDEs, apps, etc., donde no faltará el “¡ah!, esa no me la sabía, ¿cómo lo hiciste?”.
Hoy en día, para mi el hablar del peer programming no equivale en hacerlo con alguien con más seniority que tu, aprovecha el peer programming independientemente del rol pues puedes aprender de todos.
Es algo que yo hago y del cual he aprendido bastante.
6. Puedes seguir siendo técnico, sin volverte manager
Una de las ideas equivocadas que tenía y creía al principio de mi carrera como dev es que la evolución de esta posición es dar el paso hacia una posición de management, y seguir por ahí en una escalera vertical de promociones donde el código quedaría muy lejos del día a día… esto era lo que había en mi época y sigue siendo vigente en algunos lados, pero no es la realidad.
Puedes seguir trabajando como dev por más años, claro, a lo mejor las limitantes de sueldo existirán en algún momento de, digamos, ser Software Engineer por 45 años seguidos, pero estas son decisiones que en tecnología podemos tomar.
Puedes hacer una carrera como dev, directamente en los fierros sin necesidad de convertirte un manager que está aprobando vacaciones de su equipo, contestando correos de head count y estar al día del PTO del equipo, tech nos da esta oportunidad y mejor aún, puedes brincar entre los dos conforme tu carrera avanza y tus intereses se incrementan o minimizan.
Así como no te recomiendo que te cases con una tecnología en específico, no te cases con una posición, mejor aún, explora y ve hacia donde quieres dirigir tu carrera, existen buenas sorpresas en el camino.
E incluso, está bien que te des cuenta que no era lo que querias; conozco ya varios casos de managers que decidieron volver al código e incluso personas sumergidas en código que llegaron a su sueño de ser managers… O claro, la indiscutible mezcla de posiciónes de managers técnicos.
La realidad es que en esta industria hay espacio para todos estos intereses y carreras profesionales.
7. Dentro de un equipo, el punto no es ser el más rápido, ni el que más algoritmos sabe, sino el que aporta mayor valor
Lo he dicho en múltiples ocasiones a conocidos: el que codea más rápido no lo considero el mejor dev, sino el que soluciona la mayor cantidad de problemas dentro de un proyecto y que aporta valor a él (osease, el término algo alusivo de aportar business value).
Es muy común que en esta época pensemos que el que codeó todos los ejercicios en HackerRank será el mejor dev para un equipo, esto no es necesariamente cierto pues esto solo prueba que es alguien capaz de resolver un problema de lógica con código y no todos los problemas o retos dentro de un equipo de desarrollo son lógica.
Digo, a lo mejor soy yo y mi limitada experiencia, pero existe una diferencia entre mantener un sistema en producción, tomar desiciones arquitectónicas escalables, tomar desiciones´on-the-fly´ cuando se cae producción, o incluso ser capaz de auto-organizarse así como de organizar y priorizar al equipo, y lo que viene siendo solucionar el problema del reloj de arena.
La posición de un dev es camaleónica y debes de estár cómodo con esto: si no es un lenguaje nuevo de programación, es un nuevo equipo de trabajo con una metodología ágil con la cual no habías trabajado, o es un nuevo proyecto con estándares para los entregables diferentes y/o más altos.
Tu labor es poder adaptarte rápidamente a estos cambios y donde la incognita principal para mi sería:
¿y ante este ambiente nuevo y constantemente cambiante, como puedo aportar más valor desde mi posición?
8. Ninguna empresa de tech, ni ningún lenguaje de programación, ni ninguna comunidad se preocuparán por tu retiro
Sé que no es exclusivo de tech sino prácticamente del estado y evolución de la economía mundial, pero algo que he aprendido en estos 10 años es que tu eres la única persona responsable de tu retiro.
En un ambiente donde más de 5 años en la misma empresa hace dudar a reclutadores de porqué duraste tanto tiempo en el mismo lugar, es obvio que una empresa que te ofrezca planes de retiro a +30 años no es rara, sino prácticamente muy difícil de encontrar…
Lo más probable es que a ninguna empresa le interese esto y está bien; los tiempos han evolucionado y todos tenemos que entender esto, pero es por esto que también tienes tú que entender este aspecto:
Tu primer empresa de tech donde laboraste no estará 50 años después para tí, o, esa tecnología en la cual te especializaste a los 30 años probablemente no estará cuando tengas 60, peor aún, no todos tendremos la suerte de Jeff Barr y a los 60 años estar lidereando una de las compañías que ofrecen tecnología de punta…
La realidad es que si no te mantuviste relevante probablemente no serás valuado para una posición en tech, o, ¿tendrás las habilidades para ser manager? Existen muchas incógnitas acerca de como evolucionarán en tech los miles de devs que actualmente están en sus 20s y 30s, pero yo digo que si buscas algo más no lo estés dejando al futuro…
Al día de hoy existen oportunidades que puedes empezar a explorar según tu conocimiento y capacidad:
- Aprender y ejecutar inversiones
- Tenemos las habilidades de poder crear cosas, crea y experimenta con negocios digitales
- Crear negocios aparte (incluso si no son de tech)
- Crear tu propio negocio en tech
No estoy diciendo que tech te correrá en 30 años a partir de hoy o que no habrá trabajo, sino que lo que he visto es que nadie más que yo, se va a preocupar del yo del futuro, así que más vale que yo haga algo para que yo esté más tranquilo en unas décadas más.
9. Especialízate, Evoluciónalo, e Itera
Recuerdo bastante la primera vez que entendí que un sistema operativo tenía flavors y por ende el comando de apt install no iba a funcionar en un servidor con CentOS, pues en mi educación en ningún momento se dignaron de explicar esto (bendita educación pública mexicana) y mi experiencia técnica en servidores era nula…
El detalle es que a lo largo de los años traté de ser un desarrollador full-stack, pensando que esa sería mi camino de carrera profesional, pero tiempo después mi interés fue evolucionando hacía el backend y el management, ambas cosas las disfruto, pero si me preguntas ahorita, ya prefiero más el backend con tintes de DevOps y estar lidereando equipos técnicamente…
Este interés obviamente ha ido evolucionando (porque para empezar no existía el concepto de DevOps cuando inicié mi carrera), pero lo importante es que cada pequeña parte técnica que tocaba, trataba de aprender más.
¿Hoy tuve la oportunidad de aprender NodeJS? ¿Cómo puedo saber si estoy utilizandolo bien? ¿Cómo puedo mejorar lo que tengo? ¿Qué eventos en mi área hay donde pueda conocer otros puntos de vista?
Busca como obtener retroalimentación e información adicional de las tecnologías que usas en tu día a día y a su vez haz un esfuerzo por conocerlas más fuera de tu “trabajo normal”.
10. Benchmarkeate e Invierte en Ti Mismo
Uno de los puntos que creo que hace que uno evolucione como persona, dev, profesional, o prácticamente, lo que quieras, es benchmarkearte. He conocido una gran cantidad de devs que hablan de OKRs, KPIs, SLAs, pero que huyen de la idea de aplicarlas a uno mismo…
¿Buscar bajar de peso? Tu KPI es tu BMI…
¿Buscar aprender de AWS? Tu Key Result 1 podría ser certificarte.
¿Buscar aprender Python? Tu SLA son 3 horas a la semana de codear con Python.
Estos son solo ejemplos de como usar métodos y/o metodologías que usamos en nuestro día a día como devs, que pueden impulsarnos a ser mejores en lo que hacemos o en la vida diaria.
Pero uno de los errores que cometí en mi carrera fue el no invertir tempranamente en herramientas, eventos, cursos, etc., que me permitieran hacer mejor y más rápido mi trabajo o tomar puntos de vista adicionales. Ahora veo que todo cuenta, pues esto es como una carrera de maratonistas profesionales; donde los lentes, los tenis, el material de la camisa y la longitud del short, cuentan.
Todo lo que inviertas para mejorar o hacer tu trabajo más fácilmente o más rápidamente, servirá. No esperes a que las compañías te hagan crecer, te entrenen o te paguen boletos de eventos, esta disposición a invertir en ti mismo tiene que nacer de tí, porque tu eres el que te beneficiarás más en este maratón.
El Pilón: Existen mercados y demandas locales, y por industria, no todo es Tech de Silicon Valley
En una conferencia me tocó escuchar de como una plataforma de producción en China manejaba más de 500 millones de peticiones — por día — , la plataforma estaba hecha en PHP y con el framework de Swoole, un framework que al momento ni siquiera estaba listo para su uso en producción.
Claro, China no es Silicon Valley, pero por otro lado, mencioné en una entrevista con Yesi Days que en mi tiempos de trabajar en Europa manejabamos una tienda de e-commerce con 300 millones de usuarios, y usabamos PHP.
Pero si yo decidiera seguir codeando con PHP y me mudo a Silicon Valley, mis ofertas serán mucho más escasas que si me voy por ejemplo, con RoR o Python. Por otro lado, si mi interés fuera crear videojuegos AAA tendría que estar enfocado en C++ o Unreal/Unity, por lo cual mis habilidades en Ruby, por más buenas que sean, me dejarían con opciones bastantes limitadas en esa industria.
Lo que quiero decir es que que conforme avances en tu carrera entenderás que existen mercados específicos, muchas veces regionales y donde también tienen que ver las industrias y/o compañías en las que quieras participar.
Esto es relevante porque si buscas especializar tu carrera en un tema o una industria o aplicar a una compañía en específico, existen desiciones que tendrás que tomar que permitirán acercarte con un mejor perfil.
Pero claro, como lo he venido decidiendo: todo en tecnología evoluciona, así que es tu trabajo el mantenerte informado, investigar y tratar de entender las tendencias.
Conclusión
No sé si esta entrada servirá para algún lector que está perdido con su carrera en tecnología o será de utilidad para un estudiante que busca apenas entrar a ella, pero para mí es un poco recordar y reflexionar las cosas que he aprendido.
Pero si te sirvió la nota (o no) déjame un comentario, me encantaría saber si de algo pudo servir.
Foto de portada por Ryan Graybill en Unsplash
