← Volver al podcast Podcast

Devs Lives #25 Gema Socorro | Androides y Personas

Escuchar episodio
Abrir en iVoox

Transcripción

[No identificado] (00:00:23): Bienvenidos a Devs Lives, episodio número 25.

[No identificado] (00:00:29): Hoy contamos con una invitada muy especial, no sólo por lo que esta persona significa en el sector del desarrollo para Canarias y en general para el ámbito nacional, sino también por las historias que hay detrás.

[No identificado] (00:00:50): Además, como anécdotas para el episodio 25, ya vemos que en el episodio 24 muchas personas se querían rifar este número. No sé qué tiene el 25. Me han propuesto hacer episodios especiales para el día de hoy, pero creo, creo que la invitada de hoy se merece este episodio y esperemos que lo disfrute como las mejores. Tenemos que ir con nosotros a Gema Socorro. ¿Qué tal, Gema? Bienvenida. ¿Cómo estás? Muy bien, muy bien. La verdad es que es todo un honor. Encima de eso, me ha tocado la sesión 25, ¿no? ¿Qué tendrá ese número, no? La verdad es que no sé.

[No identificado] (00:01:34): Ay, la gente, la gente del sector. Sí, sí, sí, sí, sí, sí. O sea, yo no sé si es por las bromas tontas, si es que es como que es la cuarta parte de 100, si qué pasa, pero es como a mí me gustaría…

[No identificado] (00:01:48): Pero da igual, es un número, o sea, ¿qué más da? Pero no, no, la gente es codiciándolo. O sea que… Hombre, el número romano es bonito, ¿no? Y XXV. XXV. No había caído, no había caído. Igual es por eso, no sé. Hay gente que le gusta, yo qué sé, el rollito clásico.

[No identificado] (00:02:07): Ostras, me estás haciendo que me replantee muchas cosas, pero no, no, la decisión está bien tomada, está bien tomada. O sea, hoy es para ti, para que lo disfrutes. Los demás, pues se tendrán que esperar a otro número que les guste, el 27, el 50, el… Yo qué sé, el 100.

[No identificado] (00:02:26): Aquí es lo que va tocando. Pues sí, pues nada, súper agradecida de que me hayas invitado a estar aquí y encima eso, porque decían con mucho honor de que me toquen este episodio. Nada, nada, nada. Ya te digo, para mí es un honor que estés tú aquí, porque para… Bueno, creo que poca gente lo sabe, de hecho probablemente solo lo sepamos… Yodra, tú y yo, y dos o tres personas más que coincidimos, pero nos conocimos hace… Ya perdí la cuenta, puede que cuatro años a lo mejor, en un GDG Gran Canaria.

[No identificado] (00:03:02): Y a partir de ahí, pues, bueno, nos hemos seguido la trayectoria profesional mutuamente y creo que el aporte que has hecho a la comunidad y en sí en el sector es súper interesante. Entonces, nada, el honor es mío de que estés hoy aquí y nos cuentes un poquito sobre tu trayectoria, sobre qué te gusta, qué no te gusta, qué valoras, qué odias. Y es una pregunta up to you. Hay un montón de temas que podemos sacar y disfrutar. Así que, nada, vamos a empezar con la maravillosa pregunta, la que nadie espera. Todo el mundo sabe, pero nadie espera.

[No identificado] (00:03:37): Todos la esperamos, pero nadie sabe cómo responderla, ¿no? Exacto, yo todavía sigo esquivando esa bala. Pero para mí es la pregunta que es la bala de plata.

[No identificado] (00:03:46): Así que, cuéntanos, ¿quién es Gema?

[No identificado] (00:03:51): Pues, no sé, Gema es la señora esa que está saliendo en el cuadradito ahí, en sus pantallas, o las que lo estén viendo, ¿no? Bueno, yo creo que Gema, primero que nada, es un ser humano, una persona. Y luego, más allá, pues, es muchas otras cosas. Por ejemplo, en una faceta de su vida, pues, por el día es una programadora, no digamos.

[No identificado] (00:04:15): En otra faceta de su vida, pues, es madre de familia. En otra faceta de su vida es una persona a la que le gusta hacer muchas cosas, sobre todo aprender muchas cosas nuevas.

[No identificado] (00:04:26): Y, bueno, y disfrutar como hacemos todos, ¿no? Pues, viendo pelis, viendo series, teniendo hobbies ultra raros. Bueno, ultra raros, ¿no? Es que parece que voy a decir aquí que, yo qué sé, que escalo montañas con tacones o algo de eso. Tampoco es para tanto, ¿no?

[No identificado] (00:04:43): Pero, bueno, al final, pues, Gema está aquí a lo que hemos venido todos, ¿no? A disfrutar un ratito y a compartirlo, ¿no? Sí, me parece estupendo. Y, además, que remarque sobre todo eso, que hay algo más, aparte del desarrollo. Oye, porque muchas personas todavía me choca bastante que parece que eres lo que haces. Y que eres esa persona que está frente a un ordenador ocho horas, pero hay más allá de la persona. Y, aunque digan, hay que separar lo profesional y lo laboral, pues, al final es tu esencia, ¿no?

[No identificado] (00:05:18): Hay muchas cosas que aprendes en tu vida diaria y cotidiana que te acabas llevando al ámbito profesional, lo que no puedes es llevarte los problemas.

[No identificado] (00:05:28): Y hay muchas personas que también consiguen hacerlo a la inversa, ¿no? Todo lo que aprenden durante el día a día en su trabajo, bien sea en el ámbito tecnológico que lo acaban aplicando en su vida y facilitándosela. O bien todo el tema de soft skills, de cómo comunican con las personas, cómo gestionan problemas, que lo llevan a su día a día. O sea, que al final es un todo. Sí, total. Bueno, yo te iba a decir, ahora por lo que tú dices, de que, bueno, que te llevas las cosas al trabajo, situando los problemas.

[No identificado] (00:06:01): Yo creo que también muchas veces la forma en la que resolvemos problemas en nuestra vida, en el día a día, también nos ayuda. Es que al final somos la misma persona, ¿no? Entonces los aprendizajes que tenemos en nuestra vida, pues, nos ayuda también en lo que es, pues, eso, las relaciones humanas en el trabajo, ¿no? Tú fuera de tu trabajo también te relacionas con personas. Al final todo está unido, ¿no? Al final, yo qué sé. Es que a mí me encantan estas cosas, como las pequeñas casualidades, ¿no? En plan de, pues, un día medio por aprender a fotografía, ¿no? Aprender fotografía, ¿no?

[No identificado] (00:06:30): Y resulta que ahora en el trabajo, estoy poniendo un ejemplo un poco raro, ¿no? Pero por poner un ejemplo así. Pues ahora en el trabajo resulta que tengo que trabajar con una librería de cámara. Pues ya yo sé muchas cosas, ya yo sé lo que es un megapíxel, ¿vale? Eso es obvio, ¿no? Pero aprendes muchas cosas. Sé lo que es, pues, el obturador. Sé lo que es el color. Sé lo que es la temperatura, etcétera, ¿no? Entonces, al final yo creo que somos un todo, que está todo relacionado, ¿no? Y somos un todo que está formado por varias patitas, ¿no?

[No identificado] (00:06:59): En plan de hay una patita que es el trabajo, hay una patita que es la familia, otras son las amistades, otra es tú mismo o tú misma, ¿no? Hay que cuidar de todas las patitas y darles cariño, ¿no? Pero ninguna de ellas te define a ti como persona o define el valor que tú tienes como persona, ¿vale? Tú puedes ser malísimo en el trabajo, pero tener, es decir, ser muy buena persona, ¿sabes? También depende donde esté la escala de valores y demás, ¿no?

[No identificado] (00:07:23): De cada uno, porque es verdad que la sociedad en la que estamos hoy en día parece como que es mucho más valioso el que tengas éxito, que ganes mucho dinero, que estés a la punta arriba de una empresa, ¿no? Que seas conocido y a lo mejor eso no es lo que te hace feliz a ti o… Es que no tiene por qué radical ahí el valor, ¿no? De las personas. Claro, cada persona tiene… Como yo lo entiendo y creo que estoy bastante alineado con tu pensamiento, es que cada persona tiene sus valores y no tienen que ser los mismos valores para…

[No identificado] (00:07:54): Pues para cada persona hay… Te tengo que voy a parafrasear un poco, pero hay personas que valoran muchísimo eso mismo. Ser millonarios, trabajar en la empresa más importante, ser CEO, CTO y hay otras personas que simplemente se conforman con tener una vida más humilde y disfrutar de lo que hacen. Y llevándolo un poco al terreno de cómo se promociona la gente, ¿no? Muchas veces se habla de eres junior, pasas a… Todos sabemos ya esa famosa escala y llega un momento en el que dicen vas a pasar a ser desarrolladora a team lead o product manager.

[No identificado] (00:08:33): Y muchas empresas lo ven como positivo, pero igual para la persona no lo es. Y además, es como un salto totalmente transversal, que es como por qué sobreentiendes que ciertas cualidades se pueden llevar al otro ámbito, no tienen nada que ver, ¿no? No sé cómo lo estuve en ese sentido. Sí, sí, totalmente de acuerdo. Es decir, tú al final, si te has dedicado a desarrollar, ¿no?

[No identificado] (00:08:57): Y si te cambias luego a un puesto en plan engineering manager, product manager, es un cambio de carrera. Realmente es como si dices, pues ahora no soy desarrollador, ahora soy médico, ¿no? Pero en plan exagerado, ¿no? Realmente yo creo que también, por ejemplo, lo que es el engineering manager, ¿no? Es un rol que está más relacionado con la psicología en sí que lo que es el código, ¿no? Está bien tener un background de código porque eso te ayuda a entender a las personas, ¿no? A las que tienes que ayudar porque realmente tu trabajo es ayudar a las personas que están a tu cargo

[No identificado] (00:09:32): Para que puedan hacer su trabajo lo mejor posible y para que se realicen haciéndolo y crezcan haciéndolo y demás, ¿no? Entonces, está eso como más ligado a lo que es el campo de la psicología, entender las personas, pues saber llevar conflictos, saber llevar situaciones, que es lo que es el código en sí. También es verdad que como desarrolladores, pues no todo es código, ¿no? Porque también trabajamos con otras personas y terminamos a lo largo de los años, queramos o no, desarrollando ciertas soft skills, ¿no? Hay gente que las trae de serie, pero hay gente que las va aprendiendo por el camino, ¿no?

[No identificado] (00:10:05): Entonces, sí, eso te ayuda, eso está un poquito de parte de la psicología, pero yo lo veo como un cambio totalmente de carrera. Es decir, ya lo mío, es decir, ya no te vas a dedicar a trabajar en código. Vas a empezar a trabajar con personas, a programar. No a programar personas, pero sí ayudarlas, ¿no? Entonces, es algo totalmente distinto, ¿no? Sí. Y bueno, tradicionalmente, pues bueno, eso era como visto como la manera de crecer, ¿no? Pero hay muchas empresas hoy en día que te permiten seguir creciendo, ¿no?

[No identificado] (00:10:35): En lo que es la vertical esta de, pues como individual contributor, que es lo que se le llama, ¿no? En plan de seguir siendo desarrollador o desarrolladora y poder seguir desarrollando tu carrera ahí. Lo veo súper enriquecedor porque yo creo que una persona se compone al final, como bien decíamos antes, de toda esa caja de herramientas que va teniendo, ¿no? De las conversaciones, de cómo va creciendo la psicología, todo el conocimiento técnico, cuantas más herramientas técnicas, perdón, cuantas más herramientas tengas, mejor vas a poder desenvolver tu trabajo. Quiero decir, no porque tengas cualidades de, o sea, hayas adquirido conocimiento o herramientas de psicología,

[No identificado] (00:11:22): Quiere decir que ya tengas que dar un salto al product management o que te guste mucho el diseño y la experiencia de usuario, no quiere decir que tengas que saltar a UX. Todo eso también lo puedes aprovechar como desarrollador, como bien decías, pues conocimientos de cámara. Ahora mismo, por poner el ejemplo, yo he aprendido gracias al podcast un montón de temas de sonido, de vídeo, de edición, que yo nunca me planteé que fuese a saber. Y en mi día a día intento sacarle partido, ¿no? Es complicado porque dentro de lo que estoy desarrollando ahora mismo, pues no tiene mucho que ver.

[No identificado] (00:11:57): Pero hay conceptos que tú dices, ah, mira, pues esto se puede asociar, cómo representas y demás. Y, ostras, yo creo que eso facilita mucho el día a día. Y por la otra parte, yo creo que levanta la mano la persona que nunca ha dicho, wow, es que el manager no tiene ni idea de desarrollo, está intentando tomar decisiones que igual le vienen un poco grandes. Todo esto dicho de forma muy políticamente correcta porque todos decimos, bueno, decimos de otra forma que viene a ser, esto no tiene ni idea de qué viene a ser. Vale.

[No identificado] (00:12:31): Pero creo que al final es eso. O sea, da igual el rol en el que estés, que cuanto más conocimiento tengas, bien sea de tu especialidad o no, te va a ayudar, directa o indirectamente. Y eso mola mucho porque al final, como bien decía, desarrollamos, bueno, desarrollamos productos y ayudamos, ¿no? No solo la parte técnica. Hace muy poquito teníamos una sesión y demás y me llamaba mucho la atención que cuando preguntábamos a la gente qué significaba ser desarrollador, qué era ser desarrollador de software, qué era ser developer,

[No identificado] (00:13:15): Solo se quedaban con la parte técnica, ¿no? Desarrollamos soluciones técnicas para, o desarrollamos soluciones técnicas para problemas. Problemas, es como, ¿y la parte humana? O sea, al final estamos solucionando problemas humanos, no problemas técnicos, ¿no? O sea, las aplicaciones no las usa un ordenador per se. O sea, las usan las personas, ¿no? No sé. ¿Será que el mensaje de Isaura me caló mucho cuando lo dijo en el podcast? Es que bueno, Isaura es una crack. Sí, ese mensajito de el end-to-end que no es la persona que está delante del teclado frente a la otra que está.

[No identificado] (00:13:54): No, no, es el cerebrito este que está aquí detrás, que va de un cerebro a otro y de extremo a extremo. Es el auténtico end-to-end. Total, total. Sí, sí, sí. Totalmente de acuerdo. Y es que además eso es como también, para mí, por ejemplo, saber eso es como la gasolina, ¿no? Del día a día de, yo qué sé, ¿por qué estoy teniendo que resolver este problema de listas enlazadas? Pues porque hay una persona a la que vas a mejorar la vida de alguna manera, ¿no? Sí. Y eso pues te da eso como la visión, la misión de lo que estás haciendo, ¿no?

[No identificado] (00:14:30): Sí, aporta mucho, muchísimo valor. Y llevándolo por esta línea también en tu, bueno, en una charla que dice en el Tenerife y Gigi, ¿vale? Hablabas también de precisamente la UX y de cómo los usuarios interactuaban con las aplicaciones y demás. Y creo que eso enlaza muy bien con lo que hablaba Isaura. Entonces, ¿cómo ves tú la UX? ¿Cómo la entiendes a día de hoy después de esa charla? A mí, por lo menos, me encantó. En ese momento te lo comenté muy rápidamente y breve porque tú sabes, las charlas en los pasillos se complican y dificultan muchas veces, pero encantadísimo de esa charla.

[No identificado] (00:15:13): Entonces, bueno, a día de hoy, ¿cómo ves y sientes tú la UX? Bueno, pues, a ver, primero decir que yo no trabajo directamente, es decir, no soy la persona que tiene… ¿Hay personas más inteligentes que tienen esas ideas? ¿Hay personas inteligentes? No, bueno, que saben más. Somos todos inteligentes.

[No identificado] (00:15:32): Pero es verdad que al final la UX va a ser la puerta, ¿no? La puertita. Imagínate que tu producto es una casa, ¿no? Y la UX es la puertita que tú le abres a la persona que va a usarlo, ¿no? Y tú quieres que la persona se quede en tu casa el mayor tiempo posible, ¿no? Entonces tú, pues, haces que esa casa esté agradable para esa persona. Pues, la invitas, le dices, ¿qué prefieres? ¿Chocolate o café? Pues, lo que prefiera, ¿no? Chocolate, vamos a tomar chocolate. ¿Qué prefieres? ¿Ver la tele o charlamos, no? Pues, la UX es eso.

[No identificado] (00:16:02): Es como ese punto en el que tú vas a poder relacionarte con tus usuarios y usuarias y tiene que ser, pues, lo más adaptado posible a ellos y a ellas, ¿no? ¿Qué pasa? Que hay múltiples millones, hay mucha diversidad de usuarios y usuarias. Entonces, pues, tienes que plantearlo de manera que puedas satisfacer el mayor número de usuarios y usuarios posibles, ¿no? Y que sea fácil de utilizar para el mayor número de personas posibles y que sea agradable, ¿no? Porque aunque sea fácil de utilizar, si luego es, no sé, desagradable, digamos. Me he ido al contrario, ¿no?

[No identificado] (00:16:40): No sé, todos nos acordamos de los típicos programas estos de los 90 llenos de botones y demás. Pues, se hace un peñazo usarla, sinceramente. Entonces, cuanto más sencilla, es decir, cuanto menos tenga que pensar el usuario o la usuaria, pues, mucho mejor, ¿no? Sí, sí, sí. Porque justo ahora que nombrabas las aplicaciones de los 90, me acuerdo, pantallas llenas de botones y pensadas precisamente por desarrolladores y desarrolladoras que, no, pero sí está claro, si tienes el botón en pantalla y le das a crear y debajo tienes eliminar y después tienes modificar. O sea, esto lleno de botones.

[No identificado] (00:17:19): O sea, a ver, cuando son pocos mal que bien, pero cuando son tantos, al final el usuario no entiende qué es esa acción dentro de ese contexto. Que a lo mejor hay veces que tú dices, oye, más intuitivo dar dos pasos y que quede bien diferenciado a hacerlo todo de una. O sea… Sí, sí, sí. Y ya imagínate ahora con los móviles, ¿no? Que tienes un espacio reducido, tienes que tener una precisión y una economía de lo que muestras. Es decir, tienes que ser súper preciso. Entonces es un campo súper delicado y por eso digo, personas más inteligentes que yo

[No identificado] (00:17:57): Son las que deciden este tipo de cosas porque lo mío es el código, ¿no? Pero bueno, yo muchas veces pues me explican, mira, esto está hecho así, por esto, por esto. Y después, qué lógica, qué razón. Nunca se me habría ocurrido. Es que yo soy malísima para ese tipo de cosas, para el diseño y demás.

[No identificado] (00:18:15): Y es una pasada, ¿no? Todo lo que hay detrás porque tú al final ves, pues eso, ves una pantalla y hay un trabajo detrás inmenso. Es decir, detrás de esa pantalla pueden haber otras cuatro o cinco que se han probado con usuarios y usuarias.

[No identificado] (00:18:29): Entrevistas.

[No identificado] (00:18:31): Vamos, hay un trabajo enorme, ¿no? Sí, sí, sí, sí, sí, sí. Y las que no se ven. Y las que no se ven, las que no llegan a la vida.

[No identificado] (00:18:42): O las que por motivo X están súper escondidas porque solo utilizan dos personas en concreto y tampoco hace falta que sean el flow principal de los usuarios. Y tú dices, y a lo mejor esas son las más complejas para dos usuarios, sí, pero son las más necesarias porque a lo mejor son las que usan o son las que mayor ingreso generan o lo que sea. Pero te preguntaba también por este tema de UX, por un tema que a mí me van a vetar hoy del canal de internet porque yo soy muy partícipe de hacer mobile first, ¿no?

[No identificado] (00:19:16): De, oye, pues primero haz las aplicaciones web responsive y demás. Pero sí que es cierto que cuando trabajas en web, que es mucho el ámbito en el que yo trabajo, cuando trabajas en a lo mejor aplicaciones para empresas que tienen su intranet, que seamos realistas, esas aplicaciones jamás de los jamases las van a utilizar en una tablet o en un móvil porque necesitan una VPN y a nivel de infraestructura pues acaba siendo un lío y te entrate y dicen, mira, esta aplicación jamás de los jamases va a ser móvil y cuando tenga que serlo prácticamente vamos a cambiar el software entero

[No identificado] (00:19:55): Porque los requisitos van a ser distintos, ¿no? Entonces cuando trabajas en web y en formato escritorio tienes todavía cierta flexibilidad más a la hora de conocer a los usuarios como operan o no. Y tienes más, sí, realmente lo que tienes es más espacio en pantalla para poder hacer cositas, pero cuando tu tamaño… Porque también es peligroso, ¿eh? Que tener mucho espacio hace que llenes el espacio y a lo mejor no te interesa llenar el espacio. Correcto, correcto, correcto. Ahí justo quería llevar, ahí justo quería llegar porque al trabajar en formato móvil

[No identificado] (00:20:27): Porque tú eres desarrolladora Android, bueno, no sé si Android o también trabajas en iOS, pero… No, no más Android 99,999% de Android. Exacto, y lo que queda por ahí al final acaba siendo 6M++ para librería… No, es broma.

[No identificado] (00:20:46): Ensamblador. Ensamblador, para conectarte bien a la cámara y al GPS y…

[No identificado] (00:20:52): Para conectarte con las entrañas de la Tierra directamente. Sí, la conexión Wi-Fi ya no existe, va todo por esporas.

[No identificado] (00:21:01): No, pero que tienes esa perspectiva que, por lo menos a mí, y seguramente a muchas personas se les acaba escapando también, ¿no? Que es como en una pantalla tan reducida tienes que tener tantos factores en cuenta, pues, porque te lo pasa, ¿no? Entonces, al final, dígase porque estás trabajando en ello, por esporas también, porque alguien te lo dice y tú te vas quedando con acopla o tal, pues, creo que tienes esa experiencia real que a lo mejor personas como yo que trabajamos más en formato escritorio, aunque de vez en cuando tocamos móvil, pues, pues está más ahí, ¿no?

[No identificado] (00:21:35): Y creo que al final tú estás más cercana a los usuarios de lo que puedo estar yo. Y era… Bueno, cada uno tenemos nuestros usuarios, ¿no? Digamos, que al final, como, va a ser una persona la que va a utilizar el software, entonces…

[No identificado] (00:21:53): ¿Qué pasa? Que a lo mejor si estás trabajando para empresas es más fácil y tocarle el hombre y decirle, mira, ¿qué te parece? Sí. ¿Tú qué harías? ¿Tú qué harías para hacer una factura? A ver, ¿cómo harías tú? Y te quedas con la copla, ¿no? Pero cuando son muchos, cuando son, yo qué sé, 200.000 personas o incluso millones de personas es muy difícil, ¿no? Saber que… Claro, claro, porque justo no había caído en esa parte, o sea, totalmente cuando nosotros tenemos un problema, bien nos lo abramos con el manager, o vamos directamente al usuario, ¿no? Al que ha reportado la issue o lo que sea.

[No identificado] (00:22:26): Pero en vuestro caso, ¿no?

[No identificado] (00:22:30): Si no es una aplicación privada, si no es una aplicación pública en la App Store, pues… Millones de usuarios conectados ahí en simultáneo, usándola y demás. En esos casos, pues para las personas no iniciadas o que van a entrar en el sector, ¿cómo pedís ese tipo de feedback? ¿Tenéis algún tipo de testing, algún mecanismo? ¿Cómo se recoge toda esa información? Bueno, es un poquito parecido a cómo se haría, ¿no? En persona. A ver, hay una parte que es parecida, ¿no? Hay dos maneras de recabar esa información. Una es con entrevistas, es decir, tú sacas… Puedes hacerla antes o después de sacar la feature, ¿no?

[No identificado] (00:23:11): Es lo que se llama el análisis, si no lo digo mal, cualitativo. Entonces tú ahí, pues recoge, ves cómo lo usa la persona, te dice las dudas que puede tener, le enseña una pantalla, a lo mejor dice, ¿qué entiende usted de esta pantalla, no? ¿Qué es lo que ve aquí?

[No identificado] (00:23:28): Y bueno, ahí te ayuda también, pues eso, a descartar cosas, a definirlo de la manera que lo puedan entender mejor, ¿no? Y luego está el otro análisis, que ya es más masivo, ¿no? Digamos, porque claro, tú las entrevistas las puedes hacer con una muestra pequeña de usuarios y usuarias, ¿no? Pero no puedes hacerlas con una gran cantidad, ¿no?

[No identificado] (00:23:50): Por tiempo, más que nada. Tiempo, recursos, lo que sea, ¿no?

[No identificado] (00:23:54): Entonces, cuando ya tienes bastante claro, ¿no? Lo que quieres hacer, pues se suele hacer lo que se llama el A-B testing, ¿no? Y el A-B testing lo que consiste es, pues tiene dos opciones de tu feature

[No identificado] (00:24:08): Y separa dos grupos de usuarios. A uno le muestras esta opción y a otro le muestras la otra opción, ¿no? Y entonces, por medio de tracking y viendo cómo van respondiendo, si la usan, si no la usan, si ves que entran y no completan el journey de la future, en plan de, pues tiene que irte la pantalla A a la pantalla C y ves que se caen a medias, en plan de, pues ahí puede haber algún problema y demás. Pues con eso, pues después vas comparando, ¿no? A veces, bueno, a veces los A-B testing se hacen con dos opciones diferentes

[No identificado] (00:24:39): O simplemente a un grupo se le activa la opción nueva, al otro no y vas viendo, ¿no? Como, pues si se mueven las métricas de determinada manera, pues sabes que puede tener éxito el hecho de poner la future en el mercado, ¿no? En tu producto. Claro. Y se puede dar el caso también de que precisamente montes ese A-B testing y eso no acabe cuajando y tengas que volver para atrás. Por supuesto, por supuesto, eso pasa también. Ostras, y en ese momento, o sea, no sé si te ha pasado en el día a día, pero típica frase también de desarrolladores de

[No identificado] (00:25:19): ¡Buah! Es que ahora hay que volver a hacer esto, hay que rehacerlo, ¿no? Me imagino que cuando esto pasa con el A-B testing también te, o sea, puede llegar a causar cierta frustración, ¿no? Una nueva interfaz, un nuevo diseño que, pues te has currado durante X, una semana, dos, tres, incluso si es muy largo, pues al final decir, no ha salido, hay que rehacerlo de nuevo, ¿no? O sea, ¿cómo gestionas eso? ¿Te causa frustración o al final es algo que interiorizas y no…? Hombre, yo creo que al principio de mi carrera sí me causaba más frustración

[No identificado] (00:25:55): Y era la típica persona que dejaba comentado código, en plan de por si acaso, porque a mí me gustaba mucho cómo estaba. Pero no, o sea, a lo largo de los años yo creo que aprendes a desvincularte un poco del código que haces, ¿no? Porque al final tú no eres tu código, tú eres tú, digamos, ¿no?

[No identificado] (00:26:14): Entonces, nada, cuando hay que echar para atrás código, yo creo que a día de hoy uno de los mayores placeres que he encontrado es borrar código. Es decir, cuando tú creas un commit donde hay más líneas borradas que líneas añadidas, eso es maravilloso. Entonces, no lo veo como algo negativo a día de hoy, ¿vale? Que simplemente es un… Es decir, es evolución del código, es un… Estamos… Cuando trabajamos en software estamos permanentemente como en un… ¿Cómo se diría? En un ciclo evolutivo del software, a ver dónde sale, ¿no? Todo es un… Entonces el software va evolucionando, va iterando, va cambiando y hay que aceptarlo.

[No identificado] (00:26:52): Pero bueno, teniendo claro ese software, ¿tus software no eres tú, sabes? Tus líneas de código son… Yo de hecho me vinculo muy rápidamente de mis líneas de código porque cuando hago algo, al día siguiente ya ni siquiera me acuerdo de lo que… Muchas veces de lo que había hecho, ¿no? De hecho muchas veces veo cosas y digo yo, ay, ¿a quién se le ocurriría esto? Joder, qué guay tal, viro el play y digo, ¿en serio que fui yo? Sí. Yo creo que eso después de unos años, yo recuerdo también que al principio era como… Yo cualquier línea de código que haya escrito no necesito bling.

[No identificado] (00:27:25): De hecho me acuerdo, o sea, voy a ir más allá, que yo ni siquiera… Cuando empezamos ni siquiera teníamos git, trabajábamos con subversion, con un plugin de Eclipse, que aquello… ¡Buah!

[No identificado] (00:27:37): Digamos que era maravilloso irónicamente. Nosotros hacíamos código y realmente, o sea, era la memoria. No, no, esto lo hice yo y lo hice por esto, por esto, por esto, por esto. Seguro, seguro, seguro. Y me acordaba perfectamente, a día de hoy, yo creo que ya he escrito tantas malditas líneas de código, que me pasa como a ti, o sea, yo miro y digo, no lo sé, ¿quién hizo esto? ¿De quién fue esta idea? ¿A quién se le ocurrió? Ah, fui yo. Tras, ya te vale, ¿no? Y la inversa también de, tras, qué bonito está esto, qué maravilloso. ¿Quién se le ocurrió?

[No identificado] (00:28:09): Ah, vaya, he sido yo. Sí, sí, sí, sí. Y a veces tengo la sensación de que la Gema del tiempo pasado programaba mejor que la Gema del futuro, porque a veces me encuentro cosas y digo, joder, cómo se me ocurrió hacer esto, tío. Sí, hay momentos así. Y también tenemos, o sea, nosotros hemos creado un meme interno, ¿vale? En el proyecto en el que estamos ahora.

[No identificado] (00:28:34): Que básicamente es less code, less bugs. O sea, cuanto menos código, menos bugs. Te los cepillas. Y últimamente hemos estado haciendo una limpieza bastante interesante barra intensa. Porque no hemos hecho AV testing, pero resulta que muchas de las funcionalidades, pues directamente los usuarios decían, es que no los usamos. Fue como, ah. Y el manager dijo, mira, nos los cepillamos. Y ha sido un gustazo empezar. Esto, fuera, esto, fuera. Ah, y esto que no, porque erróneamente desarrollamos una dependencia y… Vaya, ya no está esa dependencia. Podemos refactorizar el… Vaya, y hemos pegado un hachazo que, bueno, ahora da gusto.

[No identificado] (00:29:18): Pero también ahí se ha ido código que decía, bueno, esto era para enmarcar, pero ya quedará por ahí para los históricos del git. Que cuando alguien se aburra, pues lo tenga por ahí para curiosear. Total, pero es verdad. Es placentero cuando tienes que borrar código. Yo estoy totalmente de acuerdo con lo que dicen ustedes de menos código, menos bugs. Sí. Es decir, cuánto… A ver, siempre que sea elegible, claro, porque luego hay personas que… Sí. Vamos, un popular opinión. Bueno, lo económico del lenguaje no significa que sea bien, ¿no? En plan de… Mejor que se entienda.

[No identificado] (00:30:00): Si tienes que escribir una línea más, pues mejor que se entienda, ¿no?

[No identificado] (00:30:04): Pero si hay algo que ya no estás usando y que estás estorbando, pues borralo y ya está. Sí. De hecho, aquí viene la segunda coletilla de la frase de no code… Perdón, less code, less bug, que es no code, no bugs. Que es directamente, si no tienes código no vas a tener errores. Totalmente. Pero sí, yendo un poco por esta línea de la elegibilidad del código, o sea, el gran olvidado. Muchas veces sí que es cierto que hay aplicaciones donde no puedes contemplarlo todo, ¿no? Hay aplicaciones como puede ser el caso de la criptografía, donde tienes que primar mucho lo que es la performance

[No identificado] (00:30:40): Y no te queda otra que decir, bueno, por la maraña esta de código vamos a intentar de mantener la medida elegible, pero es que en cuanto a performance implica mucho. Pero teniendo en cuenta los pedazos de dispositivos que existen hoy en día, los ordenadores, las tablets y los móviles, creo que generalmente el performance no suele ser uno de los problemas y vale más primar en ahorrar tiempo al desarrollador y desarrolladora cuando tenga que tocar un código que lo entiende, que sea elegible, que no siempre afecta al performance,

[No identificado] (00:31:13): Pero bueno, yéndonos al extremo de hay que hacer unos buclos que se entienda frente a que tarde 30 milisegundos más. Porque es total. O sea, es que lo pones en la balanza y dices 30 milisegundos más de ejecución de un código que no se va a ejecutar. Ah, ¿cuántas veces va a tener que pasar alguien por aquí? Intentar entender qué es lo que ocurre y después modificarlo para… Lo pones en la balanza y dices, mira, económicamente la empresa está teniendo pérdidas. No porque la aplicación tarde 30 milésimas de segundo más, sino porque cada vez que alguien pasa por ese código se pierden dos horas.

[No identificado] (00:31:51): Exacto, es que de que te sirve tener una performance súper optimizada, si luego eso, cada vez que cambias ahí, vas a tener un bug o… Total, total, total. Es que, total.

[No identificado] (00:32:03): Y después, que además suelen ser los típicos códigos que acaban en no están probados o tenían un test que acaba siendo comentado porque no hay quien lo mantenga, porque no entiende el código y no sabe qué hace eso. O se acaba borrando el test, la gente, el equipo acaba cambiándose. Que al final les acaba convirtiéndose en el código que nadie quiere tocar. Y eso acaba matando los proyectos a la larga. Y a los desarrolladores y desarrolladoras.

[No identificado] (00:32:34): Sí. A base de… Sí. De microinfarto. Sí, sí, sí, sí, sí, sí, sí, sí. Totalmente de acuerdo. O sea, yo voy a hacer aquí apología a… Todo este pelo que falta se debe a…

[No identificado] (00:32:51): Código de ese estilo de… Esto… Déjalo ahí. Si funciona, no lo toques. Mejor. Vamos a ver cómo lo abordamos, ¿no? Sí. Nada, pero sí que es verdad que…

[No identificado] (00:33:05): Yo hago apología a la gente a que, por favor, no borren test. Por favor, no borren test. Si está… Sí, eso es verdad, es verdad. Si tienes que borrar… Es decir, la única vez que se borra test es cuando se borra la filter que te te va a colote. Exacto. Exacto. Exacto. Pero, no sé, seguramente tú te has encontrado ese escenario también de… Sí, claro. A mí eso sí me cabrea. O sea, a mí personalmente no es cuando borro un código que digo no se usa, bueno, o hay que rehacerlo, sino cuando llego y alguien te dice…

[No identificado] (00:33:34): He borrado este test porque realmente no lo entendía. Y es como, ostras, pues no pasa nada, refactorizamos el test, pero coméntalo, pero no lo borres, que además yo después voy con toda la seguridad de… Esto estaba cubierto por test y llegas a hacer un cambio tranquilamente y dices… Ah, pues no. O sea, también falló miedo de no revisar primero si había test, pero yo qué sé. En mi memoria estaba que había algo escrito de eso, ¿no? Pero, bueno, más y aseguro que te has encontrado con alguno de estos casos. Sí, sí, a ver, los he borrado yo misma.

[No identificado] (00:34:08): A ver, a lo mejor te ves en una situación en la que no te pasa el pipeline, tienes que sacar a producción algo, ¿no? Y hay un test que no ha dado tiempo de arreglar. Yo creo que la solución para mí en esos casos es comunicación. En plan de hablar con el equipo, mire, voy a tener que ignorar este test por hoy porque no está relacionado con lo que vamos a sacar. Pues claro, si está relacionado ya es en plan de, uy, gracias. Gracias a usted porque me has evitado salir a producción, ¿no?

[No identificado] (00:34:36): Pero si se ve claro que no está relacionado con lo que vas a sacar, pues decir, mire, voy a ignorarlo porque necesitamos sacar esto. Pues ahora, en cuanto termine de hacer esto, me pongo a ver qué es lo que está pasando, ¿no? Pero yo creo que ahí la comunicación es clave, ¿no? En plan de, al final somos un equipo, yo creo que el código es como el hijo del equipo, ¿no? Primero te digo, no te identifiques con tu código, ¿no? Pero el código, yo qué sé, hay que, formas parte de un equipo y si vas a hacer un cambio

[No identificado] (00:35:04): Así de radical, sobre todo cuando hay otras personas confiando en que ese test está ahí, ¿no? Y el día de mañana les va, porque al final los test son como el paracaídas, ¿no? Que nos ponemos en las espaldas ahí para en plan de, si no esa persona se va a tirar del avión y no le va a abrir el paracaídas, pues mira el problema que hay, ¿no? Entonces eso, comunicación y compromiso de, bueno, de que hay que arreglarlo y no ir a borrarlo, ¿no? Claro. También hay que ver la situación, ¿no? De cada persona, qué conocimientos tienes, ¿no?

[No identificado] (00:35:36): Si a lo mejor te viene alguien que ha borrado un test porque no ha logrado entenderlo, pues vamos a sentarnos con esa persona y decirle a ver, bueno, qué es lo que no has entendido, venga, vamos a hacerlo entre los dos. Para mí el per-programming es genial para ese tipo de cosas, ¿no? En plan de, venga, vamos entre los dos, lo sacamos y lo dejamos ir funcionando. Sí, y además el feedback, o sea, previo al per-programming, o sea, yo te digo, yo hago per-programming casi las ocho horas del día, o sea, para mí es un obligatorio porque yo soy muy despistado.

[No identificado] (00:36:08): Tengo que reconocerlo y a mí tanto el per-programming como los test a mí me dan la vida. Sin eso yo sería todavía ni junior, o sea, sería un trozo de cartón, pero bueno.

[No identificado] (00:36:23): Previo a eso yo creo que es súper importante porque la gente siempre se queda con la legibilidad del código, pues se olvida de que al final los test también son código, aunque digamos que no debería ser tan complejo como para tener que preocuparte de ellos, pero si debería ser legible, si un test es muy complejo de entender, ostras, pues a lo mejor es que la forma en la que estamos siguiendo para testearlo no es la adecuada, o se puede hacer otra forma más sencilla, o se pueden dar muchísimas cosas, pero que al final los test

[No identificado] (00:36:56): También tienen sus buenas prácticas y tienen sus refactores, y antes de borrarlo, ostras, pues somos un equipo, ¿no? Lo que tú decías, el código no es de nadie, que eso yo creo que está guay, ¿no? El matiz de no me identifico con mi código, pero no es mío, es de todo, es del equipo, o sea, al final es algo que todos vamos a tener que mantener, todos vamos a tener que trabajar sobre él, y no tomarlo como algo mío, personal, de decir, no, no, este es mi código,

[No identificado] (00:37:27): Esto lo he escrito yo, y esto lo mantendré yo, y esto lo has hecho tú y lo vas a mantener tú, no, para nada. No, no, no, para nada, eso luego lleva a temas difíciles de gestionar en un equipo, ¿no? Ya te digo. Y cuando llega el tema del blaming, en plan de, ¿no?, ¿por qué tú hiciste? ¿por qué tú? Ahí ya, pues, se rompen muchas cosas, ¿no?, que hay que mantener. Sí. Y es malo. La comunicación, como decías, es clave, es totalmente clave. Ya te digo, para mí, las personas que se dedican al desarrollo, deberíamos de trabajar

[No identificado] (00:38:03): Más la comunicación, porque al final es lo que estamos haciendo todo el día, estamos comunicando a través del código, nos estamos comunicando con otras personas, y si nos ponemos muy metafísicos, al final, a través de nuestro código, nos estamos comunicando con los usuarios, o sea, trabajemos la comunicación en general. Y con los desarrolladores del futuro que vendrán a usar el code base que tú has creado, y dirán, ¿y esta persona en qué estaba pensando en este momento, no? Es como que, realmente tenemos un trabajo, bueno, sabemos que dentro de 30 años, igual

[No identificado] (00:38:32): Los códigos que escribimos hoy no van a existir porque habrá otra cosa, ¿no? Pero es como que trasciende un poco a nosotros mismos, ¿no? Porque el día de mañana, pues, verán un código que hiciste con tu equipo, y será como, ah. Esta gente. ¿En qué pensaba cuando abría Kotlin ahí, creaba data clases? Si esto podía ser un silclas, ¿por qué hicieron? Tal cual, tal cual, tal cual, tal cual. Pero yo creo que incluso nosotros, ¿no? O sea, nos lo tomamos mucho a meme, pero… Cobol. O sea, Cobol. ¿Por qué hacían las cosas así? Pues, mira, la vida, las tarjetas perforadas. Que siguen usando, ¿eh?

[No identificado] (00:39:11): Que aquí…

[No identificado] (00:39:13): No me digas eso. ¿Sí? Sí, yo creo que sí. Para sistemas así, bancos y rollos de eso, yo creo que sí, sí, usando temas de estos de tarjetas perforadas. O sea, yo creo que sí. Me estás haciendo que empiece a sudar frío. Y yo pensar que le estoy dando… O sea, que estoy ingresando… Hombre, podría ser el… Si es así, puede ser el trabajo mejor pagado del mundo, porque debe haber poca gente que se dedica a eso ahora mismo, ¿no? Sí, pero como decíamos antes, creo que al final yo no quiero ser el que más cobre, sino el que más feliz esté en la normalidad.

[No identificado] (00:39:43): Totalmente, totalmente. Entonces, yo les regalo las tarjetas perforadas a la gente así, o sea, como si fuese, ¿qué tarjetas perforadas? Toma, para ti. Ala. No le veo necesidad. A ver. Total, total.

[No identificado] (00:39:55): Bueno, si nos ponemos muy sibaritas, creo que igual tienen hasta menos problemas de seguridad, ¿no? Para tocar esos códigos tiene que entrar una persona físicamente al servidor a jugar con la tarjeta perforada, o sea que… Uf, pero a mí hoy en día me quitas el autofill del ID. Tal cual. Y ya, vamos. Y el click through, el autofill y el click through. Sí, sí, sí, sí, sí. Y hasta, bueno, no sé si has trabajado mucho con él, con… Bueno, IAS, varias, ninguna patrocina. Estamos de todas patrocinio. No, pero no sé si has trabajado con Tap9, Copilot. No, no, no. Hasta uno…

[No identificado] (00:40:38): Te digo, para temas de algoritmos como tal, o sea, te ahorran tiempo porque, entre comillas, es código ya hecho, o sea, es el copy-paste y permiten que tú te centres más en precisamente eso, en comunicar bien cuáles son las funcionalidades dentro de nuestro dominio, qué nombre recibe esto, esto debería estar encapsulado aquí o no, qué relación guarda. Cuando dicen, es que este tipo de IAS nos van a quitar el trabajo. O sea, yo creo que lo van a facilitar y nos van a permitir mantener el foco en cosas que no están tan mascadas y que son más particulares de cada producto, ¿no?

[No identificado] (00:41:18): No sé cómo lo ves. Sí, sí, sí, totalmente de acuerdo. Es decir, al final yo creo que la IA viene a sustituir pues una serie de trabajos que para nosotros a día de hoy son pelinteriosos, que es en plan de… Al final día de hoy, pues seamos sinceros, ¿no? Si tienes que hacer algo medianamente así que ya sabes que existe, te vas a Google, lo buscas y te lo traes. Es decir, por ejemplo, en mi caso, ¿no? En Android para hacer listas hace falta crear una cosa que se llama Recycler View y un adapter y unas historias, ¿no?

[No identificado] (00:41:45): Y suele ser un tocho de código bastante importante, ¿no? Entonces lo normal es que te vayas y busques dónde lo has hecho otras veces o que te vayas a Google o, bueno, que lo empieces a teclear y te rellene, te la autorrellene el ID, ¿no? Pero vamos, que este tipo de IA te pueden ayudar con eso, en plan de empiezas a escribir, dices lo que es y seguro que ya te va a saber rellenar lo que tiene. Entonces te puedes dedicar a otras cosas como pensar mejor qué solución vas a hacer, pues cómo testearla, por ejemplo.

[No identificado] (00:42:18): Igual la IA también te rellena los test, no lo sé. Sí, sí, sí, sí, sí. De hecho, hay una vertiente donde quiero seguir profundizando, pero hay IA que se están empezando a plantear precisamente para que sea la IA quien plantea los test. O sea, hay mucha, o sea, en cuanto a los test al final las personas nos acabamos quedando con los básicos, ¿no? Test unitario, test de integración, test de aceptación, pero en cuanto a eso hay muchas técnicas. Hay, por ejemplo, el Property Based Testing, ¿vale? Es un approach, una forma de enfocar los test que es un poco más variable.

[No identificado] (00:42:57): Tú lo que haces es que de forma aleatoria, ¿vale? Aleatoria, define un tipo de input, como puede ser, oye, pues un objeto persona, ¿vale? Y eso puede tener sus propiedades, pero los valores de ese objeto se generan de forma aleatoria. Y dentro de esa persona que has definido se generan varias. Entonces esa propiedad se le pasa al test que te lo va generando en cada ejecución de forma random. Y tú lo que te garantizas es que tu aplicación es resiliente al fallo. Que no porque le introduzcas algo que no está planteado, funciona.

[No identificado] (00:43:34): Entonces es un tipo de test que se encuentra poco, pero que es súper útil. Tú imagínate, casos límite, con eso lo descubres enseguida. Claro. Y en base a eso, cuando ya tienes guía por ahí, que conoce cuáles son los flujos, o sea, has entrenado previamente, sabes cuáles son los flujos de uso de tu aplicación por los usuarios,

[No identificado] (00:43:56): Sabes, o sea, es capaz de generarte datos aleatorios también para, es como, tra, pues. Joder, eso estaría, está súper guay. Está guay, pero primero, invito a las personas que nos escuchan a que se informen sobre el tema, porque creo que es un terreno que está muy verde, hay mucha exploración posible. Y segundo, que me parece una locura, o sea, creo que el siguiente pasito para las personas que les mola el tema del testing, pues, tirar por ahí. Así que, nada, en un futuro, que si alguien investiga del tema o quiere hablar del tema,

[No identificado] (00:44:31): Que se venga porque es un campo de investigación que me interesa mucho y que me falta mucho que más caro.

[No identificado] (00:44:39): Pero sí, sí, sí, se puede sacar muchísimo de por ahí. Está súper interesante. Sí, sí, sí, sí. Y, mira, por ir a lo un poco, hace, creo que año y medio, dos años, que he empezado a trabajar con Kotlin, ¿vale? Yo antes, bueno, he tenido mis épocas, ¿no? Tuve mi época cuando estudiaba de odio Java, no quiero tocar Java. Por favor, no quiero hacer las prácticas en Java y quisiera Java.

[No identificado] (00:45:12): En la empresa, cuando terminé las prácticas, dije, guau, no volveré a tocar Java en la vida. Dice, espérate, que te contratamos, Java.

[No identificado] (00:45:24): Aprendí Java, escribí demás, pero ahora he estado tocando Kotlin el último año y medio. Y, bueno, al final, ya después de tantos años, como de tanto más caro y literal, ya le tengo cariño y reconozco las virtudes y también las problemáticas que tiene, ¿no? Pero Kotlin parece que es algo que en Android es muy natural, porque, de hecho, creo que ya en Android Java per se no se usa. Nosotros lo utilizamos en aplicaciones para backend, ¿no? Y las virtudes que tiene el lenguaje es maravilloso, pero no sé. ¿Cómo te sientes tú con Kotlin? ¿Le odias? ¿Le quieres? ¿Cómo lo ves? Para nada, para nada.

[No identificado] (00:46:04): Ahora a mí si me dice, ¿vuelve Java? Te digo, no. Bueno, si lo tengo que hacer, lo hago, ¿no? Si me veo obligada, pero la verdad es que a mí me encanta decir… A ver, es que yo había tocado Java, había hecho apps con Java, hice apps con OJTC.

[No identificado] (00:46:22): Eso está para darle de comer aparte. Como Cobol. Bueno, con menos agujeritos y con más corchetes. Y después aprendí Python. Y Python me gustó porque, bueno, también había hecho PHP. Dios mío.

[No identificado] (00:46:42): Entonces, conocí Python y me gustó bastante porque me resultó súper sencillito, súper claro, fácil de entender y demás. Y cuando empecé a aprender Kotlin, pues me parecía bastante, porque, bueno, tiene cosillas bastante parecidas, ¿no?

[No identificado] (00:46:58): Y, bueno, fue que me salió una oportunidad de hacer un proyecto para una empresa inglesa y dije, bueno, venga, vamos a ver qué tal. Lo voy a hacer en Kotlin en vez de hacerlo con Java, ¿no?

[No identificado] (00:47:11): Y cuanto más iba aprendiendo, pues más me iba gustando hasta el punto que es ahora mismo. Es decir, yo entré en la empresa que estoy ahora, que es Cabify. Entré, yo creo que al poco tiempo decidimos quitar ya lo que quedaba de Java de la app y dejarlo todo Kotlin. Porque todo el mundo, es decir, toda la gente que conozco, los desarrolladores de Android al menos, pues en general les suele terminar gustando más Kotlin. Todo el tema de cómo gestiona, pues la anulabilidad, el tema, pues, del subar sí, syntax este, ¿no?

[No identificado] (00:47:44): Que nos gusta mucho decir que está, es súper, me gusta decir bonito, pero es que es bonito. Es bonito, bonito. Es súper bonito y es súper agradable, ¿no? Entonces, cuando veo código en Java es un poco, uy, este código tiene muy verbose para mí ahora mismo en Java. Pero, bueno, es muy parecido. Es decir, quien sabe Java pueda aprender Kotlin perfectamente. Bueno, y tú lo habrás experimentado también. Sí, sí, sí. Tiene sus detractores, ¿eh? No te creas que a todo el mundo le gusta Kotlin. Hay gente que dice que para ellos Java está mucho mejor. Sobre todo las últimas versiones, ¿no?

[No identificado] (00:48:22): Donde ya hay temas de, pues, temas de las landas, los nulables también, ¿no? Los opcionales en Java y tal. Pero yo la verdad es que con Kotlin estoy súper contenta. No me planteo volverme. Es verdad que tiene, a ver, tiene un problemilla y es que, pues, al final, pues, las aplicaciones se generan solo una máquina virtual. ¿Qué tal, Vicky? Y se pasa a Java o se pasa, si no me equivoco, ya a Bycode. Entonces, sí es verdad que tarda más. Es decir, con respecto a rendimientos, su performance es un poquito peor que la de Java. Pero tampoco es esa gran cosa, ¿no? Que diga…

[No identificado] (00:48:59): Y luego tiene ventajas, aparte de, bueno, de lo que es la sintaxis y demás. Que se nota que es un lenguaje moderno, ¿no? Que está currado. Que, bueno, la gente de Jepprene sabe lo que hace, ¿no? Es como una mezcla entre Python y Scala, algo así. Espero que nadie se enfade porque yo no sé Scala, pero se me parece mucho. Cuando lo he visto, pues, es bastante parecido, ¿no? Sí, tiene sus cosillas. ¿Qué te digo? Y luego está el tema del multipláfono. Que ya eso ya… Con Java… Bueno, Java sí puedes instalar las diferentes máquinas y lo que tal. Pero en ellos no funciona.

[No identificado] (00:49:37): Sí. El tema de Java y el multipláfono, bueno… Está ahí. Déjemoslo. Era la promesa. Yo creo que cuando yo empecé con Java, era como la gran promesa. En plan de, no, Java… Funcionan todos los tipos de máquinas. No tienes que preocuparte, tal. No sé qué. Yo sí, pero necesito la máquina virtual. Sí, al final… Y no es la misma máquina virtual. O sea, que al final… Siempre acabas teniendo tus cosillas, ¿no? Aunque, bueno… He de decir en virtud de ellos que está bastante mitigado. Tienen sus cosillas, pero está bastante mitigado.

[No identificado] (00:50:09): Pero… Tengo que reconocer que, aunque yo soy muy amante de JavaScript y TypeScript… El código más bonito que yo he visto en mi vida… Está escrito en Kotlin. Ya sea por la syntax subar que tiene o por lo que sea… Fue en un proyecto donde además estaban instaladas las corrutinas de Kotlin.

[No identificado] (00:50:30): ¡Ostras! Aquello era una maravilla. Tú llegabas, abrías la clase, te veías todos los… Los comandes, los queries bien puestitos. Porque era una consecución de operaciones. Todo encadenadito. ¡Ostras! Tú decías… ¡Ostras! Y está maravilla. Y lo leías y además es que era… O sea, te contaba una historia. O sea, es que era maravilloso. Tú abrías el código y decías… No tengo ni idea de lo que va la aplicación. No tengo ni idea de… Es la primera vez que abro Kotlin. Pero yo estoy viendo esto y sé que llega un parámetro. Y que en base a ese parámetro va a hacer esto.

[No identificado] (00:51:00): Y luego va a ejecutar esto. Y luego va a ir a hacer esto. Y luego esto otro. Si es que lo… No entiendo. Pero ¿qué es esto? O sea… Yo creo que Kotlin es un lenguaje que, primero, tiene el tipado. Tiene el tipado fuerte. Con lo cual, good. O sea, el tipo siempre nos salva la vida. Sí, total. Tiene ese azúcar sintáctico. Que, oye, te puede costar un poquito entenderlo. Si no has visto antes, pues, programación funcional. Si no estás familiarizado con lambdas y demás. Pero llega un punto que es que cuando ya está escrito. Se lo das a una persona que no sabe programación.

[No identificado] (00:51:36): Y le dices, toma, léelo. Es que lo lee, lo lee. De hecho, para mí, ya el máximo de Kotlin. Fue cuando escribí un test en Kotlin. Y vi el tema de las template string.

[No identificado] (00:51:50): ¿Sabes? Esto de que puedes definir el texto como tal. Como nombre del método. Y decía, ostras, esto para código. De verdad. ¿Sabes? De la aplicación. No, pero para los test. Maravilloso. Y además para crearte típico fixture de. Oye, necesito recrear un escenario. Donde está esto y esto y esto y esto. Y tú dices. Esto son 300 líneas de setup. ¿En serio? Y yo, aguanta. Template de stream. Creamos no sé qué con idea, bla, bla, bla. Hacemos no sé qué con idea, bla, bla, bla. Y tú dices. ¿Esto es el setup? Y lo estoy leyendo y lo estoy leyendo. Para mí eso fue la gran magia.

[No identificado] (00:52:27): O sea, yo me enamoré de Kotlin en ese momento. Quiero TypeScript. Lo quiero. O sea, me gusta. Pero el código más bonito que yo he visto. Y que creo que es más amigable ahora mismo. Es Kotlin. O sea, sin duda alguna. No he probado a experimentar eso de programar React con Kotlin. Se puede hacer. Pero no lo he experimentado todavía.

[No identificado] (00:52:50): Yo tampoco. Yo de móvil no he salido. De hecho, en backend también. Bueno, tú lo estás usando, ¿no? En backend. Sí. Se usa. Es compatible con Spring. Y bueno, también hay otros frameworks como Kator y demás. Correcto. Lo que ya para móvil, vamos. Es que es maravilloso.

[No identificado] (00:53:06): Además, es justo lo que se ha dicho siempre, ¿no? O sea, cuando trabajas solo en un lenguaje de programación, es más fácil cambiar de contexto. O sea, igual tienes que cambiar un poquito el paradigma. Pero tampoco tanto. Por eso, yo al principio me sentía muy cómodo cuando tenía TypeScript en frontend y TypeScript en backend. Claro. Lo mismo es que lo mismo da, ¿no? Pues ahora con Kotlin, ya te digo, no he probado utilizarlo en frontend. Pero cuando puedes saltar de una aplicación móvil a un backend, pues como tú decías, con un Kator o con un Spring o lo que sea,

[No identificado] (00:53:42): El switch mental es muy cómodo. Y esas cosas se agradecen. No tienen precio ese tipo de cosas.

[No identificado] (00:53:50): Total. Bueno, pues, Gemma, ha llegado el momento de las dos preguntas random.

[No identificado] (00:53:59): ¿Estás preparada para…? No, no, no. No estoy preparada, pero es lo que toca. Bueno. No, no, no. Nunca se está preparada. Eso te iba a decir. Nunca se sabe por dónde a mí me va a venir la inspiración y por dónde voy a salir.

[No identificado] (00:54:15): Yo hago mis labores de investigación.

[No identificado] (00:54:18): Hay testigos que han dicho, ostras, rebuscaste mucho en Twitter para encontrar esa frase.

[No identificado] (00:54:24): Pero no, no, no. No he sido tan malo en esta ocasión. No he sido tan malo en esta ocasión.

[No identificado] (00:54:30): Pero creo que nos vamos a reír.

[No identificado] (00:54:33): Las personas que desarrollan Android y demás, pues, saben que hay un robotito, ¿no? Y es como al final el… También en Go tienen el…

[No identificado] (00:54:45): Gofer se llama, puede ser. Sí, sí, el muñequito. Exacto. ¿En Android tiene nombre?

[No identificado] (00:54:51): Que yo sepa, ¿no? Es decir, más allá de Android.

[No identificado] (00:54:55): Bueno. No sé. El robot de Android. El robot de Android. Yo creo que… El coleguita.

[No identificado] (00:55:02): Bueno, al final el robot lo acaban… Le acaban haciendo de todo, ¿no? Falta que le hagan un Funko Pop porque lo visten de todo. Entonces, para representar a Gema Socorro. ¿Cómo crees que ese robot representaría mejor a Gema? Como así, visual drawing. ¿Cómo lo vestimos? Exacto. ¿Cómo lo vestimos? ¿Qué atrezo le ponemos?

[No identificado] (00:55:28): Pues tendría un móvil, por supuesto.

[No identificado] (00:55:33): Tendría un móvil porque Gema trabaja con móviles.

[No identificado] (00:55:38): Algo relacionado con la música porque, bueno, se mueve por ahí, ¿no?

[No identificado] (00:55:44): No sé. Si le pongo una cosa de cada hobby que tengo, igual se cae al suelo, ¿no? Pero… Bueno. Bueno, vamos a ponerle un… Ponerle el violonchelo que es mi instrumento favorito. Y es el que sé tocar.

[No identificado] (00:56:00): Tendría, pues, también una pequeña familia de Android alrededor.

[No identificado] (00:56:05): Porque estoy como definiendo…

[No identificado] (00:56:08): Estoy haciendo la pregunta al principio pero con un muñequito. ¿Has visto? ¿Has visto? Y tendría un ordenador, obviamente, en la mano, ¿no? Y una falda de colores porque a mí me encanta ir así vestida de forma muy alegre. Y no mucho más, no sé. Bueno, oye, yo creo que es una buena respuesta para ser la primera. O sea que… Bien, bien, bien. Bien hilado, bien hilado. Esta es la de romper el hielo, ¿no? Después viene la… Generalmente la gente siempre dice que la primera es la más difícil. Sí. No sé. Yo al final tiro un dado.

[No identificado] (00:56:44): Así como las personas que juegan a rol, yo tiro un dado. Y digo, bueno, pues… A lo que salga precisamente por esos Ramos, ¿no?

[No identificado] (00:56:52): Mira, pues justo que has hablado del violonchelo, tal cual me compartiste cámara, me vino a la inspiración divina. Y ya que has gastado la reserva de preguntarte si volverías a Java, ya dijiste que ni de coña. O sea, no tiene sentido. Hombre, te lo puedo repetir. No, no, no, no. Esa sería la fácil. Entonces ya… A ver, volvé.

[No identificado] (00:57:17): Bueno, hazmela otra de otra forma porque ahora quiero saberla, ¿no? Pero… ¿Volverías a Java? Sí, con una pistola en la… Si no… A ver, si no me queda más remedio. Pues obviamente, ¿no? Si el proyecto lo requiere, ¿para qué nos vamos a cerrar, no? Pero… Sí, pero no sería lo deseado. Sí, sí, me dan elegir, no. Exacto. Obviamente.

[No identificado] (00:57:37): Bueno, pues mira, ya que tienes un violonchelo detrás… ¿Dónde está el violín chinito? Yo lo tapo allá porque no…

[No identificado] (00:57:47): No se ve. Bueno, de todos modos, igualmente las personas que nos están escuchando no lo van a saber. Es verdad, verdad. Se lo narramos, no pasa nada.

[No identificado] (00:57:56): Esta va a ser muy parecida, pero me resulta interesante porque la gente se acaba liando.

[No identificado] (00:58:02): ¿Qué canción tocarías cuando has comentado los test para llegar a producción? O sea, es decir… Acaba de llegar el momento donde voy a subir a producción y justo eso que nos narrabas antes, ¿no? De… He tenido que comentar un test. Entonces, Gema llega por detrás, coge y empieza… Niña, niña, niña. ¿Qué canción sería? Cuéntanos. Una triste, ¿no? Ni, ni, niña. Entiendo el problema, pero vamos a ponernos todos tristes.

[No identificado] (00:58:39): Pero, no sé, no sé. A Chelo, por ejemplo, pues… No sé si es una típica así, tristilla…

[No identificado] (00:58:47): No sé, cualquiera de Bach, porque ese hombre, el pobre…

[No identificado] (00:58:51): Ostras, sí. Estaba un poquito deprimido, yo creo que sí. Merece la ocasión. Bueno, bueno, tenía sus cosas, ¿eh? Que dice que tuvo una vida bastante intensa, sobre todo en el sentido sentimental, digamos.

[No identificado] (00:59:04): Pero… Bueno. Pero bueno. Una de mis favoritas… ¿Cómo te puedo decir? Una de mis favoritas, por ejemplo, que es la de… La de Mary Gow… A ver… Ahora no me acuerdo cómo se llama, pero es la de… La de la película de Estudio Ghibli… La del Castillo Ambulante. Vale. Mertil… No sé qué, Oslife. No me acuerdo cómo se llama. Del nombre no tengo ni idea, pero acabas de decir las palabras claves que es Castillo Ambulante. O sea, ya sé. Sí, ya sabes cuál es. Pues esa la podría tocar, aunque no es muy triste, ¿eh? Esa es bastante alegre.

[No identificado] (00:59:38): Dentro de lo que cabe en Estudio Ghibli, pero… Bueno, digamos que es ese momento no tan triste de… Bueno, lo estoy haciendo, pero el equipo está de acuerdo de que lo hagamos. Sí, exacto, exacto. Bueno, venga, vamos a la aventura. Hemos subido a producción. Algo así, ¿no? Sí, sí, sí, exacto.

[No identificado] (00:59:56): Qué bueno. Pues, oye, Gemma, ha sido un auténtico honor y un placer estar aquí contigo. Me lo he pasado súper bien. Creo que… Ha salido una charla bastante amena. Constructiva, sobre todo. Porque hemos tocado temas, pues…

[No identificado] (01:00:14): Técnicos, de comunicación, de equipos, de personas. Que al final es lo que está ahí. Y creo que… Que con una sonrisa por medio, que es una de las cosas que te caracteriza mucho. Siempre que te veo, te veo con esa sonrisa de lado a lado. Y me encanta eso que transmites. Así que muchísimas gracias por estar aquí, de verdad. Un auténtico placer. Muchas gracias a ti por invitarme. Y nada, a mí también se me pasó volando, ¿eh? Yo no sé ni cuánto tiempo llevamos aquí. Me he puesto profunda desde el minuto cero. Hablando de los valores de las personas y demás. Lo siento mucho.

[No identificado] (01:00:48): Pero bueno, al final es lo que hay, ¿no? No, bueno, al final… Ya te digo, a mí me ha encantado. Creo que ha sido el tono. Y al final también es un poco como tú te sientes, ¿no? Igual esta entrevista, si la hubiésemos hecho en otro momento, hubiese hablado de otras cosas. Pero es lo que toca ahora. Y es la Gema de hoy. Mañana igual. No, no, y es Gema.

[No identificado] (01:01:14): Ya está, yo creo que eso es lo importante y es la esencia. Está súper bien. La verdad es que eso se me ha ido volando. Y bueno, a quien quiera venir, que bueno, que no lo duden, ¿no? Que es súper entretenido y súper interesante, ¿no? El debate que se genera y la conversación. Pues muchísimas gracias. Para el 26. Y al 25 es mío, lo siento. Ah, está asignado. Ya es… No puede ser. Es de Gema Socorro. Vas a tener el numerito ahí para ti. Nada. Lo que te digo, muchísimas gracias por las palabras.

[No identificado] (01:01:47): Que al final todo esto a mí también me motiva a seguir cada día. Y bueno, pues lo agradezco un montón. Y a todas las personas que nos están viendo, que nos están escuchando. Recordad que hay que tocar el violonchelo. Cuando subimos ese teja comentado a producción o eliminado. Es broma. Hay que tener cuidado con ese tipo de cosas. Pero oye, siempre que se hace hay que hacerlo con una sonrisa como la tiene Gema en este podcast. De lado a lado y transmitiendo tan buena vibra. Así que muchísimas gracias por estar aquí. Muchísimas gracias por escucharnos. Nos vemos en el próximo episodio. Adiós. Adiós.

[No identificado] (01:02:35): Adiós. Adiós.

[No identificado] (01:02:40): Adiós.

[No identificado] (01:02:43): Adiós.

[No identificado] (01:02:45): Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós.