Los sesgos en los procesos de selección en equipos de ingeniería – Mi reflexión para el 8M

En vísperas del 8M solemos pararnos a reflexionar sobre distintos aspectos de nuestra sociedad. En mi caso, dado que me estoy encargando del proceso de contratación en mi equipo y tengo experiencia en este tema, quiero describir en qué consisten estos procesos, desde una perspectiva de género feminista.

Espero que este artículo te sirva sobretodo si eres un hombre, si perteneces al equipo de recursos humanos (en adelante RRHH) o People and Culture (en adelante P&C) y también si eres una mujer que no pertenece a un equipo masculinizado.

Las experiencias y datos utilizados a continuación se basan en información recogida en charlas y estudios sobre diversidad e inclusión en entornos de trabajo técnicos, vivencias de compañeras y mi propia experiencia tras 13 años picando código.

Imaginemos, en este ejercicio de reflexión, que eres una programadora en busca de trabajo. Permite que te describa el tablero de juego.

1. No apareces en las listas

Tu nombre no aparecerá en las redes sociales de empleo ni en las listas de las agencias de contratación.

En LinkedIn, InfoJobs y similares, si tu título es “programadorA” o “desarrolladorA” directamente no sales en las búsquedas de “programador”. No existes. Eres invisible a no ser que cambies tu título a “programador”, redactes tu perfil en inglés o apliques activamente a alguna oferta. También puedes aumentar tus posibilidades utilizando “tags” buscados, es decir, incluyendo en tu CV términos como “Java”, “AWS”, “CSS”…

Cuando encuentren tu perfil y vean que eres una mujer, automáticamente tu credibilidad desciende 10 puntos. Deberás demostrar por encima de toda duda que eres válida así que cúrrate el CV. No puedes permitirte ser mediocre.

Por cierto, elige bien la foto. Y no des datos a través de los cuales puedan localizarte físicamente.

Por otra parte, las bolsas de trabajo de las agencias de contratación se generan en base a una determinada caja de eco y no se suelen plantear políticas de diversidad. Por ejemplo, muchas agencias se conforman con captar los recursos recién salidos de la universidad. Sin embargo, sabemos que menos del 30% de las personas que se gradúan en carreras STEM son mujeres. Adivina qué aspecto tiene la susodicha bolsa de trabajo.

Pero en realidad no importa mucho, ya que su objetivo es entregar un recurso a una empresa, no mejorar la industria. Para ello es infinitamente más fácil hinchar CVs de recién licenciados mediocres que ir a buscar candidatas a un bootcamp de mujeres o, dios no lo quiera, asistir a eventos técnicos con mayoría de participación femenina para captar talento.

Tu nombre no aparecerá en las redes sociales de empleo ni en las listas de las agencias de contratación.

2.1. Recurso humano

Como recurso que eres, cuando entres en la empresa, te gestionará RRHH. RRHH es un departamento administrativo que no se preocupa por la diversidad y la inclusión (en adelante D&I). Se ocupan de que firmes el contrato, de tu nómina (que probablemente sea muy inferior a la de tus compañeros, pero nunca lo sabrás porque la política de nóminas es de opacidad absoluta), de tu finiquito, de términos legales, etc. Pero no van a ayudarte si te enfrentas al acoso, a la explotación, al techo de cristal o a la discriminación.

Probablemente tu sueldo sea muy inferior a la de tus compañeros, pero nunca lo sabrás porque la política de nóminas es de opacidad absoluta

Cuando se enfrenten a un conflicto, lo resolverán en favor de la empresa, pidiéndote que no desveles públicamente tu situación, despidiéndote u ofuscando el problema dentro de una iniciativa global.

2.2. People and Culture

A veces la empresa llama “People and Culture” (P&C) al equipo de RRHH cuando quieren darle un rollo más cercano. Este departamento se encarga de fomentar relaciones laborales “familiares” o de amistad entre colegas de trabajo. Puede que de vez en cuando hagan talleres opcionales sobre D&I donde, probablemente, nunca verás a ningún ingeniero.

Porque sus iniciativas no están dirigidas al equipo de ingeniería. A los equipos de ingeniería se les permite que se autogestionen.

P&C, RRHH o como se llame, tiene un filtro de visión que le impide ver a través del velo místico que envuelve a ingeniería. Los ingenieros son seres vacíos con cerebros positrónicos cuyas decisiones responden únicamente a la lógica y jamás se ven afectadas por los sesgos del individuo.

Estos androides no son machistas porque se rigen por un sistema “100% meritocrático”. Casualmente el equipo suele estar formado por hombres blancos cis por aplastante mayoría, por lo que sea, pero vamos que son todos un amor.

Las iniciativas de P&C no están dirigidas al equipo de ingeniería. A los equipos de ingeniería se les permite que se autogestionen.

3. La autogestión de ingeniería

Como el equipo técnico se autogestiona y son todo tíos, probablemente sea un tío el que redacta las ofertas, las anuncia en su caja de eco, diseña el proceso, entrevista y elige a los afortunados. Seguramente no se le pase por la cabeza preguntarse por qué hay 0 o prácticamente ninguna mujer interesada. Si se lo plantea lo resuelve con un rápido “bah, mujeres” y sigue con lo suyo. Nadie está pendiente de esto, todo se autogestiona.

Se acepta y celebra como hito en D&I contratar hombres blancos cis mayores de 40, hombres blancos cis gays o incluso hombres blancos cis hetero con un acento distinto. Imagina lo pequeña que debe ser tu caja de eco para que suponga un shock cultural contratar a un hombre gay.

En fin, imaginemos que por alguna razón has conseguido el puesto incluso siendo una humilde señorita.

El equipo de ingeniería es un grupo de tíos que lleva mucho tiempo autogestionándose. Nadie se ha molestado en escribir un código de conducta y si lo hay nadie vigila que se cumpla. Sobretodo en el caso de los veteranos, que pueden seguir comportándose como unos gilipollas tranquilamente.

Están permitidas las bromas y comentarios de cualquier tipo, porque a ver somos amigos. Te dirán que van a tratarte igual que a los demás, que no son capaces de distinguir tu género, lo cual no sólo cancela la parte más fundamental de tu ser, sino que es mentira, ya que  en realidad eres un estereotipo con patas.

Tus compañeros podrán tener arrebatos, contestar de malas maneras e ir a cara perro todo el día, tú no. Tú debes comportarte, si levantas la voz te llamarán la atención sobre el tono. Si te quejas porque se han apropiado de tus ideas te dirán que somos un equipo, no individuos. Si no sonríes te pedirán que lo hagas. Si le preguntas a algún compañero qué es lo que aportas al equipo, probablemente te cuenten alguna historia sobre lo amable y luminosa que eres. Si reclamas un sueldo equitativo te dirán que eso depende del mérito.

Si le preguntas a algún compañero qué es lo que aportas al equipo, probablemente te cuenten alguna historia sobre lo amable y luminosa que eres.

Simplemente existir supondrá un esfuerzo extra, demostrar que vales será una odisea y sólo lo conseguirás si eres una programadora del copón (y extremadamente cabezota). No esperes sobrevivir siendo mediocre. Y todo esto se suma al esfuerzo habitual de estar labrando una carrera profesional.

4. La programadora

A pesar de ser supuestamente incapaces de ver que eres una mujer, te exhibirán como un trofeo si deben explicar sus méritos en diversidad, incluso cuando te hayas ido y ya no haya mujeres programadoras en el equipo.

Si eres LA programadora, no esperes empatía por parte de tus compañeras de otros departamentos o del equipo de RRHH. Como te he comentado, no entienden tu situación.

Puede incluso que se espere de ti que seas la precursora de la D&I del equipo de ingeniería, la “developer advocate” aunque 1) no sea tu puto trabajo 2) no tengas ningún poder.

Eres un estereotipo con patas que juega a ser programadora, dime cómo te legitima eso para llamarle la atención a un veterano sobre su actitud.

Al cabo de unos años en la industria, si estás un poco harta de la situación y ya tienes algo de estabilidad laboral, podrás empezar a reclamar un espacio seguro. Fíjate que no estoy hablando de colgar banderas moradas de las paredes, sólo de reclamar un pequeño espacio no hostil. Y siempre sin molestar, cuidando las formas, sin crispar el tono y por supuesto sin desenmascarar que esa supuesta meritocracia mística con la que se autogestiona eficientemente el equipo de ingeniería es en realidad machismo puro y duro.

esa supuesta meritocracia mística con la que se autogestiona eficientemente el equipo de ingeniería es en realidad machismo puro y duro

Eso si consigues hacerte un hueco en la industria. Porque si eres una mujer, existe un 40% de probabilidad de que abandones en menos del 10 años. Y no por genética, sino porque habría que estar loca para quedarse tanto tiempo en este caldero al fuego.

5.Una experiencia personal

En mis últimos trabajos he tenido la oportunidad, el apoyo y la energía para colaborar en el proceso de contratación de los equipos de backend. (Actualmente estoy buscando este perfil)

Durante estos años he hecho mi trabajo como programadora y luego, aparte, he dedicado tiempo y esfuerzo a entender el problema e intentar solucionarlo. Se ha dado por hecho que esto era más fácil para mí que para cualquiera de mis compañeros varones, como si yo no me hubiera criado en el mismo campo de nabos que ellos.

He dedicado tiempo y esfuerzo a entender el problema e intentar solucionarlo. Se ha dado por hecho que esto era más fácil para mí que para cualquiera de mis compañeros varones.

Tras entender y enfurecerme por las evidencias, me he enfrentado a muchas barreras con el objetivo de contratar, por mis santos ovarios, a más mujeres:

A la hora de diseñar una oferta o un proceso de selección, da un miedo tremendo hablar de “mujeres”. Se considera discriminatorio para los hombres y los hombres se ofenden fácilmente cuando no se sienten incluidos en algún tema. Hay que ir con pies de plomo.

No sabéis lo duro que es estar compaginando estos dos trabajos y que de repente un compañero te suelte una estupidez sobre la meritocracia o te explique la diversidad. O tener que pasar los filtros de P&C para publicar un artículo sobre este tema. Ya ni hablamos del esfuerzo que supondría hacer que la empresa se declarase abiertamente feminista. Esto último, ni lo he intentado tbh.

Me hace gracia porque RRHH nunca se preocupa de la D&I hasta que la única programadora del equipo levanta la voz. Entonces empieza a ser un problema. Es un problema que la programadora esté levantando la voz, no que el equipo de ingeniería sea machista. Es entonces por lo general cuando gente de otros departamentos empieza a involucrarse en tu lucha feminista para ayudarte aportando un toque “corporativo”.

Todo esto me enfurece, pero sobretodo me entristece, porque en nuestra perspectiva corporativa de ponernos de lado y maquillar el problema, estamos perdiendo oportunidades.

La oportunidad de mejorar la comunidad asegurándonos de que nuestros equipos son espacios seguros y enriquecedores en los que las mujeres pueden crecer y convertirse en veteranas y en referentes.

La oportunidad de mejorar nuestros equipos expulsando a las personas tóxicas y educando en una mejor versión de la masculinidad.

La oportunidad de mejorar, en general, aceptando la diversidad de cada persona, trabajando de verdad como equipo, dando igualdad de oportunidades, pagando equitativamente, cuidando de nuestra salud mental.

6. Despedida

Por suerte, la pesadilla ha acabado. Vuelves a ser el hombre, la persona de RRHH o la mujer en un departamento fenimizado que eras cuando empezaste a leer el artículo.

Te agradezco que hayas llegado hasta aquí y me hayas escuchado. Ahora que puedes entenderme un poco mejor, me gustaría que dedicases un tiempo a reflexionar sobre mi situación y la de tantas otras compañeras, aceptes el problema y nos ayudes a solucionarlo.

Necesitamos que tanto los individuos como las empresas se posicionen claramente y lleven a cabo acciones drásticas, con mano firme, porque sólo con ese poder cambiaremos la industria.

5 Consejos para destacar en la prueba técnica

Cada vez más empresas utilizan pruebas técnicas como parte de su proceso de selección. Una de las más habituales es enviarte el enunciado de un problema de negocio (generalmente relacionado con su actividad) para que lo resuelvas en casa. Tu ejercicio será posteriormente evaluado por tus potenciales colegas de trabajo de forma asíncrona, sin tener contacto contigo. En otras palabras, tu carta de presentación en esta parte del proceso es tu código, por lo tanto, debe transmitir todas tus capacidades.

He estado en ambos lados del muro: He sido candidata y he sido revisora, y esto me ha ayudado a aprender varios trucos y normas de “etiqueta” que me gustaría transmitirte a través de los siguientes consejos:

 

Haz preguntas

Lee con detenimiento el ejercicio y si hay algo que no te queda claro pregúntalo. Una de las capacidades más útiles en programación es la empatía. ¡Programar no cosiste en picar código! En nuestro trabajo es muy importante que entendamos bien el contexto de nuestras tareas, el vocabulario de nuestro sector, las necesidades del cliente. Por lo tanto, no dejes de hacer una pregunta porque pienses que vas a quedar mal, al contrario, vas a dar una imagen muy profesional al mostrar tu compromiso con la entrega de valor.

 

Preocúpate por el enfoque, no por terminarlo

No necesito que termines el ejercicio. No voy a ponerlo en producción ni a venderlo. Lo que necesito es saber cómo programas. Por lo tanto, preocúpate más por cosas como, por ejemplo, tu historial de commits.

Los commits son una buena representación de tu metodología. Sólo leyendo el nombre de tus commits podría conjeturar si has escrito los tests antes que el código, si has dado pasos pequeños, qué importancia tiene para ti la fase de refactor, cuánto tiempo has tenido los tests en rojo e incluso tu capacidad para expresarte y tu nivel de inglés.

Lo cierto es que las aplicaciones nunca están terminadas. El código es un ser vivo que muta constantemente a lo largo del tiempo, por lo tanto es irrelevante si te has creado un “Facebook” de una sentada en una noche. Eso sólo demuestra que tenías tiempo para hacerlo. Lo realmente importante es si tu código es legible por otras personas, si eres capaz de transmitir tus conocimientos, si encajas con nuestra cultura ágil.

Piensa: si tuvieras que irte de vacaciones y dejar este código en manos de otra persona, ¿sería fácil para esta persona trabajar con él? Si la respuesta es sí, no importará que no esté terminado.

Escribe un código limpio

Seguramente estoy dejando de hacer otras cosas para revisar tu ejercicio. Tengo poco tiempo: No me obligues a perderlo descifrando tu código.

Hay muchos trucos y recursos que pueden enseñarte a escribir un código legible y expresivo: Leer mucho para adquirir vocabulario, aprender a detectar los olores de código y a refactorizarlos, programar en parejas…

Mejorar en esta habilidad te será muy útil para comunicarte con tus compañeras y compañeros de trabajo, e incluso con tu yo del futuro. Y también será útil, como hemos visto, para la empresa, ya que un código limpio es un código escalable.

Truco: Si necesitas explicarte a través de comentarios por todo el código, algo no va bien. El código debería autodocumentarse a través de la semántica y de los tests.

 

Cuida tu README

El README es el documento en el que se define en qué consiste un proyecto y cómo interactuar con él. Y es lo primero que voy a buscar. Intenta incluir en él toda la información que creas que voy a necesitar:

  • El enunciado del problema: no des por hecho que me lo sé. Puede que hiciera este ejercicio hace meses o años, o tal vez nunca, y ahora está perdido en el laberinto de documentación laboral de la empresa. No me hagas ir a donde quiera que tengamos los enunciados a buscar el tuyo.
  • Cómo levantar la aplicación y ejecutar los tests: En definitiva, cómo utilizar tu programa. No asumas que tengo el mismo entorno que tú instalado en mi ordenador, ponme links a recursos si debo descargarme alguno, concreta versiones, lista requisitos, dime cuál es el comportamiento esperado.
  • Notas: Si quieres decirme algo que no puedes expresar a través del código, puedes reservar una sección del Readme para “Observaciones”. Por ejemplo, si tenías en mente hacer algunas cosas pero no te ha dado tiempo, o no has podido tomar alguna decisión porque preferirías debatirlo con alguien, escribe una lista de “To-Do” explicando qué, por qué y cómo.
    Por otro lado, es importante que cuides las formas. No te tomes confianzas. No soy tu “coleguita de birras”, soy una profesional que está juzgando tu trabajo, por cierto, con un código de conducta bajo el brazo. Dame sólo la información necesaria, de una forma concisa.
    Y sobretodo no utilices el Readme para quejarte de algo o de alguien, para disculparte, o para explicarme tu situación personal. Estas son cosas que debes hablar con tu persona de contacto de la empresa, que es quien debe valorarlo. Si tu situación personal te ha impedido que dediques más tiempo al ejercicio, lo dicho, escribe en la lista de “To-Do” lo que habrías hecho si hubieras podido.

Haznos la vida fácil

En general, lo que se agradece es que tu ejercicio sea fácil de revisar: Fácil de entender y fácil de operar. En este aspecto, mi mayor consejo es que virtualizes tu entorno de pruebas.

Como he comentado seguramente la persona que te lo está revisando tiene poco tiempo y muchos ejercicios en la cola de espera, y es muy incómodo tener que instalarse el entorno concreto que requiera cada ejercicio.

Por eso agradezco mucho cuando una aplicación está Dockerizada, ya que trae todo el entorno preconfigurado, con las versiones necesarias, etc. Ayúdame a centrarme en tu código.

 

¡Espero que estos consejos te sirvan de utilidad en futuras oportunidades laborales! Ten en cuenta que están basados en experiencias y opiniones personales, por lo tanto, no los sigas al pie de la letra. Los ejemplos que he puesto sirven para procesos de selección en los que se valora ante todo la excelencia técnica y el seguimiento de las buenas prácticas, sin embargo puede que no te sirvan si aspiras a un puesto de Data Science o desarrollo de videojuegos, por ejemplo. Investiga siempre qué es lo que se espera de tí y cuáles son los valores de la empresa.

¿Conoces algún otro truco o consejo para superar las pruebas técnicas?

¿Dónde están esas devs?

¿Cuántas veces has oído eso de que “a las chicas no les gusta programar”? Yo estoy harta de oírlo y leerlo así que lo primero que quiero dejar claro con este artículo es que que nos gusta. ¡Claro que nos gusta! ¿Por qué no iba a gustarnos uno de los oficios más creativos, más empáticos, mejor pagados y con mayor empleabilidad del panorama?

 

¿Entonces, por qué no tengo candidatas?

Te propongo un ejercicio: Por un momento, imagínate que a las mujeres nos gusta programar tanto (o tan poco) como a los hombres.

Visualiza ese supuesto. Créelo. ¿Lo tienes? Vale, ahora vuelve a preguntarte por qué no tienes candidatas. Por qué, aunque nos guste programar, no nos hemos interesado por el puesto que ofreces. Pregúntate también por qué nos pierdes antes de que acabemos nuestros estudios. O incluso antes de que los empecemos, cuando nos enseñan que la ingeniería es “cosa de chicos”.

Bienvenido a nuestra triste realidad.

Nos gusta programar. Lo que no nos gusta es el trabajo que ofreces. Puede que el problema resida en cómo enfocas la pregunta. Deja de preguntarte por qué nosotras no aplicamos, y empieza a preguntarte…

 

¿Cómo puedo hacer mi oferta atractiva para las mujeres?

Aquí tienes algunos consejos:

 

  • Permite el trabajo en remoto sin límites

No te escondas tras “horarios flexibles”, “jornadas intensivas” o “remoting de vez en cuando si tienes una excusa”. Si quieres facilitar la conciliación, permite el trabajo en remoto todos los días. Adapta tu infraestructura para permitirlo. Se puede ser agile, hacer extreme programming e incluso generar sensación de equipo trabajando 100% en remoto, te lo digo por experiencia.

A cambio, tanto nosotras como ellos tendremos más tiempo para estar en casa compartiendo derechos y obligaciones.

 

  • Ofrece salarios competitivos

No nos infravalores. Si quieres que creamos de verdad que vamos a cobrar lo mismo que nuestros compañeros, publica los salarios de forma transparente (al menos de forma interna).

También valoramos beneficios como el seguro de salud privado y los cheques guardería, y seguridades como la estabilidad que ofrece tu proyecto.

 

  • No pidas requisitos mínimos

Muchas mujeres tienden a abstenerse ante una oferta de trabajo cuando no cumplen todos los requisitos mínimos especificados.

Sin embargo, tal vez no necesites ninguno de esos requisitos. En varias charlas he mencionado que el trabajo de un programador no consiste en picar código, sino en pensar.

Esto significa que no necesitas que la candidata sepa “Java”. Lo que necesitas es que sea una persona comunicativa, empática, profesional, resolutiva, responsable. Igual hasta te convence de que Java no es la herramienta que necesitas.

Otra estadística apunta a que las mujeres abandonamos las carreras STEM antes de acabarlas porque, entre otros factores, pensamos que ese no es nuestro sitio. Sin embargo, muchas estudiamos FP, somos autodidactas o nos hemos reinventado gracias a un bootcamp.

Por lo tanto, no pidas títulos universitarios. Estamos llenas de energía y ganas por obtener nuestro primer empleo, pero como en la oferta pone que se necesitan “ingenieros”, directamente no aplicamos.

 

  • Incluye mujeres en las entrevistas técnicas

Con esto no me refiero a que tengas una chica en RRHH. Me refiero a que incluyas una programadora en la entrevista técnica, en el code review, con voz y voto.

De esta forma tu candidata verá que en tu empresa hay otras compañeras y se sentirá más motivada a continuar con el proceso. Tal vez incluso se sienta más relajada durante la sesión de pairing, lo que os ayudará a descubrir su verdadero potencial.

 

  • No acapares su tiempo

No exijas que dediquen su tiempo libre a la programación. Las mujeres no tenemos demasiado tiempo libre ya que, aparte de trabajar, se nos atribuyen por defecto las tareas de cuidado del hogar y la familia.

Por lo tanto no esperes que dediquemos nuestro limitadísimo tiempo de ocio a hackear, a preparar charlas o a acudir a meetups por la tarde-noche o en fin de semana. Algunas lo hacemos y otras no, pero esto no significa que no nos apasione nuestro oficio ni que debas descartarnos por incompatibilidad cultural.

En cuanto a los estereotipos que nombro, luego hablaremos sobre formación.

 

  • Garantiza un ambiente seguro

No solo para contratar, sino también para mantener a las que hayas contratado. No queremos ni tenemos que “luchar” por nada. Estamos cansadas de tener que demostrar nuestra valía todos los días.

Queremos trabajar en entornos sanos, en los que se nos escuche sin necesidad de levantar la voz, en los que se nos dé credibilidad y se respete nuestra profesionalidad. Tenemos muchas ideas, explícanos qué foros nos ofreces para compartirlas: Retrospectivas, code reviews, global dev meetings…

Detalla también cómo de diverso es tu equipo técnico. No la empresa en general, sino en concreto tu equipo técnico. ¿Cuántas mujeres programadoras hay? ¿Qué acciones tomáis para que el entorno sea seguro? ¿Cómo evitáis los prejuicios de género en los procesos de selección?

 

  • Utiliza un lenguaje inclusivo

Supongo que es obvio, ¿no? Programadores y programadoras. Y si lo que buscas en concreto son mujeres, no lo maquilles. Redacta la oferta para una mujer.

 

Vale, ya tengo claro cómo redactar la oferta perfecta. Pero…

 

¿Cómo puedo encontrar talento femenino?

Igual que encuentras talento masculino: Buscándonos.

 

  • Búscanos

No te limites a preguntarle a tus amigos si conocen a alguna chica que quiera aplicar. Sé proactivo. Búscanos en redes sociales, páginas de empleo, universidades, centros de FP, bootcamps (¡incluso en la Devscola! ;)).

 

  • Contrata referentes

Preocúpate de buscarnos en la comunidad. Existen miles de comunidades dedicadas a visibilizar a las profesionales del sector, la más básica búsqueda por internet te devolverá una avalancha de nombres.

Ven a ver nuestras charlas. Asiste a eventos de visibilización. Es imposible que conozcas a mujeres programadoras si evitas este tipo de eventos o charlas. Que esté hecho por mujeres no significa que esté dirigido exclusivamente a mujeres.

 

  • Lidera el cambio

Predica con el ejemplo. Lidera vuestro compromiso con la diversidad acudiendo a cursos a través de los cuales aprendas a ponerte en la piel de una mujer y sentir cómo es nuestro día a día. El peso que cargamos, ocupándonos del trabajo y del hogar, luchando por defender nuestra valía, soportando comportamientos machistas a diario.

Promueve vuestra presencia en charlas impartidas por mujeres o en eventos de visibilización. Igual que quedáis para ir juntos al Codemotion, ¿por qué no quedar para ir al WTM?

 

  • Implícate

Si eres patrocinador, prioriza los eventos de visibilización y eventos con paridad entre ponentes. Si organizas charlas y talleres en tus oficinas, intenta que al menos la mitad de los ponentes sean mujeres. Propón tus propias iniciativas de visibilización.

De esta forma ayudarás a crear más referentes femeninas en las que la siguiente generación pueda fijarse. No hay mejor forma de conseguir que haya más mujeres programadoras.

 

Conclusión

El sector tecnológico es el que más puestos de trabajo genera, y el que mejor proyección a futuro tiene. Como mujeres no podemos permitir que nos expulsen de esa prometedora industria pero, a su vez, la industria no puede permitirse perder a la mitad del talento. Así que, por el bien de todos, actúa.

The Agile Breakfast

Do you know which is the best way to start the day? It’s a fact: A good day starts with a good breakfast. Don’t you agree?

This is the reason why every Tuesday morning we, people from Devscola, buy a bunch of food full of sugar and saturated fats and eat it while making what we like most: Coding. And this nutritional heresy received the name of Katayuno.

Katayuno is a combination of the words ‘Code Kata’ and ‘Desayuno‘. It is an event during which we sharpen our programming skills using code katas and Agile and XP methodologies, like pairing, TDD and code reviews.

But, what does ‘Agile’ and ‘XP’ refer to?

Continue reading “The Agile Breakfast”

Pair programming

This post belongs to this root post and may be out of context if it is read separately.

Pairing is a practice where two developers work together in the same computer. We can imagine it like a ride in a car: The driver manipulates the steering wheel and uses its driving skill, while her companion guides and supports her.

In the same way, during pairing, the driver uses the keyboard and writes the code, while the navigator guides her.

Continue reading “Pair programming”

Timebox

This post belongs to this root post and may be out of context if it is read separately.

Meetings

How many times have you entered a meeting thinking ‘oh my god, this will take hours. I have no idea around what time this meeting will end.‘ Many of us experienced this situation before.

Continue reading “Timebox”

Test Driven Development

This post belongs to this root post and may be out of context if it is read separately.

The Test Driven Development (TDD) is a software development technique that uses tests to make the design merge using the Red-Green-Refactor cycle.

How could I illustrate this…

Have you ever use a ‘gap filling’ exercise? They are used in grammar and language learning, and they look like this:

Gap filling exercise

Continue reading “Test Driven Development”

Retrospective

This post belongs to this root post and may be out of context if it is read separately.

The retrospective is a meeting during which the team discusses about the last three or four weeks. This is a conversation about factual subjects surrounding our work as a team. What did work? What did not work so well? What can we improve?

Continue reading “Retrospective”

Code it yourself

This post was titled after a talk I gave to people attending a course to learn how to develop software. One of the main purposes of my talk was to prevent wrong ideas about what software development really means.

In the past (and nowadays), the industry has considered programmers as ‘coding monkeys’, like if developing software was a repetitive task, similar to assembly lines in factories. But the truth is that the work of a programmer does not consist in writing code, but in THINKING. Thinking solutions that solve problems. It is a creative and adaptive job, therefore, the methodology used for repetitive tasks does not work for software development.

Continue reading “Code it yourself”

Indie games IV – Game design

This post is the first part of the talk I gave at IES Alfons III and belongs to this root post.

Now we know the employable tools, it’s time to get into the core. This post will be composed by two parts: Lifecycle and How to make it work.

The former makes a small tour around different steps that a game has, from its conception to its distribution, while the latter explains how to build a place on the market for your game.

Continue reading “Indie games IV – Game design”

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑