La inteligencia artificial (IA) es una de las tecnologías más disruptivas del momento, que no para de crear nuevas oportunidades para mejorar la calidad de vida de las personas alrededor de todo el mundo mediante contribuciones en diferentes ámbitos y sectores como pueden ser la educación o la salud.

¿Pero, qué pasaría si estos algoritmos estuvieran "aprendiendo" a ser injustos? El efecto podría ser catastrófico. Por ejemplo, un algoritmo de búsqueda de empleo podría favorecer candidatos varones frente a mujeres, o asumir que las mujeres son más adecuadas para trabajos específicos como "enfermera" o "secretaria". Esa solución estaría sesgada y tendría un impacto negativo en nuestra sociedad. Por lo tanto, es necesario levantar nuestras voces y concienciar sobre la importancia de trabajar hacia sistemas que sean justos e inclusivos.

Hoy en día, nos encontramos estos desafíos a diario en el campo de la inteligencia artificial, debido en gran medida porque no hay una clara definición de qué es justo y que no. En esta sesión veremos los principales problemas asociados a los sesgos en nuestros datos y como podemos construir modelos que sean éticos, justos e interpretables.

I will explain how to setup Sentry which is a tool for catching and tracking exceptions very easy to include in our products. Sentry works with multiple programming languages so I hope this matches the general purpose of the conference.

Cada día se añaden millones de líneas de código a nuestros proyectos que tenemos que mantener. Este inventario que vamos generando incrementa la complejidad de nuestro software y complica la búsqueda de los ejes de cambio que existen para modificar el comportamiento de nuestras funcionalidades o de añadir nuevas.

Existen multitud de literatura y conocimiento asociado a crear nuevo software pero muy poco a entender el que ya está escrito. En esta charla contaremos nuestras herramientas, prácticas y heurísticas a la hora de enfrentarnos a proyectos que son complejos de entender, ya sea por su tamaño, como por las decisiones de diseño empleadas.

La charla está enfocada desde un punto de vista práctico para que se pueda aplicar en el día a día para ayudar a enfrentarse al problema de la compresión de software complejo de entender.

¿Consideras que vuestro equipo tiene puntos de mejora que has visto en charlas y libros? ¿Conoces prácticas de XP y de Lean software development que os pueden ayudar pero no acabas de saber explicar bien el por qué funcionan? ¿Quieres introducir alguna mejora, pero no tienes claro cómo “venderla” al equipo?
Una de los ejercicios que más me ha ayudado en los últimos años, ha sido basarme en los 7 tipos de “waste” (muda) de Lean software development.

Me ha ayudado a combatir algunos mitos como que "la especificación temprana reduce el tiempo de desarrollo", que "estimar mejora las predicciones" o que "el testing es para encontrar bugs". Y me ha guiado para saber que prácticas implementar en cada momento y para qué las necesitábamos (pairing/mob, TDD, Vertical slicing, CI/CD… ).

Basándome en mi experiencia explicaré que prácticas ayudan para cada tipo de “waste”, por qué y que impacto tienen en nuestro proceso.

I’ve seen many teams that start only with developers and a very tight deadline. When that happens, teams are in a rush to deliver and quality might not be their priority, so it is usually sacrificed with the promise of taking care of it latter. This becomes a problem, to the point where team delivery slows down and adding new features requires more development work. By this time, teams start thinking about how they can increase the quality in their project, and they most commonly resort to hiring a QA person for this endeavour. However, without the proper team structure and support this is going to be a very difficult task for our new team member.

Many times the QA role is only introduced in teams when things are broken, so I started questioning myself whether it is a symptom of a dysfunctional team.

During this talk I want to go through my journey as a QA. I started as a manual QA, then I started doing automation, at some point I lead a QA department, I went back to automation and finally moved to software development. During this journey my role has changed a lot. I would like to explain tips and tricks that helped me build quality as a practise inside the team instead of making it a responsibility of the QA person.

Un data lake es como el océano, todos imaginamos lo grande que es, somos conscientes de su magnificencia, incluso creemos saber qué seres lo habitan cuando nos arrimamos a la orilla, pero ninguno sabe lo que realmente albergan sus profundidades. El análisis de datos pretende aportar luz a esas oscuras profundidades de un data lake.

Con el traje de buzo y una botella de oxígeno bien cargada saltaremos del barco y nos sumergiremos en los beneficios de aplicar QA en nuestro negocio, un posible proceso de planificación y presentación de resultados. Todo ello desde la perspectiva de quienes acaban de introducirse en estas aguas y que buscan acercarse, de forma asequible, a estas vastas e ingentes cantidades de datos que nadie conoce en profundidad.

Testing: What’s it all about? Everyone talks about testing but what does it all mean? What are the benefits (and the pitfalls)! of writing test-driven code? This lightning talk will be a high-level overview of why testing matters, how it can turn you into a better developer and from a beginner’s perspective, why testing isn’t so scary after all.

¿Es el pair programming una metodología para todos?
Hablaré de la problemática del pair programming:
- situaciones descompensadas de poder
- diferencia de procesos mentales de la gente
- qué pasa si uno es más driver y otro es más "reposado"
- la necesidad de adecuar el ritmo cuando entra gente nueva en el equipo y no están los dos en el mismo punto de conocimiento del producto
- el talante y la paciencia necesarios
- no hacer sentir mal a tu pair por no estar en tu mismo punto
- realmente no son necesarios los merge/pull requests con el pairing

Y por supuesto hablaré del drama de ir al WC cuando estás de pairing :D

Una charla técnica (no tecnológica) en la que contaremos cómo construimos aplicaciones frontend modernas (react, react-native, vue, etc.) mantenibles, agnósticas del framework y cómo nos traemos las buenas prácticas que tan interiorizadas tenemos en el backend al frontend.
Hablaremos de arquitectura de componentes, ui-kits, estado local vs global, arquitecturas limpias, testing, happy-paths y gestión de errores, aislarnos del API y muchos conceptos más. Veremos desde nuestra experiencia cómo todo ello nos ha ayudado a trabajar de manera sostenible en proyectos frontend de gran tamaño a nivel funcional.

Cuando entré en Audiense los sprint plannings duraban toda una mañana y la relación con Producto se basaba en recibir User Stories. Dos años después los plannings duran 15 minutos y consideramos que el equipo de desarrollo y el de Producto son uno solo.
En esta charla intentaré mostrar con qué dinámicas hemos conseguido aplicar la filosofía de Product Developer en nuestro equipo de producto.

At first, this was going to be a talk on the awesomeness of functional programming. Then, we had to admit that in real-life, we use a lot more object-oriented principles. So here it is, the talk to join both! We’re going to look at different features and judge how they would go if you’d use one principle or the other. We want to show you why it would be a bad idea to close yourself to one architecture just on principle, and we’d love to spark a debate on when one makes more sense than the other.

Uno de los problemas más comunes desarrollando es cómo gestionar con el legacy. Y una de las soluciones más comunes a ese problema es reemplazarlo por la v2. El problema es que dentro de 4 años esa v2 se vuelve legacy y la solución es montar la v3… ¿o no? 👀

Esto hace que en lugar de monolitos acabemos teniendo monstruolitos que nadie quiere trabajar en ellos y que frenan mucho la velocidad y motivación de desarrollo. 👹

En esta charla exploraremos **diferentes estrategias de gestionar el legacy**, desde micro a macro diseño. Yendo pasito a pasito, y sobretodo, mostrando soluciones realistas y pragmáticas sin tener que parar todo el negocio todo el año para montar la v2. ✨

Todo esto gracias a técnicas de refactoring, testing, migración progresiva a una buena arquitectura de software con ejemplos en diferentes lenguajes de programación.

A menudo se habla de clean code y de aplicar el principio de boy scout, pero como pasa con los valores, va más allá de ser una técnica, tiene que ser una mentalidad compartida en el equipo para poder contener la deuda técnica del día a día.

El objetivo de este workshop es sentar las bases para aprender DDD y explorar este formato de cartas y tablero como herramienta para enseñar, alinear equipos y tener debates técnicos alrededor del concepto de DDD.

"El juego del DDD" en realidad es un proceso, el cual a través de ciertas actividades, ganaremos alineamiento sobre conceptos de DDD.
Una vez tengamos esas actividades interiorizadas, jugar nos servirá para mantener esa alineación en el equipo.

Si no tienes experiencia en DDD, no te preocupes, disfruta del viaje que te ofrece este workshop...

Learn the critical basics of technical writing. Get an introduction to technical writing through a set of theoretic best practices that will be followed by exercises that will put the learned theory into practice. Based on Google's Technical Writing One course (https://developers.google.com/tech-writing/overview)

We invite mentees from different communities (Codebar Barcelona, Migracode CodeWomen, Step4Ward, Women Who Code, etc.) to join us for a session working with crafters. The guest ticket will be valid for Sunday so mentees can enjoy the conference talks and networking.
For this session we aske mentees to any projects they are working on, homework you have to do or questions you'd like to have answered and we'll paired you with a crafter coach who can help you with it.
Mentees sign up here
Coaches (already attending the conference, you need a full conference ticket) please enroll here

Gracias a nuestra colaboración con Stepward (bit.ly/Step4wardhome) las mentoras nos hemos dado cuenta de la importancia de sentirse acompañada cuando haces un cambio de carrera tengas o no experiencia en el sector tecnológico, para poder bajar la ansiedad y la incertidumbre, sería interesante crear un punto de debate sobre este factor en el momento de crecer profesionalmente y como compartir los privilegios que tengamos con otros que estén en situación desfavorecida.