La Teoría del Juego en la Toma de Decisiones 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.

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

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.

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.

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.

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.