Creé mi primera cuenta de GitHub en la universidad, luego no la toqué durante tres años. Si bien escuchaba constantemente sobre el código abierto y los beneficios de involucrarse en el ecosistema, tenía mucho miedo de comenzar porque pensaba que el código abierto era solo para desarrolladores experimentados, no para novatos como yo.
Después de graduarme de la Universidad de Portland, trabajé como ingeniero de software integrado de integración de Linux en IBM durante cinco años. Si bien el rol no contribuyó explícitamente con funciones o correcciones de errores a las comunidades de código abierto, interactuamos con mucho código fuente abierto. Como resultado, tuve una pequeña muestra de algunos elementos de código abierto: buscar errores abiertos, buscar parches y corregir errores. Si bien este nuevo mundo de código abierto fue extremadamente interesante, en realidad no estaba contribuyendo a estas comunidades. Después de beneficiarme del ecosistema de código abierto y el conocimiento de la comunidad durante tanto tiempo en IBM, estaba listo para comenzar a retribuir.
En mi función actual, trabajo en VMware como mantenedor de código abierto para Tern , una herramienta de inspección de contenedores que genera listas de materiales de software (SBOM) para imágenes de contenedores. Disfruto de tener la libertad de proponer funciones y recibir comentarios de otros mantenedores y miembros de la comunidad. Interactuar con otros explorando lo que es útil y lo que nuestros usuarios quieren hace que mi cerebro de mantenedor se pregunte: ¿Qué es factible? ¿Qué tiene sentido? ¿Qué es técnicamente posible? Como ocurre cuando se desarrolla cualquier producto de software, lo que los usuarios quieren no siempre es lo que es posible, pero aún desea que la comunidad encuentre útil su software. Definitivamente hay que lograr un equilibrio entre lo que tiene sentido y lo que los usuarios realmente usarán.
No siempre pensé que sería posible para mí ser un colaborador habitual del código abierto, pero debido a que entré a través de mi trabajo, ha sido gratificante mostrar a los recién llegados que el código abierto es más accesible de lo que creen. Eso es algo de lo que nos enorgullecemos como mantenedores de Tern: queremos que el proyecto sea accesible para todos, incluso si no eres un experto en Python o en contenedores (como yo no lo era). Antes de comenzar, el mensaje que escuché fue que tienes que ser muy hábil para contribuir al código abierto. Me gusta cambiar esa percepción cuando puedo.
Antes de comenzar, el mensaje que escuché fue que tienes que ser muy hábil para contribuir al código abierto. Me gusta cambiar esa percepción cuando puedo.
Todavía somos falibles incluso cuando somos expertos
Me atrajo el puesto en VMware porque implica trabajar con contenedores, que era (y sigue siendo) una tecnología omnipresente central en la forma en que creamos e implementamos software moderno. Dada mi experiencia en Linux y el hecho de que los contenedores no son más que un proceso que se ejecuta en Linux, pensé que tenía suficiente conocimiento básico para tener éxito en el puesto y al mismo tiempo dejar mucho espacio para crecer. Cuando busco nuevas oportunidades, me gusta asumir desafíos que me intimidan o me asustan un poco porque hay satisfacción en demostrarte a ti mismo que puedes hacer cosas difíciles.
Dicho esto, todavía no me sentía totalmente calificado para postularme para el puesto porque, hasta donde yo sabía, era más adecuado para alguien con más experiencia en código abierto. A menudo nos decimos a nosotros mismos que solo debemos postularnos a trabajos si estamos 100% calificados, pero no hay crecimiento allí. Así que me dije a mí mismo que debía postularme de todos modos y, si tuviera la oportunidad, podría hacer el 50 % del trabajo el primer día y recoger el otro 50 % en el camino.
Usamos un software de control de versiones diferente en IBM, por lo que no estaba tan familiarizado con los flujos de trabajo de GitHub cuando comencé a contribuir con Tern. Como colaborador de código abierto relativamente nuevo, trabajar con GitHub fue un poco intimidante. Si bien entendí que cometer errores era una parte inevitable del trabajo, los errores que cometes en GitHub son de dominio público para siempre. En mis primeros meses como mantenedor de código abierto, tuve la oportunidad de poner a prueba esta teoría cuando accidentalmente reescribí el historial de confirmaciones de Git para 80 confirmaciones en la rama principal de Tern. ¡Hablando de traumatizar! Me sentí extremadamente estúpido.
Cuando comete un error, especialmente uno que impacta negativamente o incomoda a otros, existe ese período inicial de pánico y duda (es decir, "¡NO estoy calificado para hacer esto!"). Pero como sabemos, el espectáculo debe continuar. Eso significa aceptar tu error y preguntarte qué vas a hacer para seguir adelante. La mejor manera que he encontrado para seguir adelante después de un gran error es poner salvaguardas para evitar que vuelva a suceder.
En este ejemplo específico, implementé medidas de seguridad aprendiendo sobre Git Hooks y cómo pueden evitar que ingrese a ciertas ramas para que me sea imposible volver a cometer los mismos errores. Luego, di una charla al respecto en una reunión técnica local con la esperanza de que alguien más pudiera aprender de mi error o, al menos, encontrar consuelo en el hecho de que incluso un supuesto mantenedor de código abierto también comete errores tontos. Ese es el lado humano del código abierto: Cualquiera puede cometer errores.
A menudo nos decimos a nosotros mismos que solo debemos postularnos a trabajos si estamos 100% calificados, pero no hay crecimiento allí. Así que me dije a mí mismo que debía postularme de todos modos y, si tuviera la oportunidad, podría hacer el 50 % del trabajo el primer día y recoger el otro 50 % en el camino.
Cultivar la confianza y encontrar el ajuste adecuado
Siempre he sido una persona extremadamente competitiva. Practiqué deportes en la escuela secundaria, obtuve sobresalientes y me gradué tercero en mi clase en la universidad. Cada vez que dudaba de mí mismo frente a un desafío, mi naturaleza competitiva me impulsaba a seguir avanzando hacia el éxito. Esto no quiere decir que nunca haya fallado o dudado de mí mismo, pero la voz competitiva en mi cabeza continúa empujándome. Todavía dudo de mí mismo a menudo. Veré los elogios de alguien con quien fui a la universidad o de un extraño al azar en Internet y me convenceré de que estoy muy atrasado en mi carrera y que debería pasar más tiempo libre codificando. Creo que dudar de tus habilidades es parte de ser ingeniero. Cuando estás constantemente tratando de resolver problemas que aún no tienen una respuesta y trabajas con personas tan inteligentes y talentosas, es
Estudié ingeniería eléctrica en la universidad. A pesar de que había una (relativamente) buena cantidad de mujeres en nuestra clase, constantemente recibía comentarios como "¡Debe ser difícil estar en esa especialidad cuando está tan dominada por los hombres!". Comentarios como este siempre se registrarían como un desafío para mí para ser tan bueno o mejor que mis compañeros masculinos. Incluso cuando mis compañeros de clase masculinos no sabían la respuesta, siempre confiaban en sus habilidades. Aprendí mucho observándolos y traté de proyectar la misma confianza en mis estudios, incluso cuando estaba convencido de que iba a reprobar. "Fíngelo hasta que lo logres" es un cliché, pero es muy aplicable en situaciones en las que es posible que aún no tengas confianza en ti mismo.
Tuve que aplicar este mantra de "fingir hasta que lo consigas" para mi entrevista con VMware. Sabía que solo estaba calificado para ciertas partes del trabajo. Decirle a un entrevistador que no tenía ninguna experiencia con contenedores no contribuiría a un resultado positivo de mi entrevista. En cambio, expliqué cómo podía aprovechar mi experiencia pasada para tener éxito en este nuevo rol y di ejemplos de situaciones en las que no sabía algo y tuve que aprender el tema por mí mismo. Terminé consiguiendo el trabajo y, como resultado, me convertí en un mantenedor de código abierto.
En la escuela, pensé que era importante saberlo todo de la cabeza. Al ingresar al mundo laboral, rápidamente se da cuenta de que no lo llevará muy lejos. No puede memorizar todo e incluso si pudiera, la tecnología está cambiando demasiado rápido para mantenerse al día. Saber cómo encontrar la respuesta es más importante que saber inmediatamente la respuesta.
Cuando comencé a hacer entrevistas para trabajos fuera de la universidad, me advirtieron sobre la temida "entrevista de codificación". Para prepararme, trataría de memorizar todas las posibles soluciones optimizadas para problemas de codificación comunes. Cuando me di cuenta de que esto era imposible para mí, mi confianza se destrozó por completo. Sin embargo, a medida que he crecido como ingeniero, me doy cuenta de que la entrevista se trata tanto de encontrar una pareja para mí como para la empresa. Si una empresa necesita un ingeniero que pueda resolver cualquier problema de codificación en 20 minutos, probablemente no tendría mucho éxito en ese puesto.
Incluso cuando mis compañeros de clase masculinos no sabían la respuesta, siempre confiaban en sus habilidades. Aprendí mucho observándolos y traté de proyectar la misma confianza en mis estudios.
Eliminación de barreras de entrada para otros
Siempre me ha interesado estudiar a las personas y sus comportamientos en diferentes escenarios. A nivel personal, empezó cuando era niño. Mis padres pasaron por un desafortunado divorcio y aprendí mucho observando sus interacciones y comportamientos. Si uno de los padres decía "no" a algo, hacía que el otro dijera "sí"; fue fascinante para mí entender sus motivaciones conductuales. No sabía que esta experiencia de navegar intereses contrapuestos a una edad temprana me estaba preparando para mi futuro trabajo en comunidades de código abierto.
Los comportamientos humanos y los patrones de comunicación se ponen bajo una lupa en código abierto. La comunicación es especialmente única porque normalmente se comunica a través de medios escritos a través de GitHub/Slack/email. Por eso, siempre trato de ser consciente de cómo diferentes personas pueden interpretar el mismo texto. ¿Cómo influyen las experiencias personales de las personas? ¿Qué nivel de consideración debo darle a esto cuando doy retroalimentación?
Un patrón de comunicación que noto comúnmente en mí mismo es la preocupación de herir los sentimientos de alguien, especialmente con la retroalimentación. Casi me disculpo cuando tengo que pedir cambios en una solicitud de extracción, aunque es mi trabajo como mantenedor. No creo que comunicarse con empatía o compasión cuando se comunica sea necesariamente un problema, pero definitivamente hay situaciones en las que ser "demasiado amable" puede interpretarse como incompetencia, especialmente como mujer.
Cuando creé mi cuenta de GitHub por primera vez, elegí a propósito un identificador unisex y no subí una imagen para ver si mi experiencia sería diferente. Como era de esperar, sentí que recibía mucha menos presión cuando solicitaba cambios si la gente asumía que era hombre. Comunicarme como una cuenta supuestamente masculina me hizo sentir menos presión para ser demasiado complaciente o amable.
Puede que responsabilidad no sea la palabra correcta, pero estoy obligado a ayudar a los nuevos en código abierto porque puedo recordar cómo es. Si hay un colaborador de Tern que quiere comenzar con un problema y veo que está en la escuela o es parte de un grupo demográfico subrepresentado en código abierto, estoy más ansioso por brindar orientación y asistencia. Comenzar con el código abierto tiene menos que ver con el proyecto específico y más con comprender los flujos de trabajo y las expectativas de GitHub. A veces, el consejo más útil que puedo dar a un nuevo colaborador es simplemente explicarle cómo actualizar su solicitud de extracción.
Esta experiencia de navegar intereses contrapuestos a una edad temprana me estaba preparando para mi futuro trabajo en comunidades de código abierto.
Todos han estado allí, y muchos de ellos quieren ayudar.
Existe la idea errónea en el código abierto de que necesita conocer todos los detalles técnicos de un proyecto para participar, ¡pero no es cierto! Puedes aprender mucho sobre la dinámica de la comunidad y el estilo de comunicación de un proyecto simplemente observándolo desde lejos. Una vez que encuentre un proyecto y una comunidad que se ajusten bien, consulte su documentación. Mejorar la documentación es una buena manera de comenzar porque puede practicar para familiarizarse con todos los flujos de trabajo y los revisores antes de fusionar el código real.
El siguiente paso es encontrar un mentor en el proyecto. Mucha gente en código abierto quiere ayudar, quiere que otros se entusiasmen con el proyecto y estuvieron en su lugar en algún momento. Al observar la comunidad, puedes encontrar a esas personas. Es posible que no tengan tiempo para asesorarlo en el sentido tradicional, pero pueden tener 10 minutos aquí y allá para guiarlo a través de algo. Si bien hacer preguntas en una comunidad nueva puede parecer intimidante, piense en ello como si ejerciera un músculo. Cuanto más practique la búsqueda de aclaraciones, incluso cuando se sienta vulnerable, más fortalecerá su confianza.
No tengo mentores "oficiales". Nisha es la otra mantenedora de Tern, y siempre la he considerado una mentora, aunque no nos llamamos estrictamente mentora/mentee. Además de nuestro diálogo regular sobre el proyecto, tenemos muchas discusiones sobre cómo queremos que sean nuestras carreras y nos damos retroalimentación sobre las acciones que debemos tomar para que eso suceda. También aprendo mucho al observar la forma en que redacta los correos electrónicos, responde preguntas, se enfrenta a confrontaciones y toma decisiones sobre hacia dónde debe ir el proyecto. En mi experiencia, las conversaciones formales entre mentor y aprendiz a veces pueden parecer rígidas y centrarse en expectativas poco realistas, en lugar de relaciones que evolucionan naturalmente.
Mucha gente en código abierto quiere ayudar, quiere que otros se entusiasmen con el proyecto y estuvieron en su lugar en algún momento.
Lo correcto moralmente y para los negocios.
A veces puede haber una percepción en el código abierto de que si te pagan por trabajar en él, es menos "código abierto". Y, de manera más general, en nuestra cultura, hay una narrativa falsa que dice que si haces las cosas de la manera difícil, cuenta más que si haces las cosas de la manera fácil. No digo que siempre haya una "manera fácil" de hacer las cosas, pero, especialmente como madre, sé que el sufrimiento no hace que nada valga la pena o sea más gratificante.
La gente debe ser pagada. Si una empresa está utilizando un proyecto de código abierto, debería pagar o contribuir de alguna manera. Es importante desde la perspectiva de hacer lo correcto, pero también desde la perspectiva del riesgo. ¿Desea confiar en un proyecto sin información sobre su ciclo de desarrollo, cómo abordan las correcciones de seguridad o cómo deciden en qué trabajarán a continuación? Simplemente no es una estrategia comercial inteligente. Creo que hay un ajuste de cuentas real en este momento en este espacio, ya que vemos más ataques a la cadena de suministro como Log4j. Vemos algunos intentos de invertir recursos en dependencias de código abierto para grandes proyectos como Kubernetes, pero mi esperanza es que finalmente veamos esto también con dependencias de código abierto más pequeñas.
El código abierto puedeser una buena puerta de entrada para ganar experiencia para su currículum, pero también limita quién puede participar si solo esperamos que las personas contribuyan de forma gratuita en su tiempo libre. No soy alguien que quiera programar en todo su tiempo libre, especialmente cuando tengo una familia con la que quiero pasar el tiempo, y especialmente no gratis. La diversidad de experiencias y pensamientos es importante, y no creo que el código abierto estrictamente gratuito promueva ese entorno. Es como decir, solo queremos personas que tengan todas sus necesidades satisfechas; quién puede permitirse trabajar gratis; que pueden no necesitar equilibrio en su vida; que no tienen familia a la que atender; no son padres solteros o alguien que cuida a sus padres ancianos o niños enfermos. Si la expectativa es que tenga mucho tiempo libre para invertir en trabajo no remunerado, limita quién puede participar.
No es un secreto que la participación de código abierto está dominada por hombres. No puedo evitar sentir que este es un efecto secundario general de décadas de expectativa social de que las mujeres, y las madres en particular, se encarguen de la familia y las tareas del hogar. Me gusta pensar que esta mentalidad está cambiando lentamente. Mientras tanto, si me encuentro en una posición frustrante, trato de preguntarme: "¿Qué puedo reconocer sobre esta situación en particular?" Esto puede significar reconocer verdades incómodas, como "No me defendí" o "He sido agradable hasta el punto de que me ha afectado negativamente". Por supuesto, no toda situación desafortunada es resultado de tus propias acciones, pero tratar de encontrar experiencias de aprendizaje en medio de los momentos difíciles es parte del crecimiento como ser humano y profesional. ¡Te lo mereces!
Fuente: marketscreener | somoslibres
