Una retrospectiva de mi carrera como Junior

María Castro
10 min readAug 3, 2018

--

Foto por @akshar_dave que me pareció bonita

Luego de un par de años dedicada al desarrollo web, formando parte de empresas pequeñas en Venezuela y Chile, voy a dejar mi puesto de trabajo como desarrolladora Junior para ingresar como Semi Senior en Globant, una compañía de software con más de 6000 empleados.

Es una etapa nueva en muchos sentidos: seguramente me encontraré con diferentes dinámicas de equipo, trataré con proyectos más grandes, y otras expectativas de mi desempeño. Un poco abrumador, si les soy sincera.

En estos días he hecho un repaso mental de todos mis años trabajando en desarrollo web, y quiero intentar resumir las lecciones que he sacado durante este tiempo que no solo me han hecho mejor profesional, sino mejor persona en general. Así puedo recordarme a mi misma lo mucho que he avanzado cuando el síndrome del impostor venga de visita y cuando olvide alguna de estas bases sea fácil refrescar la memoria. A veces hay que revisitar lecciones.

Pero antes de empezar, creo que toca hacer el SUPER DISCLAIMER. Todo lo que expreso acá es en base a mi experiencia y ni más ni menos válido que las de otras personas que hayan pasado por situaciones diferentes. Lo que si puedo decir es que esto es mi realidad y si siento que contando mi historia puedo ayudar a alguien a sentirse cómodo y valioso en nuestra área, pues, el propósito de escribir esto ha sido cumplido.

El código no es lo más importante

Esta es la única sección donde voy a mencionar código directamente. Y es para decir que cada vez me convenzo más de que se le da mucha importancia a lo que escribimos en nuestro IDEs.

Actualmente estoy involucrada en la comunidad JavaScript de mi ciudad, y es muy fácil entre grupos dejarse llevar por discusiones sobre qué framework o librería es la mejor, e incluso si vale la pena o no usar alguno de ellos. O peor, más de una vez tuve que escuchar comentarios sobre como los desarrolladores web somos de “menor categoría” comparado con alguien que programe en C++, Python, Ruby o Go.

Pero… la verdad es que el código va más allá sobre si es mejor usar un for o un forEach para recorrer un array. El código refleja procesos, visiones de empresa, e incluso sesgos del programador que lo escribe. Y no importa si mi código está 100% optimizado, o que use el mejor framework para performance si no es capaz de cumplir el propósito del producto estoy desarrollando.

Las veces que mi trabajo se hizo difícil no fue porque no sabía como hacer algo con X framework, o porque una función usó tres ciclos for en vez de uno. Esas son cosas que se pueden resolver en un día, o se puede buscar una solución alternativa. Los casos cuando se me ha hecho difícil hacer mi trabajo es cuando no sé exactamente qué tengo que hacer, cuando me bloqueaba y tenía miedo de preguntar a mis compañeros de equipo, o cuando en el equipo no se podían llegar a acuerdos porque nadie quería ceder su punto de vista en favor de otro.

Es muy común imaginarse al informático metido en su computadora como exitoso. El que le incomoda la gente o cree que es demasiado importante para hablar con ella. Pero la mayoría de los problemas del desarrollo de software vienen de fallos de comunicación, un equipo desordenado y falta de visión de lo que hacemos. Y lidiar con todos estos asuntos es cuestión de habilidades que están fuera de la computadora: saber comunicarnos con nuestro equipo y entre equipos, refinar nuestra inteligencia emocional y ser considerado con los demás.

Así que he dejado de obsesionarme por lo que esté in en el ecosistema de JavaScript a dedicar más tiempo a mejorar mis prácticas de programación, para que mis compañeros la tengan más fácil a la hora de leer y modificar mi código; a trabajar en mis prejuicios y mis limitaciones sociales para comunicarme mejor y compartir mis experiencias para recibir feedback y poder abrirme a otros puntos de vistas.

No es fácil para nada, y no todos pueden estar de acuerdo conmigo pero creo que es el camino correcto y siento que es lo que me ha hecho mejor desarrolladora.

Porque al final hacemos software para personas y con personas.

El cerebro “roto”

Una vez un compañero de trabajo conversando sobre salud mental me preguntó “¿Alguna vez has pensado en suicidarte?”.

Pregunta fuerte, ¿no?

Y me dio risa, no porque piense que el suicidio es gracioso, sino porque me ha pasado varias veces en mi vida y no es nada fácil de manejar.

Como la genial Sara Vieira dice en su charla “Your brain doesn’t have a fix flag”, para algunas personas funcionar normalmente les toma más esfuerzo que a otras. Y pueden pasar muchos años antes de estar consciente de esto, y muchos más para tomar los pasos activamente para lidiar con ello.

Desde que soy chica me ha tocado vivir con un cerebro “roto”: Muy sensible, y muy frágil para merecer cosas buenas de la gente, y de la vida. Llorando por cosas que muchos me decían que “no era para tanto”. No tener fuerzas para levantarme de la cama y mucho menos ser productiva. Evitando lugares y situaciones que me ocasionaban ataques de pánico. Conozco el tener un cerebro que atenta contra ti todos los días.

Y por estar rodeada en un entorno donde la salud mental era tabú, estuve enfrentándome a mis episodios de depresión por mi cuenta durante muchos años antes de empezar a recibir el tratamiento adecuado.

La María de ahora es muy diferente a la María de ese momento. Ahora vivo en otro país, soy independiente, y sigo yendo a terapia sin necesidad de medicación constante.

Sin embargo, aún tengo momentos malos. Me ha tocado tomar ansiolíticos para entrevistas. Una vez tuve un ataque de pánico durante una stand up. Y he visitado todos los baños de mis trabajos a llorar porque simplemente no podía seguir soportando el día. Aún a pesar de eso, soy capaz de entregar funcionalidades, tomar decisiones y hacer presentaciones frente a personas.

Pero nuestra área puede ser muy cruel a veces. Es muy normalizado el egocentrismo, el ser súper racional y no dejarse llevar por emociones (no como aquellas mujeres sensibles, ¿cierto?), trabajar muchas horas bajo presión y que prefieras estar detrás de una computadora programando que hablar con la gente.

Estuve mucho tiempo tratando de adecuarme a ese modelo de trabajo. Tratando de ser más agresiva, dejar los sentimientos y endurecerme. Y, ¿saben algo? Eso no debe ser lo normal. No necesito convertirme ni aparentar ser otra persona que no sea yo. Nadie tiene que navegar entre la falta de empatía y sacrificar su felicidad por cumplir un deadline.

Y más allá de si sufres o no alguna enfermedad mental, está bien poner límites. Eso no quiere decir que no eres profesional, todo lo contrario, porque estás consciente de lo que sientes y puedes hacer.

Quien no los entienda o te juzgue por ello, es el que tiene el problema, no tú. Recuerda, eres un ser humano, no una máquina. E incluso una máquina se descompone cuando se le obliga a funcionar más allá de sus límites.

Está bien no saber

En la pequeña escuela donde estudié no tuve casi amigos. Lo que más recuerdo son los años de rechazo que sufrí por muchos de mis compañeros debido a mi forma de vestir, de hablar, o las cosas que me gustaban.

Algo que escuché mucho durante esa época era cuando los profesores me felicitaban por mis buenas notas. Desde que era muy niña, tenía sembrada la idea de que era muy “inteligente”. Así que mis notas en la escuela eran el medio por el que me sentía reconocida de forma positiva: mi madre se enorgullecía de mi, los profesores me felicitaban, e incluso algunos compañeros me pedían ayuda para estudiar. En otras áreas era muy llorona, tímida, fea o de gustos extraños.

Y aunque mi época de universidad fue muchísimo más fácil a nivel social ya estaba convencida que lo único bueno que tenía en mí, era mi inteligencia. Que podía ser muy gratificante, pero también ha sido un obstáculo muy grande para funcionar normalmente.

El problema de definirte de forma tan limitada, es que es muy fácil derrumbarse cuando sientes que no estás encajando en esa descripción. ¡Y vaya que la informática me ha brindado muchas oportunidades para ello!

Cuando tenía dificultades para entender algo en el trabajo, me sentía el fracaso más grande del mundo. Porque no me sentía inteligente, y por ende, no quedaba nada positivo de mi.

A veces no era necesario tener un bloqueo programando. Me he dado cuenta que he olvidado muchas cosas básicas con los años. Y veía otra persona que si lo sabía y ¡bam! María se siente idiota de nuevo. Esto era capaz de parar mi productividad, e incluso me provocó un par de ataques de pánico.

No ha sido fácil pero la terapia y compartir las preocupaciones con mis colegas y compañeros me ha permitido volverme más cómoda con el hecho de no saber cosas. Es normal olvidar cosas básicas cuando trabajas sobre capas y capas de abstracciones. ¡Incluso es mejor porque así evitas ocuparte de los detalles y dejas oportunidad para solucionar los problemas grandes!

Y también hay muchos tipos de inteligencia, más allá de la lógica. Detrás quedaron las alabanzas al Desarrollador Rockstar. Ninguna empresa seria quiere depender de un programador egocéntrico e incapaz de trabajar en equipo aunque saque funcionalidades a la velocidad de la luz.

El valor de alentar

Siempre es bueno recalcar el valor de nuestro propio esfuerzo. Es muy bonito cuando dejas las excusas y te haces dueño de tus éxitos.

Muchas veces me han dicho que las cosas que conseguí las hice yo sola. Y puede ser. Nadie me obligó a leer libros de JavaScript o dar una charla en un meetup, pero sin esas personas que me ofrecieron palabras de motivación cuando dudaba no creo que hubiera llegado muy lejos o tan rápido.

Cuando se está en una posición de poder o mucho alcance, hay que ser consciente de los mensajes que transmitimos y el efecto que podemos tener en aquellos que están debajo de nosotros. Hay personas que prefieren ser dañinas y creen que pertenecer al área de tecnología es un privilegio al que pocos pueden pertenecer.

Y sí, afecta muchísimo a las mujeres y las minorías. Muchas veces he escuchado la tontería de que las mujeres no saben programar. ¡Mentira! Tengo una amiga que me contó sobre cómo le gustaba programar hasta que un profesor que le dijo que nunca iba a hacerlo bien. Ella, siendo estudiante empezando la universidad, naturalmente quedó muy abrumada y tuvo que tomarle un par de años para retomar la programación. ¿Es necesario esa clase de actitudes?

Y honestamente, la programación no es una actividad de gente súper dotada. Como cualquier otra profesión, lleva práctica y estudio.

Excluir a los que están interesados por prejuicios es algo que no puedo comprender. Mientras voy avanzando en mi profesión, una de mis satisfacciones más inmediatas es ver gente aprendiendo y mejorando solo por contar mis experiencia y mostrar las cosas que hago.

Hay mucho más valor y aprendizaje cuando ayudas a otra persona a ser un mejor desarrollador. Intercambia ideas con personas que están aprendiendo, comparte historias y lecciones, reconoce su esfuerzo y ayúdalos sin juicios a encontrar sus puntos flojos para que trabajen en ellos.

Nuestra área se enriquece de la diversidad, no de seguir la misma corriente de años. Hay personas que me hicieron sentir que puedo aportar de forma significativa a la tecnología y es un sentimiento muy hermoso sentirse apoyado y que ellos estén orgullosos de mi. Es algo que quiero llevar a las personas que quieran aprender de mi en el futuro.

Cómo lidiar con los errores

Por los muchos trabajos que he pasado, he visto instancias donde los desarrolladores hablan mal de las personas que no están en la empresa. También están las situaciones donde alguien encuentra un bug, y el primer chiste es sobre hacer un git blame para saber a quién culpar.

Confieso que hubo un tiempo donde esas dinámicas no me parecían gran cosa, e incluso formaba parte de ellas. Ahora me doy cuenta que son innecesariamente crueles. Porque me llevó a tomarme muy mal cuando aparecían problemas en código que yo había hecho, sentía que estorbaba a mi equipo y que no merecía el puesto que tenía.

Con el tiempo me di cuenta que empezar a desenterrar un bug para buscar el nombre de un causante es una forma rápida de desviar reuniones a estados no productivos, retrasar búsqueda de soluciones y dañar el espíritu del equipo. ¿De verdad importa quien cometió un error si todos estamos claro qué sucedió y qué podemos hacer para que no suceda de nuevo?

He tenido muchas oportunidad de reflexionar sobre mi forma de trabajar y la de los compañeros de equipo que he tenido, y es un hecho que para todo el trabajo que hacemos aplicamos el mejor esfuerzo posible, con los conocimientos y restricciones que tenemos al alcance en ese momento. Y un equipo unido de verdad tiene una buena actitud hacia los errores donde evita generar instancias de culpa y no vacila en darte una mano para sacarte del barro.

La verdad es que los momentos donde se genera el mayor aprendizaje son cuando se cometen errores. Yo he tomado la decisión de sacar todo el provecho que pueda enfrentándolos, compartiendo mis experiencias con ellos y dejando a un lado la mentalidad de “tú lo rompes y tú lo arreglas”.

¿Y ahora?

Pues… ¡les diré que ando un poco nerviosa! Pasar de formar parte en equipos pequeños a más grandes traerá retos nuevos donde tendré que hacer ajustes de mi parte.

Pero todas las personas que conocí en estos años y los momentos que fui ganando, para bien o para mal, siempre me han dejado algo, y creo que mientras tenga presente estas bases que aprendí como junior soy capaz de tener la actitud adecuada para enfrentar los retos que aparezcan.

A quienes decidieron integrarme en su equipo en Globant, ¡Muchas gracias!

…Y por favor, déjenme mandarle gifs de gatitos por la eternidad.

Miles de gracias a las siguientes personas que me ayudaron con feedback: Daniel Rodríguez, Leonardo Graterol, Tatiana Molina, Kat Guzmán y Federico Cayrol (no hice esto como dinámica de retro, lo siento).

Si quieres preguntarme algo, hacer un comentario, o solo saludar, puedes hacerlo por Twitter.

--

--

María Castro

A web developer who likes to draw, videogames and cats. Learning about Agile. My goal is to motivate people to create fun stuff with JavaScript.