La Teoría del Juego en la Toma de Decisiones de Software

Rate this content
Bookmark

A medida que trabajamos para construir la mejor solución de ingeniería de software posible, nos encontramos con muchas decisiones que debemos tomar. A diario. A veces esto implica conversaciones muy activas y apasionadas, que a veces pueden tomar un camino negativo, creando un mal ambiente en el equipo. Además, es una gran pérdida de tiempo. Pero ¿qué pasaría si esas decisiones diarias pudieran ser mucho más fáciles y simples? En esta charla intentaré abordar y eliminar los puntos dolorosos de la toma de decisiones en la ingeniería de software y mostraré cómo ayudé a mi equipo a beneficiarse de un proceso de toma de decisiones más ligero.

18 min
09 Mar, 2023

Video Summary and Transcription

La charla de hoy trata sobre la Teoría del Juego de las Decisiones de Software, explorando cómo se puede aplicar la teoría del juego al desarrollo de software. El orador comparte consejos sobre cómo crear un ambiente de equipo productivo y una toma de decisiones efectiva. Enfatiza la importancia de dejar de lado las cosas no importantes y centrarse en lo que es mejor para el proyecto. La charla también aborda cómo manejar dilemas de codificación y toma de decisiones, sugiriendo estrategias como definir KPIs y consultar a un jurado neutral. El orador concluye enfatizando la importancia de mantenerse racional, presentar datos y mantener la profesionalidad en el desarrollo de software.

Available in English

1. Introducción a la Teoría de Juegos de Decisiones de Software

Short description:

La charla de hoy trata sobre la Teoría de Juegos de Decisiones de Software. Compartiré consejos sobre cómo crear un entorno de equipo productivo y tomar decisiones efectivas. Soy Siv Levy, DJ y paramédico de primeros auxilios. Sumergámonos en el mundo de la teoría de juegos y su aplicación en el desarrollo de software.

Hola, soy Siv. Gracias por unirse a mi charla hoy sobre la Teoría de Juegos de Decisiones de Software. Espero que puedan obtener algunos consejos sobre cómo crear un entorno de equipo más productivo mientras enfrentan los desafíos diarios de la toma de decisiones.

Un poco más sobre mí, soy Siv Levy. He estado trabajando en Wix durante los últimos cinco años y medio. También soy DJ, mezclo música oscura de los años 80 y techno. Pueden encontrar mis sets de DJ en vivo en YouTube, disfrútenlo. Y también soy voluntario como paramédico de primeros auxilios y ampliaré más sobre eso más adelante hoy. Para aquellos que no están familiarizados con Wix, Wix es una plataforma para construir sitios web para una variedad de tipos de usuarios, ya sea que sean desarrolladores avanzados o principiantes, Wix te ofrece excelentes funciones para tu negocio y presencia en línea. Así que soy parte del grupo de ingeniería de Wix. Es un grupo de ingenieros muy talentosos, pero también, como vemos aquí, muy diversos en muchos aspectos. Y saben, está bien porque después de todo, todos somos humanos. Dentro de mi trabajo en Wix, tuve la suerte de comenzar un nuevo producto de Wix. Lo he hecho varias veces y para diferentes tipos de usuarios, ya sean usuarios de la empresa o usuarios internos. Comenzar un nuevo producto desde cero es una gran aventura en realidad para cada desarrollador y conlleva muchos desafíos y también incertidumbre.

2. Introducción a la Teoría de Juegos

Short description:

En estos momentos, las personas tienden a sentirse abrumadas y eso afecta directamente su juicio y su capacidad para tomar decisiones. Tomemos un momento y hablemos sobre la Teoría de Juegos uno a uno. La Teoría de Juegos es un campo matemático que trata de maximizar la ganancia o el beneficio en situaciones contradictorias entre dos o más factores, generalmente llamados agentes. Define una amplia gama de relaciones sociales y de comportamiento, así como la ciencia de la toma de decisiones lógicas en humanos, y también en animales y computadoras. Lo más importante que me gustaría que saquen de esta sesión es que no están en un juego de cero y uno.

En estos momentos, las personas tienden a sentirse abrumadas y eso afecta directamente su juicio y su capacidad para tomar decisiones. Tomemos un momento y hablemos sobre la Teoría de Juegos uno a uno. La Teoría de Juegos es un campo matemático que trata de maximizar la ganancia o el beneficio en situaciones contradictorias entre dos o más factores, generalmente llamados agentes. Define una amplia gama de relaciones sociales y de comportamiento, así como la ciencia de la toma de decisiones lógicas en humanos, y también en animales y computadoras. Lo más importante que me gustaría que saquen de esta sesión es que no están en un juego de cero y uno. Un juego de cero y uno es cuando uno gana y el otro pierde. Específicamente, hoy nos enfocaremos en el proceso de cómo tomar decisiones de manera efectiva y con suerte, con menos dolor involucrado. Todo esto me vino a la mente una vez que tuve una discusión con uno de mis colegas y esta discusión empeoró mientras más duraba y finalmente salimos de la habitación con muy malos sentimientos, mucha vergüenza y sin haber tomado ninguna decisión. Pensé para mí mismo, Dios mío, ¿cómo es posible que este tema tan poco importante necesite tanta atención? Quiero decir, es una total pérdida de tiempo. Algo debe

3. Making Decisions in Software Development

Short description:

Además de programar, también soy paramédico. Cada semana tomo decisiones de vida o muerte. Utilizo las mismas habilidades y metodología de toma de decisiones en el campo médico y las aplico al desarrollo de software. La principal diferencia es que los sistemas basados en software están en constante cambio. En cualquier discusión, necesitamos saber cómo dejar de lado las cosas no importantes y enfocarnos en lo que es mejor. El ego a menudo nos lleva a perder tiempo y discutir sobre asuntos triviales como las tabulaciones versus los espacios.

ser cambiado. No lo sé. Así que déjenme llevarlos a otro aspecto de mi vida. Además de programar, también soy paramédico. Me ofrezco como primer respondedor y estoy listo para ser despachado 24 horas a la semana a las 7 para cualquier incidente médico cerca de mí, según mi ubicación y disponibilidad, por supuesto. ¿Por qué les cuento esto? Porque cada semana tomo decisiones de vida o muerte. Literalmente. Y les diré algo sobre las lesiones traumáticas fatales. Realmente tienes solo unos segundos para tomar decisiones difíciles. Entonces, ¿cómo puedo tomar decisiones de vida y muerte en segundos o minutos? Y en cosas no importantes, ya saben, no importantes, me permito discutir una y otra vez y perder tanto tiempo. Ahora, sé lo que están pensando, ya saben, no es lo mismo. ¿Verdad? Pero, y probablemente tengan razón. Pero, ¿qué pasa si puedo usar las mismas habilidades y metodología de toma de decisiones en el campo médico y aplicarlas en el campo del software en el que trabajo? Veamos en qué se basan mis decisiones. Así que tengo mi entrenamiento y protocolos, ¿de acuerdo?, en cada campo. Siempre uso mi experiencia pasada, ¿de acuerdo? Cuanta más experiencia tenga, mejor. Y miro hacia adelante al objetivo principal. ¿Cuál es el objetivo principal que quiero lograr aquí? La principal diferencia entre los dos casos es el hecho de que los sistemas basados en software son virtuales, ¿de acuerdo? Por naturaleza, el requisito siempre está cambiando. Todo el tiempo. Y no es como cualquier otro producto que enviamos de la fábrica a la estantería y ya está. Así que la verdad desnuda aquí es que solo en retrospectiva sabes si tomaste una buena decisión o no. En cualquier otro campo de ingeniería, así como en la ciencia médica, el requisito es constante, mientras que en el software, está cambiando constantemente. ¿De acuerdo? Después de darme cuenta de estos principios, pasemos a la segunda fase. La segunda fase en una discusión es saber cómo dejar de lado las cosas estúpidas, ¿de acuerdo? Y sé que para algunas personas, algo estúpido puede ser lo más importante y viceversa, pero realmente estoy tratando de reducir el nivel de drama. Entonces, si la otra persona propone la mejor práctica A, y yo propongo la mejor práctica B, ¿entonces qué demonios importa? Ambos queremos lo mejor y eso es lo importante. Quiero decir, cualquier decisión que se tome es mucho mejor que perder tiempo y seguir discutiendo entre nosotros. De acuerdo. Sin embargo, tenemos esta pequeña cosa llamada ego. De acuerdo. Y este ego nos lleva a lugares tan bajos como las tabulaciones versus los espacios. Veamos algunos ejemplos en mi próxima diapositiva.

4. Spaces vs Tabs Argument

Short description:

Tus compañeros de cuarto tienen razón. Realmente odias los espacios. Tengo una ligera preferencia por las tabulaciones porque prefiero la precisión. Una vez que pasa por el compilador, es lo mismo, ¿verdad? No entiendo por qué alguien usaría espacios en lugar de tabulaciones. Las tabulaciones crean tamaños de archivo más pequeños. No creo que esto vaya a funcionar. No hay forma de que esté con alguien que use espacios en lugar de tabulaciones.

Vamos. Oh Dios mío. Tus compañeros de cuarto tienen razón. Realmente odias los espacios. No, no, no, no, no lo odio. No es un odio fuerte. La verdad es que tengo una ligera preferencia por las tabulaciones, pero eso es solo porque soy meticuloso y porque prefiero la precisión. Bueno, no quiero pelear aquí. Pero si realmente te importa la precisión, usa espacios, pero como sea. Una vez que pasa por el compilador, es lo mismo, ¿verdad? Sí, sí, técnicamente sí. Supongo que simplemente no entiendo por qué alguien usaría espacios en lugar de tabulaciones, si al final es lo mismo, bueno, ¿por qué no usar simplemente tabulaciones? Porque podría verse diferente en las computadoras de otras personas. Las tabulaciones crean tamaños de archivo más pequeños. De acuerdo. Dirijo una empresa de compresión. Créeme, he dedicado mi vida a minimizar los tamaños de archivo. Es lo que hago. No entiendo por qué alguien usaría espacios en lugar de tabulaciones. Quiero decir, ¿por qué no usar Vim en lugar de Emacs? Yo las uso en lugar de Emacs. Oh, Dios, ayúdanos.

De acuerdo, uh, sabes qué, simplemente no creo que esto vaya a funcionar. Lo siento mucho. Quiero decir, ¿qué vamos a hacer, traer niños a este mundo con eso en sus cabezas? Eso no es realmente justo para ellos. Ni siquiera hemos dormido juntos. ¿Y sabes qué? Nunca va a suceder ahora. Porque no hay forma de que esté con alguien que use espacios en lugar de tabulaciones. Richard.

De acuerdo, sí, esto fue como una escena del gran programa The Silicon Valley. Entonces Richard aquí rompió con su novia por esta, ya sabes, antigua y estúpida discusión. Así que debes ser transparente con la otra parte, ¿de acuerdo? Tal vez incluso antes de comenzar a discutir el problema y definir si el problema es crítico o no. ¿Y por qué te duele tanto? ¿Por qué te importa tanto? De cualquier manera, intenta dejar tu ego afuera.

5. Handling Coding Dilemmas and Decision-making

Short description:

Tomemos otro ejemplo, ¿de acuerdo? Estamos analizando dos formas de lograr la misma funcionalidad en el código. Los dilemas de codificación pueden llevar a discusiones apasionadas y conflictos en el equipo. Para reducir el drama, pregúntate si el problema es reversible y define KPIs para la toma de decisiones. Ten una estrategia de respaldo y establece un plazo para la toma de decisiones. Consulta a un jurado neutral si es necesario. La antigüedad no significa tomar todas las decisiones; significa ser un asesor del equipo.

Tomemos otro ejemplo, ¿de acuerdo? Veamos el siguiente código. Este código fue escrito hace solo unas semanas en mi equipo. Sí, mi equipo y yo no somos, ya sabes, inocentes. Y a veces tenemos los mismos problemas a pesar de que todos tenemos experiencia y llevamos trabajando juntos bastante tiempo. Pero aún así sucedió. Así que aquí estamos analizando dos formas de lograr la misma funcionalidad, que es llamar a una función, crear un elemento y obtener una nueva instancia de elemento como resultado. Mientras que la primera opción es llamar a la función y poner todos los parámetros uno tras otro, la segunda opción define una interfaz que tiene exactamente las mismas propiedades y el parámetro de solicitud dado para la función debe cumplir con esa interfaz. Ahora no tenemos tiempo para profundizar en cuál es mejor, así que no lo discutiré ahora. Pero probablemente estés familiarizado con este tipo de dilemas de codificación que a veces incluso surgen en un proceso de revisión de código. Y esos dilemas pueden llevar a una discusión apasionada que rápidamente se convierte en una pelea de equipo completa, ¿vale? Y eso es exactamente lo que sucedió en mi equipo hace unas semanas, y fue a través de Slack, ¿vale?, con más de 15 mensajes sobre este problema. Así que imagínate eso. Entonces, nuevamente, lo que quiero que saques de esta sesión es cómo detectar esos momentos y ya sea ganar el juego o evitarlo desde el principio. Lo que he encontrado que funciona para reducir el nivel de drama en torno a estos problemas es hacerme dos preguntas principales. Una es si esto es reversible, y la segunda es cuán rápido puedo darme cuenta de que cometí un error, ¿vale?, que tomé la decisión equivocada. Ahora, si el problema es reversible, ¿vale?, quiero decir, si la decisión que tomo e implemento en el código es reversible, entonces bien, problema resuelto, ¿vale?, no es necesario enfatizar una y otra vez esta misma discusión. Y si no es reversible, bueno, realmente dudo de eso porque no estoy familiarizado con casi ningún campo de software que no pueda cambiar el software mediante una actualización por aire o lo que sea. Lo segundo es definir un punto rápido, ¿vale? Necesitamos saber cuáles serán los KPI, qué nos indicará que tomamos una buena decisión, una decisión equivocada o también una buena decisión. Y también necesitamos tener una estrategia de retroceso. Significa que si consideramos dos o más enfoques y elegimos uno, y probablemente supongamos que podríamos querer cambiar a otro después, entonces necesitamos tener una estrategia de respaldo para que la transición sea, ya sabes, lo más fluida posible para los usuarios en caso de que se implemente la decisión y esté en producción. Otra lección que me gustaría compartir es que si el problema es crítico y no llegas a una decisión en 10, 20 minutos, tal vez un poco más tarde, pero, ya sabes, intenta limitar la discusión a un cierto plazo. Entonces, si no tomas una decisión dentro de este plazo, simplemente consulta al jurado. ¿Vale? Este jurado debería ser alguien con quien todos estén de acuerdo y aprecien sus conocimientos. Y por cierto, no debería ser el gerente o el líder del equipo o lo que sea. ¿Vale? No los pongas en esta incómoda situación donde tengan que elegir entre tú o alguien más del equipo. ¿Vale? No es su trabajo y es desagradable para todos. También quiero enfatizar algo sobre el nivel de antigüedad. Ser un senior en un equipo no significa que la decisión sea tuya para tomar.

6. Final Thoughts and Game Rules

Short description:

Puedes proporcionar ideas basadas en tu experiencia real. Si no tienes experiencia con un problema específico, no eres mejor que el desarrollador más junior. En problemas no críticos, tenemos reuniones semanales para sugerencias del equipo. Sin ego, mantén la racionalidad, aporta datos, llama a un jurado. Mantén la profesionalidad y la mente abierta. Considera que estás en una primera cita en el trabajo. Sé educado y mantén la calma.

Y la decisión es tuya para tomar. ¿De acuerdo? Esto significa que eres el asesor del equipo. ¿De acuerdo? Puedes proporcionar más ideas basadas en tu experiencia real. Y si no tienes experiencia con un problema o tema específico, entonces no eres mejor que el desarrollador más junior en la sala. ¿De acuerdo? Por ejemplo, tengo más de diez años de experiencia y nunca he lidiado con la recolección de basura. Por lo tanto, no tengo aportes en este tipo de discusión sobre el rendimiento de la recolección de basura. Y en otros casos donde el problema no es tan crítico, como la calidad del código o las convenciones de código, organizamos una reunión semanal para que el equipo sugiera y discuta esos temas. A veces, esta reunión se convierte en una reunión de desahogo, una discusión sobre otros temas. Siempre tratamos de hacerla con algunas bebidas para que el ambiente sea agradable. Y, ya sabes, si nadie propone ningún tema, entonces la reunión se cancela para esta semana o para este mes. Realmente ayuda a coordinar las cosas. Estamos a punto de terminar esta sesión. Así que quiero finalizar cuáles son las reglas del juego aquí. Sé rápido. Adopta un proceso más rápido y sigue tu intuición. Recuerda que no estás en un juego de suma cero. ¿De acuerdo? Todos ganan aquí. Todas las propuestas son correctas de alguna manera, y solo necesitas entender cuáles son los compromisos. Y sin ego, ¿de acuerdo? Deja tu ego afuera. Los jugadores con ego nunca ganan. Y trata de mantener la racionalidad, ¿de acuerdo? Aporta un punto de vista racional, ¿de acuerdo? Sé técnico. Aporta los datos. Usa los datos para tus argumentos. Y llama a un jurado, ¿de acuerdo? Deja que alguien más decida. Siempre es mucho más fácil. Y mantén la profesionalidad, ¿de acuerdo? Recuerda que cuando discutes con... estás discutiendo sobre asuntos profesionales con algunos de tus colegas, debes mantener la profesionalidad, ¿de acuerdo? No te lo tomes personal con ellos. No les digas qué hacer, ¿de acuerdo? De manera autoritaria. No les digas qué pueden o no pueden hacer. Y, ya sabes, a veces las personas piensan fuera de tu caja. Y eso es simplemente porque no encaja en tu caja o no llegas al fondo de sus pensamientos. No significa que no sea una buena idea. Y la última regla general es considerar que estás en una primera cita, ¿de acuerdo? En una primera cita, dejas de lado las cosas no importantes, o de lo contrario no tendrás una segunda cita. Así que deberías hacer lo mismo aquí en el trabajo, ¿de acuerdo? Solo considérate en una primera cita. Sé un caballero. Sé educado, y mantén la calma. Eso es todo. Gracias. Soy Ziv Levy. Tengo mucho más para compartir. Estaré encantado de conocerte y charlar contigo. Siéntete libre de contactarme también en Twitter, underscore Ziv Levy. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
Everything we do, from the way in which we write our emails, to the method in which we provide negative feedback and evaluate performance, governs the performance of our teams. And understanding how culture impacts our efficacy as a team can drastically improve our day-to-day collaboration. In this session you'll learn: How different cultures communicate, How different cultures evaluate performance and give constructive criticism, How different cultures make decisions, How different cultures trust, How different cultures perceive time.
React Advanced Conference 2021React Advanced Conference 2021
20 min
Advanced Patterns for API Management in Large-Scale React Applications
Top Content
In this talk, you will discover how to manage async operations and request cancellation implementing a maintainable and scalable API layer and enhancing it with de-coupled cancellation logic. You will also learn how to handle different API states in a clean and flexible manner.