Planear tu carrera

¿Para dónde apuntar?

Conozco personas bien preocupadas de su “plan de carrera”. También conozco otros que no. Que no ven necesario proyectar años para adelante, o que no se sienten capaces de hacerlo.

Yo tiendo más al segundo grupo. Si me dicen “Donde estarás en 5 años más” respondo “No sé”. Como que lo voy viendo en el camino, más orgánicamente.

Suena raro entonces que esté escribiendo sobre tips para escoger un camino profesional hacia dónde apuntar. Mi tip es que descubrí que el tema de fondo no es si planificas más adelantado o más “en el camino”. Sea cual sea tu estilo, uno termina con el mismo dilema: Elegir en qué meterte y de qué aprender. Aunque te guíes por tu interés/curiosidad, tarde o temprano el tiempo disponible será una restricción. Y habrá que elegir.

Los que planifican más su carrera tienen la ventaja de hacer el simulacro-de-elegir, antes de elegir. Eso también los hace menos vulnerables al problema de nunca-elegir (que espero abordar en otra entrega).

Ahora, elegir en qué prepararte es una apuesta. No hay cómo estar seguro que va a funcionar. Necesitas una cuota de suerte para que funcione. Uno de mis héroes tiene una muy buena frase al respecto:

“La suerte es cuando la preparación se encuentra con la oportunidad”

— Randy Pausch

La pega de uno es prepararse para cosas con chances de encontrarse con oportunidades geniales. No todas las “oportunidades” van a ser igual de geniales.

Para traer esto a la práctica, aterricemos las “oportunidades” al mercado laboral (en futuras entregas romperemos ese paradigma).

Allí, mientras más útiles sean tus habilidades y conocimientos, mejor. La ciencia ficción quizás es poco útil en tu mercado laboral. Diseñar experiencias para apps móviles es probablemente útil.

También mientras más raras sean tus habilidades y conocimientos, mejor. Hace una década programar en Python no era tan común, pero tampoco taaan raro. Sin embargo…

---

Este es un buen momento para contarles una historia personal 😅 .

Hace mucho tiempo atrás me pagaron por escribir (parte de) un libro técnico. En inglés. Y yo no sabía mucho inglés.

¿Cómo pasó eso?

Dí una charla en inglés en una conferencia sobre Python en Chicago (quizás lo recuerden en mi historia personal sobre fallar) y tuve la buena idea de quedarme a socializar post evento a pesar de estar exhausto. En realidad me quedé a tomar algo mientras la gente conversaba alrededor y con algo de suerte conseguía entender algo (mi inglés era pobre, especialmente hablado). A veces decía algo cuando creía que entendía.

“Capaz que esta sea la última vez que entiendo lo que dicen suficientemente a tiempo como para meter la cuchara, así que diré algo aunque sea una tontera”, era mi lema ese día. Probablemente influido por el alcohol. Eventualmente terminamos en una mesa con otros charlistas. Ahí en esa mesa un representante de Apress nos pidió escribir un libro. Dije que sí, obvio (metiendo la cuchara, aunque fuera una tontera).

¿Cómo pasó eso?

Un año y medio antes programamos algo en Python junto con el dev part-time del equipo de casi-puros-diseñadores (que les conté en la historia personal sobre aprender-a-aprender). En esa historia el cliente quería despedirnos. Entre las cagadas que explican eso es que al actualizar las promociones y descuentos de la página de este banco a veces alguien de nuestro equipo copiaba o pegaba mal los datos y el % de descuento quedaba mayor. O la fecha de término de la promoción fallaba. Era info que se copiaba/pegaba dentro de un CMS desde un excel que nos enviaban. No culpo a quien metía mal los dedos, el proceso era una locura.

Como buenos ingenieros automatizamos la solución. Automatizamos es mucha gente, en realidad Pablo (el desarrollador part-time) hizo todo o casi todo. El CMS era un desastre así que nuestro programa era un “robot” escrito en Python que copiaba/pegaba (sin errores, rápido y sin aburrirse) las cosas desde la planilla que nos mandaban detectando las diferencias con la planilla anterior. Lo hicimos en Python porque era una herramienta interna y a los dos devs nos gustaba. Usamos Django (principalmente el admin) como framework web. Se acabaron los errores en las promociones del banco. O mejor dicho, todos los errores que llegaban eran traceables a errores en la planilla original que nos mandaban.

Hasta que se nos ocurrió decir que nuestros errores bajaron a 0 porque hicimos este programita y nos cayó la política oficial del banco: la herramienta debía ejecutarse en servidores oficiales. En un cluster, redundante y con toda la parafernalia. Obviamente fue una historia de terror donde primero no sabían como armar un ambiente Python y luego de casi 9 meses resultó que lo hicieron bien en una máquina del cluster pero mal en la otra (igual sospecho que no éramos precisamente prioridad).

Eso me dio tiempo para pegarme una volada. Como en este banco sí sabían armar ambientes Java y yo conocía Jython me dije: Hagamos funcionar nuestra aplicación allá. No funcionó. Pero con una mezcla de ingenuidad, ingenio, experiencia en opensource y experiencia en sistemas legados me armé de debuggers y paciencia para entender por qué no funcionaba. Arreglé lo que parecía arreglable (tanto en Jython como en Django) y empecé a mandar “parches” (hoy serían “pull requests”). Me aceptaron algunos y sugirieron mejoras en otros.

Parece que los aportes al final eran buenos porque me sugirieron postular al Google Summer of Code donde si eres estudiante (y yo en vespertino sacaba mi ingeniería) Google te puede pagar por dedicarle tiempo al opensource. Postulé y quedé.

Y un día mientras avanzaba en mi proyecto de que Django funcionara sobre plataforma Java, me escribió mi mentor/guía del proyecto contándome que estábamos invitados a una conferencia en Mountain View (¡en Google!) para hablar de nuestra volada.

Esa charla salió remal (por mi lado) porque mi inglés hablado era malo. Pero postulamos con el mismo tema a otra conferencia en Chicago y ahí me propuse pasar menos vergüenza. Ensayé incontables veces la presentación y salió rebien. Estaba tan contento del resultado que a pesar de lo agotado que estaba decidí quedarme a socializar. O a beber mientras la gente conversaba a mi alrededor. Y ustedes ya saben lo que pasó.

---

Programar en Python no era demasiado raro hace 10 años. Pero eso más programar en Java + saber participar del open-source + tener nociones de compiladores/lenguajes/intérpretes era suficientemente raro. Suficientemente raro para que la suerte juntara mi preparación con oportunidades increíbles.

Ahí me cayó la teja de apuntar hacia habilidades y conocimientos que sean útiles y a la vez raros. Suena bonito pero el mercado no te lo hace fácil: Si demasiadas personas dicen “ajá, voy a aprender XYZ porque parece que será útil y raro”… se vuelve una profecía auto-incumplida (será útil pero no raro).

¿Cómo hacerlo entonces? Creo que hay dos caminos igual de válidos:

• La (hiper-)especialización. El más común, creo. Suele ir de la mano con tendencias de la industria. “Voy a especializarme en desarrollo de apps móviles” dijeron algunos hace años atrás y creo que les ha ido bien. Pero mientras mejor funciona, más gente se especializa. Así que los especialistas tienen que seguir especializándose. De ahí a veces se da el fenómeno de la hiper-especialización. Es un camino que funciona bien en cuanto a rareza, pero tienes que tener ojo sobre el tipo de empresa en que te gusta trabajar. La hiper-especialización suele ser más apreciada/usada en organizaciones gigantes. Un amigo hiper-especialista que trabajaba en una empresa de tecnología gigante en Sillicon Valley me contaba que era difícil quejarse (trabajar allá había sido su sueño), pero no le gustaba sentirse como un engranaje de una máquina enorme.

• La mezcla-rara. El más fácil, creo (Si más personas supieran que es más fácil, quizás sería más común). El truco: no necesitas que los ingredientes sean raros. Digamos que sabes programar (nada de raro) y te pones a aprender de growth marketing/hacking (camino a ser menos raro porque hoy hay hartos profesionales enfocándose en eso). Pero desarrolladores que sepan de growth es una mezcla rara. Diseñadores que programen (o viceversa) son una clásica mezcla que sigue siendo rara, compuesta por ingredientes nada de raros. Este camino casi por definición funciona bien en rareza, así que todo depende de que tan útil resulta la mezcla.

Ahora van mis tips:

Cuando estás comenzando no veo necesario escoger un camino. Uno no sabe mucho de casi nada, por lo que es una etapa para descubrir lo que sea que más te entusiasme y donde tienes más “dedos pal piano” (o “match quality”, como le dicen los científicos que estudian esa parte del puzzle).

Después de algunos años ya sabrás por donde va la cosa. A menos que hayas cometido el error de sólo aprender cosas muy parecidas. En tal caso te recomiendo aprender un par de cosas “raras” antes de caer en una especialización precoz de la que te costará salir después.

Si ya hiciste un buen “tour”, es hora de tomar un camino deliberado entre hacerte raro via especializarte o armar tu propia mezcla-rara. No es necesario que sepas exactamente hacia donde te llevará ese camino (dicen por ahí que los puntos se conectan mirando hacia atrás, no hacia adelante). Pero ojalá sea un camino donde veas una buena oportunidad de utilidad + rareza. Mejor aún si es un camino donde crees que podrás disfrutar lo que haces, lo que persigues y/o lo que consigues.

Elegido el camino, puedes usarlo para priorizar. Si tienes una lista de libros por leer o cursos que tomar o proyectos-propios que hacer, pon primero en la lista los que apuntan para el camino de especialización o mezcla-rara según elegiste.

Yo decidí irme por el camino de la mezcla-rara, a pesar que las señales de la historia que les conté sonaban a especialización. Otro día les contaré por qué escogí eso.

Igual de vez en cuando aprendo o profundizo cosas de desarrollo, para mantener vigente ese componente de mi mezcla rara. Quienes eligen la (hiper-)especialización también de vez en cuando tienen que aprender cosas “raras”. Por ejemplo, aprender sobre cómo se toman las decisiones en tu organización es una de las que más recomiendo.