Entrevista a Maarten van Steen
Investigador en sistemas distribuidos, y principal autor del libro Distributed Systems.
Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.
This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.
Maarten van Steen es un destacado académico y experto en informática, con una sólida formación en Matemáticas Aplicadas. Obtuvo su Maestría en esta disciplina en 1983 en la Universidad de Twente, donde se destacó por su estudio en optimización combinatoria y teoría de grafos. Posteriormente, en 1988, completó su doctorado en informática en la Universidad de Leiden, centrándose en la modelización de sistemas operativos y realizando contribuciones significativas en esta área. Después de su graduación, Maarten trabajó durante aproximadamente cinco años en investigaciones para TNO antes de regresar al ámbito académico en 1993, donde continuó su carrera en instituciones como la Universidad Erasmus de Rotterdam y la Universidad VU de Ámsterdam. En reconocimiento a sus logros académicos, fue nombrado profesor titular en 2002 y jefe del departamento de Ciencias de la Computación en 2010. En 2015, Maarten se unió a la Universidad de Twente, donde continúa desempeñando un papel destacado en el campo de la informática.
Además, es autor de multiples libros, entre los cuales están:
Y su libro más popular: Distributed Systems (2024, cuarta edición, versión 4.02). Este ha sido influyente en el campo de la informática y se ha utilizado como material educativo en todo el mundo.
Una de las cualidades de Maarten es su capacidad de explicar temas complejos de una manera clara, y sin evadir la rigurosidad. Además me gustaría destacar su gentileza para conmigo al aceptar esta entrevista.
¡Espero la disfruten!1
Versión traducida
(1) Eres coautor del libro Distributed Systems, que ahora está en su cuarta edición (2024). ¿Cómo surgió la idea de escribir este libro?
Hace unos años, en 1995, me uní al grupo de Andy Tanenbaum en la Vrije Universiteit de Ámsterdam como profesor asistente. Un año más o menos después, comencé a enseñar sistemas distribuidos utilizando su libro Distributed Operating Systems. Aunque eso funcionó bastante bien, después de un tiempo comencé a notar que los estudiantes tenían dificultades para ver el panorama general. Además, después de unos pocos años, algunos temas estaban quedando obsoletos. Lo más importante es que había demasiado énfasis en los sistemas operativos, mientras que los verdaderos desafíos radican en las cosas que eran independientes de los sistemas operativos. Decidimos escribir un nuevo libro enfocado únicamente en sistemas distribuidos. Para mí, los sistemas distribuidos caen en la categoría de cosas complejas. Como siempre les explicaba a los estudiantes: si cambias algo, es posible que comience a afectar en algún lugar donde no lo esperarías. Hay muchas interdependencias que deben considerarse. Entender esas interdependencias es, para mí, realmente de qué se tratan los sistemas distribuidos. Esa es la razón por la que elegimos tomar diferentes perspectivas: procesos, comunicación, coordinación, etc. El libro ha estado disponible en varias ediciones durante más de 20 años y aún se necesita. Es imposible explicar todo sobre sistemas distribuidos en un solo libro, pero ciertamente como introducción, todavía creo que el libro llena un vacío importante. Hay otros buenos libros ahí fuera, pero algunos de ellos realmente parecen una colección de temas aparentemente elegidos al azar. Eso no es bueno para un libro de texto, en mi opinión.
Una cosa con la que estamos satisfechos es hacer que el libro esté disponible en línea de forma gratuita. Simplemente permite que las personas comiencen con un presupuesto bajo. Junto con un conjunto extenso de diapositivas que cualquier profesor puede modificar según sus propias necesidades, lo que queda es concentrarse principalmente en el contenido. Además, cualquier error se puede corregir fácilmente y poner a disposición al instante. También lo vendemos a través de Amazon a un precio bajo, y con su sistema actual, incluso puedo actualizar las versiones físicas, lo que me permite mantener la copia digital y física sincronizadas. Esta autoedición realmente es útil para que las cosas avancen.
(2) ¿Cuáles consideras que son los desafíos más importantes en los sistemas distribuidos hoy y en el futuro? ¿Hay algún nuevo principio que pueda surgir?
Esa es una difícil. Mi propia investigación siempre se ha concentrado en los problemas de escalabilidad. Diseñar para la escalabilidad no es fácil: parece que tenemos esta tendencia a complicar demasiado las cosas. Desde esta perspectiva, un gran desafío real es mantener las cosas tan simples como sea posible (pero no demasiado simples). Creo firmemente que solo las cosas simples y basadas en principios pueden escalar. Esto también significa que no soy un gran fan de las optimizaciones de rendimiento, o al menos no hasta que se haya implementado el diseño más simple que funcione. Como se dijo, para muchos de nosotros, mantenernos alejados de las optimizaciones y reflexionar sobre cómo podemos simplificar aún más los diseños es un desafío. Puede ser el mayor desafío para aquellos que desarrollan sistemas distribuidos.
Para dar un ejemplo. Hay mucho revuelo sobre la computación edge. La mayor parte de ese revuelo se trata de cómo podemos implementar mejor los sistemas edge. Esto a menudo se trata de optimización. Sin embargo, cuando lo piensas, también podemos preguntarnos qué problema realmente resuelve la computación edge. Muchas personas mencionan la privacidad, la eficiencia energética, el uso del ancho de banda y demás. Sin embargo, yo diría que la computación edge puede contribuir a mejorar estas cosas (aunque la eficiencia energética es discutible). Para mí, el mejor argumento para la computación edge es que la necesitamos cuando es difícil vencer a la Madre Naturaleza, y eso prácticamente solo ocurre cuando hay problemas de latencia. Creo que es justo decir que los problemas de ancho de banda siempre son de naturaleza temporal; lo mismo ocurre con la conectividad (con notables excepciones, como en aplicaciones espaciales). Proteger la privacidad manteniendo las cosas locales no tiene sentido para mí (aunque reconozco que su realización puede ser algo más simple). Entonces, ¿por qué molestarse tanto con la computación edge? Desde la perspectiva de la computación en la nube, introducida ya en 2009, optimizar el edge no parece un tema de alta prioridad. Lo que sí importa, y es un tema difícil, es cruzar los límites administrativos. Y sí, esta es una de las cuestiones de escalabilidad ya mencionadas por Clifford Neuman en la década de 1990.
Una cosa que he estado considerando agregar como principio es el mantenimiento. Los sistemas distribuidos no se apagan (bueno, normalmente hablando). Siempre están en funcionamiento, y mientras lo hacen, las cosas deben actualizarse, reemplazarse, lo que sea. Los componentes también se rompen, y sería conveniente si pudieras predecir dónde sucedería eso. Aún no he desarrollado una imagen razonable para incluir esto en el libro como un principio separado. Pero quizás en la 5ª edición.
En resumen: diseñar para la simplicidad y con ella para la escalabilidad es y sigue siendo, para mí, el mayor desafío. Lo que ayuda a mantenerse en el camino correcto es preguntarnos cuál es el problema que estamos tratando de resolver. Intentemos evitar trabajar en tecnología por el bien de la tecnología, aunque sea tan divertido. En este sentido, puedes entender que no soy un gran fan de las blockchains.
(3) Con la popularidad de la IA y sus modelos generativos, ¿cree que este campo podría influir en la investigación en sistemas distribuidos, creando mecanismos para la adaptabilidad, la privacidad o los algoritmos distribuidos autogenerados?
Bueno, creo que acabas de dar una respuesta positiva a tu propia pregunta. Dicho esto, no me queda claro cuál es el verdadero poder de la IA (generativa), en el sentido de que aún tenemos que ver qué tan confiable es para generar soluciones que funcionen. A veces sospecho que una vez que superemos nuestro propio asombro, notaremos varias fallas profundas que son difíciles de mitigar. La IA sigue siendo IA estrecha: buena para hacer una cosa. A menudo, todavía tenemos que descubrir qué tan robustos son los análisis y las soluciones. Sin embargo, soy optimista, pero no me preguntes todavía cómo se utilizará la IA para los sistemas distribuidos. Como primer paso, veo mucha promesa en el mantenimiento predictivo basado en IA, un tema en el que Ozalp Babaoglu ha estado trabajando, como uno de los primeros, de hecho.
(4) Tienes un video titulado «Dos perspectivas sobre el futuro de las ciencias de la computación» (Two perspectives on the future of computer sciences) donde explicas una perspectiva integrada de la computación con otras áreas del conocimiento. Ahora, con los avances en el campo de la IA, ¿ha cambiado o se ha expandido de alguna manera tu perspectiva sobre el futuro de las ciencias de la computación?
Una cosa que mencioné en ese video fue el cambio del núcleo de las ciencias de la computación desde los temas «tradicionales» de las ciencias de la computación (algoritmos, sistemas, lenguajes) hacia la IA. Ahora preveo que las ciencias de la computación tendrán que mirar mucho más hacia los temas para hacer que las soluciones de IA funcionen. Por ejemplo, sospecho que necesitaremos alternativas para nuestras computadoras de Von Neumann, que actualmente nos permiten solo simular modelos de IA. ¿Qué significaría esto para nuestras prácticas de computación? ¿Para nuestro desarrollo de sistemas?
Volviendo a los problemas de escalabilidad, también creo que tendremos que enfocarnos más en la naturaleza estocástica y probabilística de nuestros sistemas informáticos muy grandes y complejos distribuidos, quizás mucho más a lo largo de los métodos que los físicos intentan capturar las sutilezas del mundo que nos rodea: mediante el modelado y la adopción gradual de esos modelos como la verdad. Sin embargo, un problema real radica en este campo vagamente definido llamado digitalización, mediante el cual virtualmente todo está equipado con componentes y soluciones digitales. Muchos espectadores de ese video han pensado erróneamente que propuse enfocarme mucho más en la aplicación de las ciencias de la computación a otras disciplinas. En cambio, quise decir que nosotros, como científicos de la computación, debemos enfocarnos mucho más en la integración con otras áreas, si solo para prevenir errores causados por personas que no entienden la computación como nosotros.
Para dar un ejemplo, tengo colegas, principalmente de las ciencias sociales, que están trabajando en un gran proyecto nacional sobre la sociedad algorítmica. Este es un tema extremadamente importante que puede dar forma al futuro para muchos de nosotros. Los científicos de la computación deberían estar (y en este ejemplo lo están) a bordo, no para aplicar lo que ya saben, sino para codesarrollar soluciones que sabemos que pueden funcionar, tanto técnicamente como socialmente. Esas soluciones a menudo aún no se conocen, ya que pueden necesitar cumplir con estrictas reglas de protección de la privacidad. Al mismo tiempo, la tecnología de las ciencias de la computación también puede ayudar a comprender lo que significa realmente proteger la privacidad (en particular, es mucho más que solo protección de datos).
Como otro ejemplo, considera el Reglamento General de Protección de Datos de la Unión Europea (RGPD). Algo que ha sido establecido por expertos, pero sospecho que no por aquellos profundamente familiarizados con las Ciencias de la Computación. Si realmente podemos hacer cumplir el RGPD ya es un punto de discusión, pero ¿qué pasa con el análisis y la aplicación automáticos del RGPD? Esto es algo para los sistemas de ley computacional. Sería interesante para mí ver qué sucedería si cocreáramos el RGPD junto con el requisito de que debe ser completamente compatible con un sistema de ley computacional. No puedo imaginar que podríamos capturar todo (lo cual es una pregunta de investigación), pero nos permitiría separar las partes «fáciles» (aquellas que se pueden automatizar) de otras partes (y típicamente aquellas que requieren mucho pensamiento). El acto de IA europeo también podría haberse manejado a lo largo de estas líneas (y habríamos descubierto interesantes contradicciones integradas).
Estos son solo dos ejemplos, pero otros fácilmente vienen a la mente que ilustran que las ciencias de la computación no pueden y nunca serán una disciplina aislada.
Así que la respuesta simple a tu pregunta es «no». Sin embargo, la urgencia de un enfoque integrado ha aumentado en mi opinión.
(5) Has escrito varios libros y enseñado varios cursos. ¿Cuál es tu enfoque para hacer que los temas complejos sean accesibles y comprensibles?
La respuesta simple es preguntarme continuamente si me estoy enfocando lo suficiente en los aspectos esenciales. Si me pierdo en tecnicismos, probablemente signifique que no entendí bien el tema para explicarlo claramente a otros. Como regla general, tomo el enfoque de que, si no entiendo lo que alguien me está diciendo, es probable que no sea mi culpa. Si comprendes bien un problema y su solución, las explicaciones se vuelven más simples. Hay numerosos ejemplos en mis libros y cursos en los que queda claro que mi comprensión del tema ha obstaculizado una explicación clara.
Además de este enfoque, y en línea con lo que mencioné antes, esforzarse por la simplicidad siempre debe ser lo primero. Realmente creo que la mayoría de nosotros, incluido yo mismo, estamos tentados demasiado rápido a optar por soluciones que pueden solucionar un problema, pero no nos hemos preguntado suficientemente si hemos entendido lo suficiente el problema, o incluso las fuentes de ese problema. Demasiadas veces he notado que también mis propias soluciones podrían simplificarse increíblemente solo dando un paso atrás. Un ejemplo reciente es el código que escribí para el libro de Sistemas Distribuidos, que utiliza el sistema Redis. Admito que no entendí completamente la semántica subyacente para la 3ra edición, lo que llevó a un código funcional, pero difícil de comprender por completo. Para la 4ta edición, creo que el código es mucho más simple y fácil de entender. Ahora también tengo más confianza en que es correcto. Por cierto, me he mantenido alejado de las optimizaciones.
(6) ¿Qué consejo le darías a una persona joven interesada en ingresar a un campo tan vasto como los sistemas distribuidos?
Simplemente comienza. Asegúrate de entender la programación de redes, cómo manejar bloqueos y cosas así, y luego elige un problema. En este sentido, recomendaría el libro de Martin Kleppmann para obtener experiencia práctica. Es una excelente lectura y una vez que tengas una sensación intuitiva de cómo funcionan las cosas en la práctica, se vuelve más fácil entender y apreciar también el material más teórico en nuestro libro.
También ayuda: construir cosas. Construir puede ser programar, pero también instalar software existente y unir cosas. Por ejemplo, todo el sitio web de distributed-systems.net se ejecuta en mis propios servidores, incluidas copias de seguridad calientes, copias de seguridad incrementales, réplicas independientes, servidores de correo, todo. En cierto punto, incluso tenía mi propio servidor DNS de segundo nivel en funcionamiento, pero es más una molestia administrativa que otra cosa. Todavía planeo tener un intercambio (semi-) automatizado simple a un servidor ubicado en otra parte, pero eso requiere una excelente conexión a Internet (y tiempo para una configuración adecuada). El punto es: los sistemas distribuidos se tratan mucho de hacer que las cosas se hagan de manera práctica, así que necesitas hacer más que solo estudiar material de libros y artículos. Una vez que tienes un sistema básico en su lugar, probar y agregar cosas se vuelve mucho más fácil. Ayuda si realmente dependes de que ese sistema funcione: te mantiene alerta.
(7) Si tuvieras la oportunidad de viajar en el tiempo y darle consejos no técnicos o no relacionados con la escritura a tu yo más joven, ¿qué sería, y por qué lo consideras importante?
En este caso, solo puedo citar al Dr. Seuss: «Sé quien eres y di lo que sientes, porque aquellos que les importa no importan y aquellos que importan no les importa». Esto también significa, para mí, que es importante escuchar lo que tienen que decir los demás, independientemente del tema. La diversidad al máximo generalmente será beneficiosa para todos, sin importar lo difícil que pueda ser a veces soportarlo. Las personas con ideas similares no te llevarán tan lejos como la gente con diferentes ideas, estilos y demás.
Original
(1) You are a co-author of the book “Distributed Systems,” which is now in its fourth edition (2023). How did the idea to write this book come about?
Back in 1995, I joined Andy Tanenbaum's group at Vrije Universiteit in Amsterdam as an assistant professor. A year later or so, I started teaching distributed systems using his book "Distributed Operating Systems." Although that worked quite well, after a while I began to notice that students had trouble getting the bigger picture. Also, already after a few years, some topics were becoming outdated. The most important was that there was too much emphasis on operating systems, whereas the real challenges lie in the stuff that was independent of operating systems. We decided to write a new book focusing entirely on distributed systems. Distributed systems for me fall into the category of complex stuff. As I always explained to students: if you change something, it may easily start hurting some place where you wouldn't expect it. There are so many interdependencies that need to be considered. Understanding those interdependencies is, to me, really what distributed systems are all about. That's the reason why we chose to take different perspectives: processes, communication, coordination, etc. The book has now been around in various editions for over 20 years and still in need. It's impossible to explain everything about distributed systems in a single book, but certainly as an introduction, I still believe the book fills an important gap. There are other good books out there, but some of them really appear to me as a collection of seemingly randomly chosen topics. That's not good for a textbook, in my opinion.
One thing we're pleased with is making the book available online for free. It simply allows folks to get started on a low budget. Along with an extensive set of slides that any lecturer can modify to their own needs, what remains is to mainly concentrate on the content. Moreover, any mistakes can be easily corrected and made available instantly. We also sell it through Amazon for a low price, and with their current system, I can even update the hard-copy versions, allowing me to keep the digital and physical copy in sync. This self-publishing is really helpful in getting things going.
(2) What do you consider to be the most significant challenges in distributed systems today and in the future? Are there any new principles that could emerge?
That's a tough one. My own research has always concentrated on scalability problems. Designing for scalability is not easy: we seem to have this tendency to make things too complicated. From this perspective, a real big challenge is to keep things as simple as possible (but not too simple). I firmly believe that only principled, simple things can scale. This also means that I'm not a big fan of optimizations for performance, or at least not until the simplest working design has been implemented. As said, for many of us, staying away from optimizations and pondering on how we can further simplify designs is a challenge. It may be the biggest challenge for those developing distributed systems.
To give one example. There is a lot of buzz about edge computing. Most of that buzz is about how we can best deploy edge systems. This is often all about optimization. Yet, when you think about it, we can also ask ourselves which problem does edge computing really solve? Many folks mention privacy, energy efficiency, bandwidth usage, and so forth. However, I would say that edge computing may contribute to improving these things (although energy efficiency is disputable). To me, the best argument for edge computing is that we need it when beating Mother Nature is tough, and that's practically only when there are latency issues. I think it's fair to say that bandwidth issues are always of a temporary nature; the same holds for connectivity (with notable exceptions, such as in space applications). Protecting privacy by keeping things local doesn't make sense to me (although I acknowledge that its realization may be somewhat simpler). So, why bother so much about edge computing? From the perspective of sky computing, as introduced already in 2009, optimizing the edge doesn't seem like a high-priority topic. What does matter, and a subject that is tough, is crossing administrative boundaries. And yes, this is one of the scalability issues already mentioned by Clifford Neuman back in the 1990s.
One thing that I have been considering to add as a principle is maintenance. Distributed systems are not shut down (well, normally speaking). They are always up and running, and while doing so, things need to be upgraded, replaced, what have you. Components also break, and it would be convenient if you could predict where that would happen. I haven't developed a reasonable picture yet to bring this into the book as a separate principle. But perhaps in the 5th edition.
In summary: designing for simplicity and with it for scalability is and remains, to me, the greatest challenge. What helps in keeping on track is asking ourselves what the problem is that we're trying to solve. Let's try to avoid working on technology for the sake of technology, even it's so fun. In this respect, you may understand that I'm not a big fan of blockchains.
(3) With the popularity of AI and its generative models, do you think this field could influence research in distributed systems, creating mechanisms for adaptability, privacy, or self-generated distributed algorithms?
Well, I think you just gave a positive answer to your own question. Having said that, it is unclear to me what the real power of (generative) AI actually is, in the sense that we yet have to see how reliable it is for generating solutions that work. I sometimes suspect that once we are over our own amazement, we'll notice various deep flaws that are difficult to mitigate. AI is still narrow AI: good at doing one thing. Often, we still need to find out how robust the analyses and solutions are. Yet, I am optimistic, but don't ask me yet how AI will be put to good use for distributed systems. As a first step, I do see a lot of promise for AI-based predictive maintenance, a topic that Ozalp Babaoglu has been working on, as one of the first, actually.
(4) You have a video titled “Two perspectives on the future of computer sciences” where you explain an integrated perspective of computing with other areas of knowledge. Now, with advancements in the field of AI, has your perspective on the future of computer sciences changed or expanded in any way?
One thing that I mentioned in that video was the shift of the core of computer science from "traditional" computer science topics (algorithms, systems, languages), to AI. I now foresee that computer sciences will need to look much more into topics for making AI solutions work. For example, I suspect we'll need alternatives for our Von Neumann computers, which currently allow us to only simulate AI models. What would this mean for our computing practices? For our development of systems?
Coming back to scalability problems, I also think we'll have to focus more on the stochastic and probabilistic nature of our very large and complex distributed computer systems, perhaps much more along the ways that physicists try to capture the intricacies of the world around us: by modeling and gradually adopting those models as being the truth. Yet, a real problem lies in this vaguely defined field called digitalization, by which virtually everything is equipped with digital components and solutions. Many viewers of that video have wrongly thought that I proposed to focus much more on the application of computer science to other disciplines. Instead, I meant that we, as computer scientists, need to focus much more on the integration with other fields, if only to prevent mistakes caused by people who do not understand computing as we do.
To give an example, I have colleagues, primarily coming from the social sciences, who are working on a large national project about the algorithmic society. This is an extremely important subject that may well shape the future for many of us. Computer scientists should be (and in this example are) on board, not to apply what they already know, but to co-develop solutions that we know can work, technically as well socially. Those solutions are often not yet known, as they may need to meet tough privacy protection rules. At the same time, computer science technology may also help to understand what protecting privacy really means (in particular, it's much more than just data protection).
As another example, consider the European General Data Protection Regulation (GDPR). Something that has been set up by experts, but I suspect not ones deeply familiar with Computer Science. Whether we can actually enforce GDPR is already a point of discussion, but what about automatically analyzing and enforcing GDPR? This is something for computational law systems. To me, it would be interesting to see what would happen if we would co-create the GDPR along with the requirement that it should be fully supported by a computational law system. I can't imagine we would be able to capture everything (which is a research question), yet it would allow us to separate the "easy" parts (those that can be automated) from other parts (and typically those that require a lot of thinking). The European AI act could also have been handled along these lines (and we would have discovered interesting built-in contradictions).
These are just two examples, but others easily come to mind that illustrate that computer science cannot and never will be an isolated discipline.
So, the simple answer to your question is "no." The urgency for an integrated approach has, however, gone up in my opinion.
(5) You've written several books and taught various courses. What is your approach to making complex subjects accessible and understandable?
The simple answer is continuously asking myself if I'm focusing enough on the essentials. If I get lost in technicalities, that probably means I didn't understand the subject well enough to clearly explain it to others. As a general rule, I take the approach that if I don't understand what someone is telling me, it's most likely not my fault. If you understand a problem and its solution well, explanations become simpler. There are numerous examples from my books and courses where it is clear that my understanding of the topic has been hindering a clear explanation.
Besides this focus, and in line with what I mentioned before, striving for simplicity should always come first. I really think that most of us, including myself, are tempted too quickly to go for solutions that may fix a problem, but have not sufficiently asked ourselves whether we have understood the problem enough, or even the source(s) of that problem. Too often have I noticed that also my own solutions could be incredibly simplified by just taking a step back. A recent example is the code I wrote for the Distributed Systems book, which makes use of the Redis system. Admittedly, I did not fully understand the underlying semantics for the 3rd edition, which led to working code, yet difficult to fully comprehend. For the 4th edition, I believe the code is much simpler and easier to understand. I'm now also more confident that it is correct. By the way, I have consistently stayed away from optimizations.
(6) What advice would you give to a young person interested in entering such a vast field as distributed systems?
Just start. Make sure you understand network programming, how to handle locks and such, and then pick a problem. In this sense, I would advise Martin Kleppmann's book to get hands-on experience. It's a great read and once you have a gut feeling how things work in practice, it becomes easier to understand and appreciate also the more theoretical material in our book.
What also helps: build things. Building can be programming, but also installing existing software and tying things together. For example, the entire website for distributed-systems.net is running on my own servers, including hot backups, incremental backups, independent replicas, mail servers, the whole thing. At a certain point, I even had my own second-level DNS server running, but that is more of an administrative hassle than anything else. I still plan to have a simple (semi-) automated handoff to a server located elsewhere, but that requires an excellent Internet connection (and time for proper configuration). The point is: distributed systems are much about getting things practically done, so you need to do more than just study material from books and papers. Once you have a basic system in place, testing and adding stuff becomes much easier. It helps if you actually depend on that system to work: it keeps your alert.
(7) If you had the opportunity to travel back in time and give non-technical or non-writing related advice to your younger self, what would it be, and why do you consider it important?
In this case, I can only quote Dr. Seuss: "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." This also means, to me, that it is important to get to hear what others have to say, regardless of the subject. Diversity to the max will generally be beneficial to everyone, no matter how difficult it can sometimes be to endure. Like-minded people will not get you as far as the folks with different ideas, styles, and what have you.
La versión traducida se realizó usando mistral-large-2402 (LLM), con algunas modificaciones de mi parte para mejorar la legibilidad.