Mejores Prácticas con Héctor Patricio

Bueno, pues estamos otra semana más en otro capítulo más de Codeadores. Esta vez me acompaña un buen amigo, Héctor Patricio, que tiene además de un gran blog donde comparte sus experiencias y su sabiduría sobre programación, también tiene el canal de YouTube y Twitch. Y no sé si terminará abriéndote un canal de TikTok incluso, de Dojo MX.

También hay, también hay.

Y hoy vamos a hablar de algo bastante diferente porque no va a ser el lenguaje de programación, pero está muy ligado con la programación. Pues Héctor me ha dicho de podríamos enfocarlo a hablar de buenas prácticas, las mejores prácticas, best practice como dicen en inglés. Y la verdad es que me ha atraído mucho, hemos estado hablando de la idea y hoy va a ser un capítulo un poco diferente, pero yo creo que le vamos a sacar bastante partido. Pues Héctor, al principio siempre me gusta empezar, y esta parte no la voy a cambiar, por preguntarte cómo empezaste en la programación, cuáles fueron tus inicios y en qué momento decidiste me voy a dedicar a esto, no voy a ser programador.

Sí, sí, bueno, gracias por invitarme, Manuel, y me da gusto que estés haciendo este esfuerzo. Te felicito, me da mucho gusto que tengas tu tu podcast. Ya creo que le va a servir a muchas personas, sobre todo con los contactos que tienes y con la experiencia que tú tienes. Entonces te felicito. Yo, ¿cómo empecé a programar? La verdad es que esta historia la he contado en otros lados, pero fue como una progresión de las cosas que tienen que ver con la electricidad en general, ¿no? La primera cosa que me llamó la atención era la electricidad en sí misma, ¿no? La electricidad de instalación de casas, ¿no? De de instalaciones eléctricas porque mi papá, yo veía que las hacía, no. Entonces me llamaba la atención eso, pero lo estudié en la secundaria, en la escuela secundaria, y después dije no me atrajo tanto. Y después me empezó a llamar la atención la electrónica, no. Y digamos que esa fue mi carrera de, o mi carrera técnica, la carrera en la escuela preparatoria le llamamos aquí, o a nivel preparatorio, el anterior a la educación superior. Estudié lo que se llama telecomunicaciones, y en telecomunicaciones pues digamos que es una combinación de electrónica con medios de comunicación en general, o digamos que es electrónica enfocada a medios de comunicación, ¿no? Entonces aprendes un montón de electrónica, y ahí la conocí y no me gustó tampoco. O sea, no era lo que yo creía, no me gustaba para nadita. La parte que no me gusta de electrónica es depender de los objetos físicos, que son poco confiables, ¿no? Es esa parte, me frustraba mucho. Me acordaba que yo hice pocos circuitos como ya fijos, de esos de los que, de los que quemas, o más bien de los que generas con ácido y ya tienes tu tabla y sueldas, o soldas, no sé cómo decirlo, pero hice poquitos de esos, pero así un montón en protoboard. Y me acuerdo de la frustración que sentía cuando por alguno, por algún caso, alguno de los componentes fallaba, ¿no? Y entonces ahí fueron como mis principios de empezar a aprender a debuggear, ¿no? Que es ¿Cómo le haces para encontrar de todos estos 70 componentes que tienes aquí cuál es el que está fallando? Y entonces ahí es el principio de empezar a ver qué componente estaba fallando. Había veces que no quedaba más que reemplazar todo y volverlo a armar esperando que nada más fallara. Pero bueno, eso era algo que me frustraba mucho, depender mucho de los componentes físicos. Que digo que eso es parte de lo que los ingenieros de electrónica tienen que hacer en su día a día, no se deben entender métodos para ver qué está fallando y probarlo. Pero justamente en esa etapa de la escuela, un amigo estaba muy metido en la parte de computación en general, y él un día me enseñó un macro de Excel. Me dijo, mira, mira lo que puedes hacer aquí. Y me enseñó un macro en el que me saludaba. Digamos que en ese momento, en el momento en el que yo vi una pantallita con mi nombre que me saludaba, ese fue el momento en el que dije que eso es a lo que yo me quería dedicar. No sé, me llamó mucho la atención. Que pudieras tú dictarle a una computadora lo que se puede hacer, ¿no? Entonces en ese momento hizo como clic en mí eso de darle instrucciones a las computadoras. Y a partir de ahí ya, bueno, justamente fue lo que busqué después de eso, ¿no? Aprender a programar y aprender a dedicarme a la computación en general. Y justamente ya después, mi siguiente carrera o mi siguiente educación fue directamente en sistemas computacionales. Eso también siempre lo digo, digamos que ya aprendí las bases, tuve algunos buenos profesores que, o sea, yo diría que el programa estaba mal hecho, el programa educativo estaba, está un poquito mal hecho, pero tuve como 3 o 4 grandes buenos profesores que me enseñaron como las bases de lo que hago hoy, ¿no? Entonces Haz de cuenta, por ejemplo, había un maestro que de hecho nos daba ingeniería de software, que no sé, que nos mostró cómo era la vida real. Lo que hizo fue darnos un proyecto, darnos un proyecto que nos los dio con pocos, con requerimientos mal dados justamente, ¿no? Y nos dio un tiempo límite corto y nos puso en equipos a pelearnos con el proyecto, en pocas palabras, ¿no? Y eso como que nos mostró cómo eran los proyectos en la vida, en la vida real. Justamente en esa clase aprendí a programar en PHP, creo, justamente para sacar el proyecto en poquito tiempo, porque así es en la vida real. O sea, es tienes que cumplir con esto, esto es lo que te está pidiendo, y probablemente no vas a llegar a la fecha, que fue parte de lo que pasó, y nos hizo analizar eso, ¿no? Es de esa clase me acuerdo mucho, porque digamos que probablemente el maestro no sabía explicar mucho, pero sabía cómo funcionaba en la vida real y nos hizo vivirlo, ¿no? Y eso era muy bueno. Eso fue muy bueno. Y la otra clase de la que me acuerdo mucho y que me dejó marcado fue de compiladores. Compiladores, el maestro era muy bueno explicando, era muy bueno en teoría, y luego después de explicarnos la teoría nos decía implementenlo, ¿no? Y esas implementaciones las disfrutaba mucho y eran muy, este, o sea, y después de haber entendido la teoría era muy, muy bonito implementarlas. Me dejó marcado justamente porque me dejó con gusto por ese tipo de sistemas. Entonces así fue mi comienzo en la programación, y ya después pues empecé a trabajar en diferentes cosas, ¿no? Digamos que todo lo que hago hoy ya lo aprendí afuera, pero creo que esas dos experiencias en la universidad me dejaron con buena, con buen sabor de boca. ¿Cómo ves?

Estuvimos hablando en la introducción sobre buenas prácticas que es de lo que queremos hablar ahora. ¿Qué opinas tú de las buenas prácticas?

Yo creo que es una opinión no muy común, pero bueno, no muy común en, no sé si nada más en Latinoamérica o en general en el mundo, pero creo que las buenas prácticas como se conciben en el inconsciente colectivo o consciente colectivo no existen, ¿no? O sea, es, no existe una serie de recetas o una serie de pasos que puedas seguir para obtener el éxito siempre, ¿no? O sea, no existe como la regla de oro que te dice si haces esto tu proyecto va a salir bien, no, porque creo que así se conciben muchas veces las buenas prácticas, como tienes que hacer esto y si no lo haces pues tu proyecto está mal, no. Y de hecho la otra vez que empezamos a platicar de esto, Manuel, me quedé pensando en lo de buenas, no, o sea, creo que en el nombre mismo trae un error, no, que es también siempre lo menciono Pero siento que nuestra educación como latinoamericanos, bueno, tú no eres latinoamericano, pero aquí en América, y no sé, yo creo que también en España en general, está muy cargado por la educación católica cristiana, ¿no? Que tiene mucho, o tiende mucho, a tener un pensamiento bipolar, ¿no? Un pensamiento más bien dividido en dos partes, ¿no? Está el bien y está el mal, ¿no? Y ese pensamiento que te puede marcar también, te hace, tiene un nombre, un nombre este tipo de pensamiento, ¿no? Que es pensamiento como como binario. El punto es que te divide el mundo en dos partes, no, el mundo entre esto es lo bueno y esto es lo malo. Y la realidad es que digo, según experiencia en la vida, que es cuando vas creciendo, sí crees que hay bueno y malo, pero la realidad es que en el mundo más bien tiene muchos, muchos más matices, no, o sea, el rango de las cosas de lo bueno y lo malo es una serie infinita de escalas de grises, ¿no? O sea, es lo absolutamente bueno y lo absolutamente malo no existen, ¿no? Sino son todo lo que hay en el mundo está en una escala infinita de escalas de grises que son más convenientes o menos convenientes para las diferentes situaciones, ¿no? Entonces, incluso si rotas, digamos, de visión, esto que era bueno ahora es malo, ¿no? Entonces Justamente es esa etiqueta de bueno y malo creo que nos afecta, ¿no? Porque, porque, porque te puede tachar algo como, justamente es lo que te lleva a decir, vamos a empezar con las críticas, ¿no? Es lo que te lleva a decir los comentarios son malos, ¿no? Y si tachas los comentarios de malos, tu cabeza los va a querer banear de todos lados, ahora va a querer decir no quiero comentar mi código nunca, ¿no? Y entonces ese es un error, ¿no? Es un error decir que algo es malo porque lo tachas y entonces no lo quieres usar por ningún lado. Pero sí, en resumen, mi opinión es que las buenas prácticas y las malas prácticas no existen, no son cosas, este, todo es variable en pocas palabras, y eso es lo que hay que aprender.

Bueno, en inglés lo llaman como best practice, que es casi como las mejores prácticas en lugar de buena o mala, ¿no? Creo que los adalides o las personas de referencia para estas buenas prácticas podrían ser Martin Fowler o incluso el Tío Bob. ¿Qué piensas?

Sí, ese es otro punto muy interesante, que es que los seres humanos tendemos a tener como un sesgo que le llaman el efecto halo o el efecto halo, no sé cómo decirlo en español. Pero el efecto halo, que es, por ejemplo, tú te concibo como una persona y pienso que, o sea, por ejemplo, te concibo como un excelente programador, ¿no? Y luego tú me das una opinión sobre política, y como te considero buen programador, pienso que tu opinión en política también va a ser buena, ¿no? Que ese es un error, ¿no? O sea, es un error pensar que como eres un buen programador vas a ser un buen politólogo, ¿no? O un buen historiador, o un buen lo que quieras, ¿no? Ese efecto halo creo que tenemos, tendemos mucho a ponérselo a las personas, ¿no? Entonces, aunque sí creo que hay referentes que han logrado cosas, hay otros que tienen como esta aura alrededor de ellos de que todo lo que dicen es la ley, ¿no? Especialmente para los programadores, el Tío Bob, ¿no? O sea, siento que todo lo que él dice es así, se lo dijo el Tío Bob, entonces es este Es correcto y es bueno. La primera pregunta que yo tuve cuando dije por qué se respeta tanto esta persona es a ver qué hizo, ¿no? Y mi investigación me llevó a ver que no ha hecho nada relevante, ¿no? O sea, que lo que hizo fue hace mucho tiempo, y según yo no hay ningún sistema público o un sistema que podamos usar que haya hecho él o algo en lo que haya influido justamente. O sea, no es como Brian Kernighan, por ejemplo, ¿no? Que dice que participó en UNIX, ¿no? Y aquí puedes ver lo que hizo, ¿no? O que te da WK, la K es de él, no, la K es de Ajo. Este, no me acuerdo de quién es la W, pero la K es de Kernighan, no, o Dennis Ritchie, no, o este cuate Donald Knuth, no, que tiene sus libros en sus manos, o sea, sus libros con cosas muy, muy complejas en sus manos, no, en tus manos. Entonces del tío Bob no hay más que libros dando consejos de cómo programar en vez de programas reales, no. O sea, esa es una de las primeras cosas que que me llaman la atención. Martin Fowler es un caso diferente porque justamente aparte de esos consejos él tiene su empresa, ¿no? O está en la empresa que es ThoughtWorks, que ThoughtWorks tiene un gran historial de crear software que te ayuda, ¿no? Entonces no es el caso con el Tío Bob. El Tío Bob, te digo, si te pones a buscar qué ha hecho de programas relevantes, no encuentras nada más que sus libros con consejos. O sea, son como estos. Gurús que se han hecho ricos con consejos y con concursos, no, en vez de realmente con cosas que, de las que hablan sobre sus consejos, no. Y la otra cosa es, especialmente te digo con los del Tío Bo, te das cuenta de que sus consejos han envejecido muy mal, no. Y la manera categórica en la que los dice, que esto es bueno y esto es malo, son, son, es una de las cosas que más dañinas se me hace para la industria, no. Porque justamente es que es común, es como un metaefecto, es como un efecto aparte de sus consejos, es categorizar las cosas inmediatamente de esto se tiene que hacer así y así tiene que ser siempre. Te lleva a que otros piensen igual que tú. Y entonces justamente te invito a cualquiera que esté haciendo esto, le invito a hacer el experimento, que ponga en Twitter o en algún lugar público que esté que está mal alguna, alguna de las cosas que se consideran buenas prácticas, y vean cómo en vez de entrar en un diálogo entran en ser atacados, ¿no? O sea, por ejemplo, vi la parte de alguien un día publicó que era una buena idea a veces, bueno, no lo puso así, también lo puso de una manera un poquito más, este, más categórica, de puso no uses foreign keys, ¿no? Y entonces Creo que, creo que la manera en que lo escribió, este, invitó a que lo atacaran. Pero en vez de entrar en un diálogo constructivo y ponerse a pensar en qué casos no conviene usar foreign keys, que no es algo descabellado la verdad, o sea, y creo que tú lo sabes, Manuel, no, o sea, hay casos en los que no usar foreign keys, y de hecho hay sistemas que viven sin foreign keys, no, te puede ayudar a justamente tener mejor performance o hacer otras cosas. Claro, con los trade-offs que lleva desactivar o no tener foreign keys. Pero en vez de entrar en ese tipo de conversación, como tener foreign keys se considera una buena práctica, entonces lo que pasó fue que lo empezaron a atacar personalmente y le empezaron a decir de cosas como este cuate no sabe nada y cosas similares, ¿no? Entonces, a lo que voy con eso es que la manera en la que comunicas las cosas es muy importante porque te puede llevar a que en vez de abrir el diálogo te puede llevar a ataques o a completamente cerrar, digamos, que las las, la comunicación, no, que es parte de lo que según yo y lo que he leído del Tío Bob él fomenta, no, o sea, porque él te habla categóricamente de las cosas en vez de hablar de cosas o de ponerle matices a las cosas, que es muy importante.

Sí, parece que más que una serie de normas o reglas propulsando un dogma que tienes que seguir y no cuestionar, porque esa es la forma de hacerlo. Por otro lado, yo recuerdo que cuando estuvimos hablando del libro de John Ousterhout, el libro, aunque tiene también muchas anotaciones en base a cómo hacer mejor el diseño de software, lo notaba menos categórico, como dices tú, de las cosas que puedes encontrar en Clean Code. En este caso, porque daba un razonamiento previo, que creo que esa es la parte importante, y después te explicaba cuándo es bueno y cuándo es malo. Entonces te muestra, como tú decías, la escala de grises y te deja elegir. No te dice que es bueno ni malo, sino que sepas que si lo haces tiene estas ventajas y estos inconvenientes, y si no lo haces pues tiene estas ventajas y estos inconvenientes. Quizás plantear ese tipo de normas de, como decías tú, el caso de los comentarios. Comentarios, sí, bueno, si pones demasiados pues tiene esta parte negativa, si no pones ninguno pues tiene esta parte negativa, si pones lo suficiente o los escribes bien tiene esta parte positiva, si no los pones en esta parte y te enfocas de otra forma en escribir el código pues tiene esta parte positiva. Entonces claro, sería ir navegando por todas las posibilidades y dar tu opinión Pero no decir no pongas comentarios, que parece como una norma.

Sí, sí, sí. O sea, y te digo que lo que se me hace peor de esto es el, sí, el consejo en sí mismo puede tener resultados negativos y nos ha llevado muchos resultados negativos. Eso de no pongas comentarios nos ha llevado a variables con nombres de 200 caracteres, ¿no? Y cosas similares, o cosas muy, muy, muy, este, o sea, yo no puedo hablar de mi experiencia porque alguien me podría decir que critico de a gratis. Pero por ejemplo, yo creo que tú también has trabajado con Magento, este, Manuel, pero siento que en ese, en ese, bueno, no sé si vayan a ver la cara de Manuel cuando contestó esto, pero son experiencias traumáticas, ¿no? Por ejemplo, trabajar con Magento, y me acuerdo de que para hacer un pequeño cambio en una funcionalidad Y no estoy exagerando, sinceramente tienes que modificar como 7 archivos diferentes, por lo menos 7 archivos diferentes para hacer diferentes cambios. Tienes que modificar el facade y el template y luego no sé qué otras cosas. Y eso es esa fragmentación, por ejemplo, es llevar al extremo este tipo de cosas de no hagas funciones largas, por ejemplo, no. Entonces, o que se siguen de manera rígida sin pensar si realmente conviene o no. No. Entonces ese es como la primera capa del daño que hacen, no. Es el consejo está llevando a hacer cosas raras a la gente que lo está siguiendo sin pensar seriamente en él, no. Y luego que seas tan categórico te está llevando a un segundo nivel de daño que yo creo que es un poquito más dañino todavía, que es te está haciendo pensar que hay reglas que se tienen que seguir de manera rígida sin ponerle un poquito de pensamiento tú, no. Y eso tú mismo lo pregonas y entramos en este tipo de de guerras en las que la gente no escucha realmente lo que, lo que ni siquiera puede observar, ¿no? Y creo que la verdad sí creo que esto es un poquito de pereza mental, ¿no? Porque, porque eso lo digo siempre cuando platico con alumnos, casi siempre la respuesta es de todo es depende, ¿no? O sea, y eso no hacen burla a los seniors de que decimos que todo, o sea, de hecho dicen que uno lo aprende a decir depende, ya lo promueven a ingeniero senior, no. Pero, pero yo digo que el depende también es una respuesta, es una respuesta floja, no es una respuesta que no depende, no es una respuesta. Siempre que tú digas depende tienes que decir una de dos: si ya tienes la información de qué depende y a qué te lleva cada caso, o sea, por ejemplo ¿Qué base de datos voy a usar? No, depende de la cantidad, bueno, del tipo de información que vayas a guardar. No, si vas a usar este tipo de información, tal base de datos, y si vas a usar este tipo de información, tal otra base de datos. No, o si no tienes la información correcta, es depende y preguntar la información que te falta. No, o sea, nunca te vas a quedar en un depende, no. Pero, pero justamente es eso, es lo que es lo que la gente experimentada aprenden que no hay respuestas absolutas, sino las respuestas siempre están modificadas por tu contexto y por los matices del contexto en sí mismo.

Cambiando un poquillo de tema, pero no del todo, me gusta, o sea, me gustaría saber, porque nunca te lo he oído responder, sobre referentes. Pues ya sabemos que el Tío Bob no es uno de ellos, sería incluso un antirreferente. Pero, ¿cuál considerarías que son tus referentes en la informática a la hora de decir, pues mira, he leído código de estas personas o sigo los comentarios que hacen porque me gustan sus opiniones? ¿Cuáles serían esos referentes que tienes tú o de los que has bebido mucho?

Sí, principalmente uno de los más como claros que tengo es Jon Osterhout, justamente el Jon Osterhout del que escribió este libro de A Philosophy of Software Design. Ese se me hace un mucho mejor libro que Clean Code para referencias en cuanto a diseño de código. Me gusta mucho que habla de sus propios errores, o sea, que dice, ah, cuando yo estaba haciendo este sistema me equivoqué aquí por, o sea, justamente aprendí de mis errores y como lo hubiera hecho diferente es así, ¿no? Me gustó mucho porque de hecho ese libro como que digamos que puso en mí lo del pensamiento modular, ¿no? Lo del pensamiento modular de que se me hace uno de los principios fundamentales del diseño de software, aprender a hacer buenos, buenos módulos. Déjame pensar en algún otro referente que tenga. Creo que no tengo como nombres claros, pero bases de código, una de las bases de código que más me llama la atención es la de Django, que creo que lo hicieron muy bien en general respecto a Todo este tipo de cosas, justamente cómo hacerlo de la manera más clara y más explícita posible, siguiendo como los lineamientos de Python. Y algún otro nombre que tenga presente, déjame pensar, el libro de Go, el libro de Go se llama The Go Programming Language, que escribió Rob Pike con, no me acuerdo cuál es el otro nombre. Ese libro me llama mucho la atención porque te explica Go, pero también enseña programas, y tú ves lo sencillo que los hicieron. Y se me hace una increíble referencia, no solamente respecto a Go, sino respecto a cómo programar, ¿no? Entonces es el libro de Go, les digo, a lo mejor te doy la referencia, Manuel, y tú lo pones en los enlaces. Se me hace un libro increíble, te digo, no solamente respecto a Go, sino respecto a la programación. Y el último libro, y el último como libro que traigo como fresco, es el libro de Rust. El libro de Rust me gusta mucho, se llama, ¿cómo se llama? Creo que se llama así igual, The Rust Programming Language, que escribió Steve Klavnik, o Klavnik, algo así se pronuncia su nombre. Se me hace un muy buen libro respecto a No sé si tú has programado en Rust, pero lo chistoso de Rust es que tiene, lo tiene como todas las características de todos los lenguajes que yo haya visto, ¿no? O sea, es, tiene opcionales y tiene este pattern matching y tiene excepciones y tiene todo, tiene todas las características, como que le intentaron meter todas las características de todos los lenguajes, ¿no? Y luego tiene unas extras que no había visto en otros lados, como por ejemplo lo de lo del borrow, lo del borrow, no, lo del manejo de memoria de manera segura, no. Entonces es un lenguaje que se me hace bastante como cargado de cosas, pero me gusta que en este libro te explican por qué le metieron este tipo de cosas, no. Y entonces hay algunas cosas que me llama la atención que las metieron directamente en el lenguaje en vez de ponértela como una buena práctica o como una buena idea, está clavada en el lenguaje. Como la parte, por ejemplo, de cuando haces matches, cuando haces matches, cuando haces pattern matching, te obligan a hacer pattern matching contra todas las opciones posibles. En vez de decirte es una buena idea que cheques todas las opciones, el compilador te obliga a decir no está checando esta opción, no está checando esta opción. O sea, por ejemplo, el match te obliga a que si tienes 3 tipos de datos posibles, lo hagas contra los 3 tipos de datos posibles, en vez de, en vez de este de darte, sugerírtelo, ¿no? Entonces ese libro me gusta porque te explica como principios fundamentales de la programación que están como clavados directamente en el lenguaje. O sea, no tienes opción de saltártelos y por qué existen. Entonces me gustó mucho.

Entonces han mencionado el proyecto de Django y los libros estos de Go y Rust. ¿Hay algún otro proyecto que recomendarías para aprender a programar bien? Que diga este proyecto de código tiene un código que incluso aún no siendo de tu lenguaje de programación pueda sacar muy buen partido de leer ese código?

Hay un proyecto de Go específicamente, ahorita el primero que me llega a la mente es un proyecto de Go que es como un proyecto que está hecho justamente para explicar cómo crear código mantenible, que es otro de los temas que queremos platicar, del código mantenible, pero No recuerdo ahorita el nombre, se llama, bueno, es un proyecto que es como para hacer lo, creo que lo básico, como un todo o algo similar a esto, pero justamente te explica los principios de cómo modelar bien tu dominio, modelarlo de manera lo más pura posible, y después cómo ponerle cosas encima para empezar a usar ese dominio. Ese proyecto creo que no se creó con ese objetivo de explicarte cómo hacerlo bien, pero lo hicieron también, que es una referencia en eso. Entonces no recuerdo exactamente ahorita el nombre, pero lo vamos a poner, ese, esa, ese link en las notas del episodio para que lo vean. Pero se me hace uno de los mejores referentes de cómo, cómo seguir un principio que yo creo que la mayoría de veces es útil, ¿no? Que tienes que modelar tu dominio de negocio lo más puro posible en tu lenguaje de programación y después empezarlo a decorar con cosas que lo van a usar, ¿no? Como por ejemplo decorarlo con cosas para guardarlo en la base, para persistirlo, por ejemplo, ¿no? O para mandarlo a través de la red o para lo que sea. No sé, se me hace uno de los principios que se me hacen útiles la mayoría de las veces, pero que no, como digo, no es la bala de plata que te va a resolver toda la vida, no, y que a veces te va a complicar más la vida de lo que te va a ayudar. Entonces ese es uno de los mejores bases de código que se me hacen útiles. Ahí hay un libro que se llama JavaScript Alongé. Este libro de JavaScript Alongé es un libro que explica programación funcional de manera como progresiva con JavaScript. Y lo chistoso de este libro es que te explica como conceptos de manera de lo más básico justamente a cosas muy avanzadas de programación funcional usando un lenguaje que no es puramente funcional, que es justamente JavaScript. Y al que le faltan muchas características para hacer un lenguaje de programación funcional como completo, ¿no? Entonces vas completando el lenguaje haciendo esas cosas y te enseña como desde lo más básico de programación, de programación solita, hasta programación funcional bastante avanzada. Este libro y su código, justamente su código en el que ves cómo implementó las cosas este cuate, y de manera tan, a veces muy, no compleja, sino de manera como muy que tú no te lo hubieras imaginado cómo se implementaba eso, eso como que te abre la mente, no, para después tú hacer cosas similares, no. Por ejemplo, implementa usando, haz de cuenta emulando Lisp, implementa listas directamente, no. Puedes simular Lisp con JavaScript solito, no, si usas como pares de cosas, no. Y te explica por qué, por ejemplo, por qué se llama CAR y CDR en Lisp y cosas similares, no. Entonces Este libro que se llama Si yo escriba Longuet tiene un conjunto de código que te puede como ayudarte a abrir la mente. Y creo que serían los dos ejemplos que quisiera dar.

Hablando de los personajes, también he recordado dos personajes, no sé por qué se me han venido a la mente. Uno es Linus Torvalds, que es muy conocido por el kernel de Linux y el proyecto de Git. Que curiosamente, aunque su código y su forma de trabajar es famosa por ser muy bueno, el producto, lo que produce y tal y como dirige, hace que resulte un buen producto. Sus modales dejan mucho que desear en ese sentido. Sería casi como lo que consiguen otros personajes Bueno, no sé si Bill Gates o el Tío Bob son gente un poco más educada, pero creo que no les han llamado nunca la atención a ninguno de los dos como a Linus Torvalds. Y recientemente también el creador de Ruby on Rails ha saltado bastante a la palestra. Bueno, ya lo ha ido haciendo de forma recurrente por su idea sobre empresas de mantenerlas pequeñas y no hacerlas crecer. Siempre le criticaban que Basecamp podría ser un titán tecnológico y sin embargo pues mantiene la empresa pequeña y dice que le gusta mantener ese tamaño de empresa para no zambullirse en burocracia y cosas que vienen atadas a las grandes empresas. Y también por sus polémicas con TypeScript, que le ha hecho ser casi como un ogro para la gente de TypeScript, criticando ciertas cosas. Yo creo que en este sentido, cuando alguien critica una tecnología con la que nosotros estamos muy cómodos, por ejemplo, si yo soy amante del lenguaje Java y llega alguien y dice, no, pero Java es muy burocrático, es muy malo, es muy— Entonces es casi como lo que tú decías con las buenas prácticas o mejores prácticas, que inmediatamente se toma como un ataque a esas prácticas. Tú no sabes nada, esto es lo mejor. Y termina no siendo una discusión acerca de las bondades en base a los beneficios y perjuicios que tienen esas tecnologías, sino termina siendo casi como una pelea entre fans del fútbol o fans de política actualmente. ¿Cómo ves tú esto de las polarizaciones y los amantes y odiadores de tecnología?

Sí, fíjate que mencionaste a alguien que me llama la atención. No sé, yo de hecho no soy fan de él, pero me gustan mucho sus opiniones y me gusta mucho que se sale de la regla. Este David Heinemeier Hansson, DHH, el creador de Ruby on Rails. Me gusta mucho que cuestiona justamente lo que se considera como lo mejor, y pasa exactamente lo que tú acabas de decir, que él dice no, TypeScript no sirve, no. Digo, también es un poquito categórico, pero, pero él sí puede después razonar, ¿no? Entonces pasa que dice, no, pues a nosotros TypeScript no nos sirvió justamente porque retrasó el tiempo de entrega y bla bla bla bla bla, ¿no? Y te da sus argumentos de por qué no le sirvió, pero, pero según yo nunca te dice no lo uses, ¿no? Te dice pues a nosotros no sirvió. O por ejemplo, lo mismo pasó con lo de la nube, ¿no? O sea, dice, ah, la nube nos estaba saliendo carísima y entonces lo que hicimos fue mover todos nuestros desarrollos a servidores propios, ¿no? Y estos fueron nuestros resultados, ¿no? Según yo, no te dice, bueno, lo que tiene y por lo que se gana mucho la pelea es porque es burlón, ¿no? O sea, de repente el CEO de Vercel dice algo y se burla de él, ¿no? Dice, ah, sí, mira, por ejemplo, el CEO de Vercel promueve que no debería esto nunca montar sus propios servidores, ¿no? Y entonces llega DHH y se burla y dice Pues sí, claro, porque tú ganas de que no monten sus propios servidores, ¿no? Entonces es muy chistoso porque ahí se gana la, como la pelea. Pero según yo, sus opiniones son bastante como eclécticas o bastante razonables. Me gusta mucho que cuestiona lo establecido, y creo que esa discusión de cuestionar lo establecido, cuestionar lo que se consideran como la forma de hacer las cosas como canónica, me gusta mucho porque, porque puedes llegar a nuevas innovaciones y nuevas cosas. Respecto a lo que me preguntaste, ahora sí creo que te digo, esto de atacar a las personas y de entrar en guerras santas y de entrar en posiciones rígidas de lo que yo estoy diciendo es la verdad y todo el que no esté de acuerdo conmigo está mal, creo que es un error en sí mismo de la sociedad. Y es por algo que muchas personas no les gustan lugares como Twitter, no, porque tú dices algo y en vez de que alguien te llegue a cuestionar la idea o entrar en una conversación productiva, llegan a decirte que eres un tonto y que no sabes nada y qué haces ahí, no, y que este nunca debiste haber hablado ni nacido y cosas similares, no. Entonces se me hace un error de él en sí mismo, de la comunidad, que primero te digo, tener opiniones rígidas. Me gusta mucho este concepto que se menciona constantemente en diferentes foros que se llaman opiniones fuertes débilmente mantenidas, no, débilmente agarradas, lo traduciría directamente. Entonces tú puedes tener opiniones fuertes, pero debes ser capaz de analizarlas y cambiarlas dado el caso, no, porque yo creo que eso es lo que lleva al progreso, eso es lo que históricamente hemos visto que el progreso te lleva, te lleva por más, o sea, y por más, este, poco convencionales o poco razonables que suenen los nuevos descubrimientos, creo que te deben de llevar hacia allá, ¿no? Que es como ha pasado en la ciencia, o sea, es lo de la física cuántica, por ejemplo, ¿no? Qué poco razonable le ha de haber sonado, o nos suena todavía, ¿no? Conociendo la física clásica, ¿no? La mecánica clásica. Entonces, este, creo que lo que se tiene que hacer para cambiar eso es primeramente sí tienes que tener opiniones, ¿no? Y mientras más fuertes, mejor, porque quiere decir que más has pensado en ellas, ¿no? Pero debes ser lo suficientemente abierto para primeramente razonar respecto a lo que te están diciendo los demás y de verdad escucharlos. Y segundo, poder cambiar de opinión, ¿no? Poder cambiar de idea, siempre evitando, este, te digo, la opinión, la opinión rígida o el ataque a las personas, ¿no? El ataque a decir, este, como a Manuel Rubio le gusta el reggaetón, entonces no confío en él como persona, ¿no? Porque no, no es este no es una buena idea calificar a las personas por una opinión o por un gusto. ¿Cómo ves?

Bueno, no me gusta el reggaetón, pero sí es verdad que catalogar a las personas por sus gustos no es lo ideal. Estás catalogando a las personas por sus elecciones, que en sí una elección en un proyecto o en tu carrera profesional no tiene por qué ser general o válida para todos en cualquier momento, que es lo que muchos se llevan a malentendidos. Si tú eres un programador de Android y has decidido utilizar Kotlin, no es lo mismo que ser un programador de frontend y tienes que utilizar JavaScript, o has decidido utilizar Elm, o has decidido utilizar TypeScript. Depende de la flexibilidad que te pongan en la empresa, el proyecto, de tu capacidad de decisión. Es decir, ahí hay muchos factores que determinan incluso si quieres saltar a otra empresa por tu carrera profesional. ¿Se te ha dado alguna vez el caso de que por decisiones propias de tecnología, gustos, llegas a decir, o sea, pudiese contigo ese sesgo de no, no, a mí me gusta esto porque es lo correcto y dejo esta empresa por este caso concreto, que han elegido esta tecnología y no la quiero.

No, fíjate que personalmente siempre he sido bastante abierto respecto a eso. Creo que esta pregunta me agarra un poquito como mal parado porque desde hace más o menos 8 años tengo como, yo diría que el privilegio de tener mi propia como empresa en la que casi casi yo decido las cosas, no, yo decido lo que se tiene que usar. A lo que te puedo decir que me ha llevado esa libertad justamente es a tomar malas decisiones, no, o sea, por ejemplo, a elegir un lenguaje, o sea, un lenguaje que no cuadraba con el proyecto al 100%, no, y claramente he tenido que pagar el precio de esas decisiones, no, porque aunque al principio vaya bien el proyecto, cuando lo mantienes a largo plazo las decisiones que tomaste te llegan a romper después, o te llegan a— yo les digo que te regresan a morder, no. Me lo imagino como una serpiente que da toda la vuelta y te empieza y te avienta la serpiente por adelante y llega y te muerde por atrás. Así me lo imagino, no, como el Ouroboros. No sé si lo conocen. Por eso digo que te llega a morder de regreso la propia decisión que tú aventaste, no, o que tú tomaste. Entonces Esto te digo, de que yo cambiarme como por fuertes convicciones y decir no, no voy a hacer esto, no me ha pasado, por lo menos no recientemente que me acuerde. Pero sí me ha pasado que te digo que tomo una mala decisión respecto a lo que se tiene que usar, ¿no? La más reciente que me acuerdo, la más fuerte, es respecto a ponerle un lenguaje fuertemente tipado, más bien con tipado estático, a un equipo acostumbrado a puros lenguajes dinámicos, ¿no? Nos peleamos muchísimo. Agarramos un proyecto y lo hicimos en Go. Nos resultó muy bien respecto a varias cosas, como por ejemplo el lenguaje lo aprendimos muy rápido porque es sencillo. Este, el proyecto tenía muy buen performance por justamente porque eso es lo que queríamos de Go y cosas así. Pero había cosas en las que nos peleábamos muchísimo, que tardábamos mucho más de lo que deberíamos por haber elegido un lenguaje con tipado estático, no como nuestros datos que llegaban eran muy flexibles justamente, ¿no? Y entonces haz de cuenta que cuando queremos meter datos en una estructura de datos fija con tipado estático, pues nos tenemos que pelear con, incluso con reflexión, para ver qué íbamos a hacer con este tipo de datos, ¿no? Entonces ese fue un error que me acuerdo mucho que no consideré, ¿no? Y de hecho, o sea, no, no, yo creo que no lo pude haber considerado Pero parte de lo que nos afectó es que el equipo en sí mismo estaba muy acostumbrado a lenguajes dinámicos, y entonces eso era un problema. Entonces sí, sí, o sea, me ha llegado a pasar que por tomar decisiones como de tecnología me enfrento con problemas que de otra forma se hubieran podido haber evitado, pero, pero es que yo creo que eso es uno de los de las consecuencias de sí mismo, de tomar decisiones. No todas te pueden salir bien.

Y otro recuerdo, que esta conversación la tuvimos a través de Twitter, que te compartí un vídeo precisamente del Tío Bob que decía que el uso de frameworks solo beneficia a los creadores de los frameworks. Yo considero que el framework en sí es casi como una mejor práctica, porque no sé si encajarlo como práctica o como una especie como de molde, plantilla, un proyecto que viene para fijar una serie de condiciones dentro de tu proyecto, como por ejemplo la arquitectura que vas a utilizar a partir de ahí, una serie de convenciones dadas por cada framework que viene en sí con la ideología de los creadores del framework y esperan que al utilizar ese framework pues tú sigas también utilizando esa guía de estilo, esa forma de hacer las cosas. ¿Podríamos considerar que el Tío Bob tiene razón ahí o no?

El Tío Bob nunca tiene razón. Siguiendo mis propios consejos, no, fíjate que a mí se me hace esa forma de expresarlo, incluso te digo que yo creo que No sé qué busca él, no sé si busca tener como, o sea, si su forma de expresarse siempre es tan categórica, pero no creo por ningún lado que él, o sea, en general, no, o sea, yo creo que sí hay gente que busca que te claves en su framework por razones económicas, claramente, no sé, por ejemplo, probablemente alguien que desarrolló un framework para que lo uses en su infraestructura quiera que te quedes ahí o quiera hacer lo que llamamos vendor locking, ¿no? Pero yo no creo que esto esté del lado de los frameworks, probablemente está del lado de las soluciones que te ofrecen algo, ¿no? O sea, porque una de las técnicas de marketing, digamos, una de las técnicas para vender o para mantener clientes es atraparlos en tu tecnología, ¿no? Y que entonces sea muy difícil cambiar entre la tecnología A y la tecnología B, ¿no? Lo que llamábamos justamente vendor locking. A veces eso del vendor locking no es una cosa planeada, sino es algo como natural de las soluciones, ¿no? Es yo estoy haciendo una tecnología, por ejemplo, se me ocurre con lo que Cloudflare está haciendo ahorita, ¿no? Cloudflare hace un montón de cosas que son tecnología que para ellos les resulta útil y que resulta que ningún otro proveedor tiene como su equivalente, ¿no? Y entonces si te quedas con la solución que Cloudflare te provee, con sus frameworks que Cloudflare te provee, pues estás amarrando de tú mismo una solución, no. Pero no creo que ese sea el caso justamente, por ejemplo, de cosas como Django o como Ruby on Rails o como incluso Next, no, que sí tiene un proveedor atrás. No creo que sea el caso que como conspirativamente ellos quieran tenerte dentro de su framework o quieran agarrarte por algo, porque no le veo sentido económico. O sea, Django nunca te va a cobrar por nada, no. Y entonces como que Django te atrape por algo, no creo que sea que sea su objetivo. Creo que tú mismo sí te puedes enredar. O sea, creo que el lado opuesto de esto es que tú, al empezar a usar un framework con ciertas reglas de uso y con ciertas, este, y con cierta, como cierta estructura, tú mismo te puedes clavar en la estructura y luego va a ser imposible salirte. Eso es cierto. Pero lo que no me gusta de ese statement de que los creadores de frameworks quieren tenerte ahí adentro es la intención. O sea, no es su intención tenerte ahí adentro, es simplemente te estás metiendo en esto, pues justamente lo que vas a hacer es adecuarte a la forma de trabajo de aquí. Si te quieres salir después, pues va a ser imposible, porque después, porque ya hiciste todo respecto a esta forma de trabajo, ¿no? Si te quieres cambiar de Django a Ruby on Rails, pues en primera vas a tener que cambiar de lenguaje, ¿no? Y en segunda de un montón de abstracciones y de cosas que Django tiene, ¿no? Entonces te digo, no creo que sea la intención agarrarte, sino más bien es la naturaleza de ese tipo de trabajo, ¿no? O sea, es la naturaleza de que cuando te metes en un framework vas a estar casado con sus formas de hacer las cosas, ¿no? Y más justamente pensando justamente en frameworks, ¿no? O sea, justamente los frameworks son, te dan todo para que tú te adecúes a ellos, ¿no? Y como siempre lo digo, es un trade-off. O sea, ¿qué te da el framework contra qué te quita, no? Te quita flexibilidad o la capacidad de cambiarte contra la velocidad de desarrollo inicial, no. Entonces tú tienes que evaluar si te conviene, no te conviene, no, y tu negocio y el timeline de tu producto y todo esto, no. Porque también, que yo creo que eso es lo que sugirió el Tío Bob, se me hace una tontería pensar que puedes desarrollar todo desde cero tú siempre, no. O sea, si no, si tú, este, si tú quieres hacer algo como en poco tiempo, no te vas a poner a hacerlo desde cero, no, casi casi nunca. Entonces es el, eso es en pocas palabras el trade-off que estás haciendo aquí en el uso de frameworks, es usar este algo que te va a quitar flexibilidad en el futuro contra algo que te va a permitir este desarrollar de manera más rápida y más eficiente en costos, por lo menos en el corto plazo, no. Y de hecho, algo que quiero resaltar respecto a eso es que es una ilusión, o es falso, que tu proyecto puede escalar infinitamente, ¿no? O sea, tu proyecto pueda primero escalar en usuarios y también pueda cambiar de funcionalidades infinitamente, es una ilusión. Eso no es, no pasa justamente. Porque las plataformas, digamos, están hechas para, bueno, más bien como la experiencia empírica que este Will Larson dice en un libro que se llama An Elegant Puzzle. Dice, nosotros en Uber, que tuvimos hiper, hiper scale, o sea, empezamos aquí y en 2 años estábamos al doble, y luego otros 2 años el doble, y así. Dice, nosotros lo que teníamos que hacer era rehacer la plataforma, no sé, mientras estábamos terminando de hacer una, ya estábamos empezando a hacer la otra. Porque sabíamos que esta no iba a aguantar, ¿no? Y esa forma es natural. O sea, es la idea de que un sistema puede aguantar evolución infinita o escalamiento infinito, es irrazonable, ¿no? No pasa eso en la vida real, ¿no? Tienes que rehacer las plataformas, y eso es una de las consecuencias del crecimiento, en pocas palabras, ¿no? Porque simplemente, yo creo que tú lo has vivido, Manuel, o sea, hay estructuras de datos que no van a soportar este en esta etapa del escalamiento, ¿no? Entonces, por más que lo quiera hacer aquí, tengo que rehacer la plataforma para la siguiente evolución, ¿no? Entonces tampoco creo que sea algo tan malo que te quiten flexibilidad en el largo plazo, porque probablemente vas a llegar al punto en el que de todos modos lo vas a tener que rehacer, sea así o de la otra forma, ¿no?

Totalmente de acuerdo. Otra de las cosas que me gusta cuando hablo contigo es que siempre saco ideas para nuevos libros, para nuevas lecturas. Así que al hilo de esto, y teniendo en cuenta de que, o sea, como no estamos hablando de ningún lenguaje de programación en sí, estábamos hablando al principio de que intentar ser un poco menos dogmáticos y tener más pensamiento crítico. Y hemos comentado el libro de Ousterhout, A Philosophy of Software Design, que es un gran libro para abrir un poco la mente y mejorar en lo que es el diseño de software. Clean Code nos lo recomendamos, empezamos por ahí. Pero, ¿qué otros libros? Porque yo recuerdo que hace tiempo me dijiste también otro que era el How to Solve It. De George Poilia. En esa línea, ¿qué libros crees que podrían valer la pena para gente que quiere empezar a programar pero quiere una base que sea genérica y que le ayude a resolver problemas?

Sí, sí, este, bueno, reitero la recomendación de este libro de A Philosophy of Software Design de John Ousterhout. Les digo que yo creo que tiene partes buenas y partes un poquito más flojas del libro, pero me gusta mucho su enfoque en la experiencia de la vida real de John Osterhout. Hay algunas partes que de hecho ahí yo he visto a gente criticándolas y diciendo que cómo se le ocurre decir eso, pero es lo que les digo, que no existe ninguna como bala de plata, o sea, eso de que existe una solución universal para todos los problemas no es cierto. No, no, esa es la primera cosa que tienen que quitar de la cabeza, no. Como voy a leer la Biblia del desarrollo y esta Biblia me va a guiar por todos mis caminos del desarrollo, eso no existe. Ni John Osterhout lo ha escrito, ni el Tío Bob. O sea, incluso yo quiero decir esto de que aunque siempre ando bacheando al libro de Clint Coates, y de hecho lo dicen muchos, dicen yo lo leí y no me gustó, pero tiene cosas rescatables. Y claro que sí tiene cosas rescatables, no. Pero no sé si leer un libro de 800 páginas para sacar 2 o 3 consejos buenos te convenga, y eso es lo que no recomendamos. Este otro libro que sí, que yo creo que te puede servir mucho dependiendo de tu etapa, de la etapa en la que estés, es el libro este de Go. Otra vez lo recomiendo muchísimo, no lo recomiendo no solamente, les digo, por el lenguaje en sí mismo. De hecho, si no te interesa Go como lenguaje podrías ignorarlo, pero la forma en la que enseñan los conceptos de programación se me hace increíblemente buena. No es este libro que se llama The Go Programming Language. Uno de los autores es Rob Pike y el otro es, este, no me acuerdo del otro nombre, pero lo recomiendo mucho como libro de programación en general. Se me hace un excelente, excelente libro. Otro de los libros que que recomiendo casi siempre, digo, ya lo mencionaste, es el de George Polya. Ese es un libro de matemáticas, es un libro de matemáticas que te enseña en general cómo resolver problemas. No solamente te enseña, o sea, de hecho no ves una línea de programación ahí, sino te da como una base para resolver problemas. Y de hecho ese libro lo pueden leer a la mitad porque tiene como partes repetitivas. Porque no era un libro, no era un libro en sí mismo, es un compendio de como publicaciones de George Polya en la que explicaba lo que llamamos hoy heurística, las bases de la heurística. La heurística es el arte de resolver problemas, digo, los programadores lo entendemos de manera diferente, no, pero la heurística es cómo resuelvo un problema. Y entonces George Polya explica la base ahí. Y bueno, otro libro que puedo recomendar respecto a, no sé si este tiene que ver directamente con programación, pero se me hace como un libro esencial para los desarrolladores, se llama Data and Reality. Data and Reality es un libro de 1978 que escribió una persona que se llamaba William Kent. Tiene 3 ediciones Según yo, bueno, yo leí la tercera edición, pero después me di cuenta de que la edición como más completa era la segunda edición, porque la tercera edición le quitaron capítulos. Y la segunda edición es como la más recomendada por otras personas también. En Data and Reality les digo que tampoco vas a ver una línea de código, pero Data and Reality te explica como las cosas difíciles de modelar datos. Y programación, hacer programación básicamente es modelar el mundo real en sistemas, ¿no? Y entonces Data and Reality es un libro chistoso porque te deja con más preguntas que respuestas, y eso, y eso es muy interesante. Te deja con preguntas como, por ejemplo, ¿cómo defino la identidad? O sea, ¿cómo defino la identidad de algo? Y trata conceptos que, aunque has tratado de manera De hecho, los programadores experimentados los han tratado de manera empírica. Nunca te habías puesto a pensar en ellos de manera como profunda, de manera como más formal. Y este libro los trata así, los trata como de manera formal. Entonces, por ejemplo, te pone las preguntas como de cómo identificas que dos cosas son la misma, ¿no? Y te hace preguntas muy interesantes como: ¿y qué pasa si esto cambia en el tiempo? ¿Cómo vas a identificar que dos cosas son? O sea, ¿cómo sabes que esta cosa y esta cosa son la misma cuando ya han cambiado en el tiempo, ¿no? Y te lleva justamente a ampliar tu pensamiento en ese aspecto de cómo puedes modelar mejor tus datos. Y te deja con una conclusión: que no existe el modelo correcto, no existe el modelo único correcto del mundo, ¿no? Y entonces cada modelo tiene sus trade-offs, como siempre, pero te pone, te da por un buen viaje por todo este tipo de cuestiones de qué es, cuál es la forma correcta de representar los datos, o por lo menos cuál es la forma conveniente de representar los datos. Entonces creo que es el último libro que recomendaría de Data and Reality. Creo que todos los desarrolladores lo tienen que leer para quebrarse la cabeza.

Muy interesante. Ese me suena porque recuerdo que alguien comentó sobre la tercera edición, que no es del autor. Sino que es de la editorial y quisieron modernizar algunas partes. Y según una persona que criticaba bastante fuerte la tercera edición, se habían destrozado muchos de los contenidos porque ya no tenían el mismo sentido. Y creo que incluso esta persona tenía en su GitHub el libro subido de la segunda edición porque ya no estaba disponible. Si lo encuentro, lo pongo en la descripción.

Sí, te lo paso.

Sí, bueno, tú lo tienes.

Sí, de hecho, la segunda edición, como está descatalogada, creo que estamos, este, estamos en nuestro derecho de compartirla para que no se pierda. Pero sí, sí, exacto. Sí, sí, sí, este, sí es un muy buen libro. O sea, yo leí la tercera edición y aún la tercera edición es muy buena. Ahora estoy leyendo la segunda edición, que es justamente lo que no le cambiaron, este, muchas cosas. Lo que tiene la tercera edición de diferente de la segunda es tiene los comentarios de otra persona que se llama Steve Hoover, y le quitaron partes. Y esa es la parte que critica, ya no me acuerdo del nombre de esta persona, que también es un gran desarrollador, este, y este libro le quitaron partes y le pusieron los comentarios de Steve Hoover. Los comentarios de Steve Hoover se me hacen valiosos, o sea, se me hacen valiosos. Puede que se vayan por otro lado a veces que el autor no tenía como pensado, pero se me hace una muy buena, se me hace un buen libro todavía la tercera edición, pero dicen que el segundo está mucho mejor, que la segunda edición está todavía mucho mejor.

Y para ir finalizando, ¿qué destrezas consideras tú que son las que más tenemos que nutrir los programadores para llegar a ese punto de decir pues somos seniors, somos buenos programadores, o no nos basamos tanto en el lenguaje sino que con estas características específicas pues podemos encontrar un trabajo más fácilmente porque son más valorables que incluso tener un gran conocimiento de un lenguaje de programación concreto.

Yo considero dos características para esto. La primera, que no sé cómo traducir al español, le diría como en inglés resourcefulness. No sé cómo la traducirías tú, como la capacidad de resolver problemas o de tener, o sea, lo que ese concepto de resourcefulness me transmite a mí es la capacidad de alguien de resolver problemas por sus propios medios. O sea, es Yo llego y le doy a Manuel un problema y Manuel va a resolver el problema independientemente de lo que pase, ¿no? O sea, esa característica de poder resolver problemas por tus propios medios y de si no tiene los medios buscarlos para resolverlo, yo creo que es la característica principal de un, de un, este, de un desarrollador senior, ¿no? De alguien, de alguien avanzado justamente que puede ser autónomo justamente o tener autonomía resolviendo problemas. Entonces yo llego a Manuel, con Manuel, y le presento un problema, y Manuel en algún tiempo lo tiene resuelto justamente por sus propios medios. Es la primera característica para mí de alguien senior, de alguien avanzado. Y la siguiente característica es que estas soluciones que él presenta son simples, ¿no? O sea, creo que tú publicaste algo la otra vez, pero de un artículo de, no me acuerdo quién dijo eso, ¿no? Que un buen programador tiene 3 características, ¿no? Que es la que es flojo, que es este orgulloso, y la cuál es la tercera, este flojo, orgulloso. O sea, son 3 cosas que consideraríamos defectos, este, pero que esas 3 cosas te llevan a la simplicidad justamente. O sea, ser flojo te lleva a querer poner la solución más simple, ¿no? Ser orgulloso te lleva a poner hacer las cosas, a querer hacer las cosas bonitas, ¿no? Y no me acuerdo de cuál es la tercera, que también alguien dijo quiere automatizar cosas, ¿no? Entonces esas 3 características me llaman la atención porque todas te llevan a lo mismo, a la simplicidad, ¿no? Entonces, y la simplicidad no quiere decir tener poco código, sino quiere tener, sino quiere decir tener algo que se puede entender fácilmente. Y también te lleva a otras cosas en simplicidad, por ejemplo, simplicidad en procesos, de si algo se puede automatizar va a ser más simple el proceso en general. Entonces lo que tengo que hacer es automatizarlo. Esas son las características que yo consideraría de alguien senior. También lo he visto justamente, o sea, alguien que no está tan avanzado crea soluciones hipercomplejas que son muy difíciles de mantener y que para cambiar algo hay que hacer un montón de cosas. Y alguien senior no, alguien senior crea soluciones simples justamente, que después es un placer mantener, es un placer usar. Esas dos características son las que yo creo que un desarrollador tiene que, que, que esté. Yo creo que la primera es muy general, no solamente para desarrolladores sino para cualquier tipo de profesión. Si tienes esta capacidad de resolver problemas por tu cuenta sin depender de los demás, eso es una característica que cualquier como persona avanzada tiene. Y la otra es la de la simplicidad.

Completamente de acuerdo. Lo de la Los 3 defectos o ventajas, virtudes y demás. Creo que lo dijimos en el vídeo de Per, porque eran las ventajas que Larry Wall se decía de sí mismo, que era bastante curioso. Pero sí, aunque parecen defectos, son virtudes, bueno, virtudes son atributos de una persona que, tal y como tú has dicho, que permite hacer otra serie de de cosas que terminan siendo ventajas y ventajas muy valorables dentro de la empresa. Pues ya llevamos una hora, así que ha sido un gusto. Si quieres decir algo para finalizar, algunas conclusiones o algo que se te haya quedado por decir.

No, no creo que quedaron claros todos los mensajes, que es parte de lo que nos falta como industria, es la apertura y la capacidad de saber que el mundo no es blanco o negro, no es solamente bueno o malo, sino que hay una cantidad infinita de soluciones plausibles para las cosas. Y creo que tenemos que aprenderlo como industria y como desarrolladores, ¿no? Eso nos va a llevar justamente a reducir las discusiones poco productivas o no productivas, y también nos va a llevar a hacer mejor las cosas, a poder hacer mejor las cosas, porque vas a descubrir nuevas formas no dogmáticas y no Este, y sin, justamente sin rigidez de hacer las cosas que te pueden llevar a nuevos caminos. Entonces, mi conclusión del asunto, y también te quiero agradecer por invitarme, disfruté mucho estar aquí en la plática.

Siempre es un gusto hablar contigo, ya sea en Dedo MX o por aquí. Y bueno, este ha sido otro capítulo más, Codeadores. Agradecemos mucho la visita de Héctor y Os esperamos la semana que viene con otro capítulo nuevo. Muchas gracias por estar ahí.