cap02 revision

chapter02.md

@@ -2,7 +2,7 @@
 
 ## Programadores famosos
 
-A través de la historia de la computación ha habido personas que han demostrado increíbles capacidades a la hora de crear código. Residen en el panteón de los grandes programadores informáticos: Ada Lovelace (la primera programadora de computadoras), Dennis Ritchie (el creador del lenguaje de programación C), Rear Admiral Grace Murray Hopper (creador de COBOL y acreditado por encontrar el primer "error" (_N. del traductor: un error informático en inglés es llamado "bug" que también se puede traducir como bicho o insecto_) informático documentado) y muchos más. También tenemos desarrolladores en nuestras propias comunidades que tienen un cierto grado de notoriedad, ya sean las personas que escribieron el lenguaje de programación que usamos actualmente, las personas que mantienen el sistema operativo que usamos o alguien que saltó a la fama en nuestra comunidad preferida. Puede ser intimidante cuando nos comparamos con estas grandes personas. Después de todo, cualquier cosa en la que estemos trabajando actualmente podría no estar a la altura de lo que ellos hayan hecho. Peor aún, podemos estar trabajando en algo similar y sentir que cualquier cosa en la que estemos trabajando nunca estará a la altura de lo que estas personas han logrado. Incluso podemos ser amigos de programadores que parecen resolver las cosas mucho más rápido y de una manera más elegante que nosotros y maravillarnos de cómo parecen tener este cuerpo de conocimiento al alcance de la mano que posiblemente no podamos entender.
+A lo largo de la historia de la computación ha habido personas que han demostrado increíbles capacidades a la hora de crear código. Residen en el panteón de los grandes programadores informáticos: Ada Lovelace (la primera programadora de computadoras), Dennis Ritchie (el creador del lenguaje de programación C), Rear Admiral Grace Murray Hopper (creador de COBOL y acreditado por encontrar el primer "error" (_N. del traductor: un error informático en inglés es llamado "bug" que también se puede traducir como bicho o insecto_) informático documentado) y muchos más. También tenemos desarrolladores en nuestras propias comunidades que tienen un cierto grado de notoriedad, ya sean las personas que escribieron el lenguaje de programación que usamos actualmente, las personas que mantienen el sistema operativo que usamos o alguien que saltó a la fama en nuestra comunidad preferida. Puede ser intimidante cuando nos comparamos con estas grandes personas. Después de todo, cualquier cosa en la que estemos trabajando actualmente podría no estar a la altura de lo que ellos hayan hecho. Peor aún, podemos estar trabajando en algo similar y sentir que cualquier cosa en la que estemos trabajando nunca estará a la altura de lo que estas personas han logrado. Incluso podemos ser amigos de programadores que parecen resolver las cosas mucho más rápido y de una manera más elegante que nosotros y maravillarnos de cómo parecen tener todo ese conocimiento al alcance de la mano que posiblemente no podamos entender.
 
 ## Entre bastidores frente a la actuación final
 
@@ -10,39 +10,39 @@ Uno de los mejores consejos que he recibido sobre compararnos con los demás es
 
 ## El atractivo del post-mortem
 
-Hay una tradición en algunos proyectos de programación (especialmente en proyectos de desarrollo de juegos donde hay un final claro para el proyecto cuando se envía el producto) de hacer una autopsia del proyecto. Lo que hace la autopsia es permitir que los desarrolladores de un proyecto indiquen lo que salió bien y lo que no salió bien. Las mejores autopsias tienden a ser relatos francos de los éxitos y fracasos de un proyecto.
+Hay una tradición en algunos proyectos de programación (especialmente en proyectos de desarrollo de juegos donde hay un final claro para el proyecto cuando se envía el producto) de hacer una autopsia del proyecto. Lo que hace la autopsia es permitir que los desarrolladores de un proyecto indiquen lo que salió bien y lo que no salió bien. Las mejores autopsias tienden a ser relatos sinceros de los éxitos y fracasos de un proyecto.
 
 La autopsia puede ser una mirada fascinante al desarrollo de un proyecto. Me he encontrado leyendo muchas de estas en busca de información sobre el proceso de desarrollo. Pero hay una trampa sutil en la autopsia: son un recuerdo de eventos desde el punto de vista de un proyecto exitoso (o fallido). Son un recuerdo de alguien que trabajó en un proyecto que fue lo suficientemente exitoso como para que tu dediques tiempo a leer sobre los altibajos de ese proyecto. Están escritos desde una perspectiva en la que el éxito del proyecto es una conclusión inevitable (o están escritos sobre proyectos que se destacaron por cómo fallaron o no cumplieron con las expectativas de los involucrados). Puede llevar a la creencia de que en lo que estás trabajando no es tan importante como las cosas en las que están trabajando otras personas. Pero no sabemos la importancia de nuestro proyecto en tiempo real. Incluso la gente en la autopsia no sabía si su proyecto funcionaría o tendría éxito mientras trabajaban en él. Es posible que nuestros proyectos nunca vean la luz del día o que sean algo que cambie el mundo. No podemos saber el valor de aquello en lo que estamos trabajando mientras lo hacemos (aunque podemos tener una idea de si _sentimos_ que nuestro trabajo es importante o no).
 
-Una autopsia también tiene el beneficio de la retrospectiva. Las decisiones que eran claras y definitivas en ese momento podrían no tener mucho sentido cuando se las compara con los datos obtenidos más adelante en la vida útil del proyecto. También hay un problema con la "memoria selectiva" en la que es posible que algo no se recuerde con la misma claridad o se combine con otros eventos. Declaraciones confiadas como "Sabíamos que esto no habría funcionado" en realidad podrían haber sido "No estábamos seguros de si esto funcionaría, así que probamos varias cosas. Todas no funcionaron". Considera a cualquiera que escriba sobre su pasado como un narrador poco confiable. Cierto, pueden ser los mejores y más informados narradores que tenemos, pero no tienen una perspectiva objetiva de lo que sea que estaban creando. Tienen sus propios prejuicios y razones para las historias que presentan en una autopsia. Trate una autopsia como trataría una autobiografía de una persona famosa: una fuente primaria con una agenda para mostrar el tema de la mejor manera posible.
+Una autopsia también tiene el beneficio de la retrospectiva. Las decisiones que eran claras y definitivas en ese momento podrían no tener mucho sentido cuando se las compara con los datos obtenidos más adelante en la vida útil del proyecto. También hay un problema con la "memoria selectiva" en la que es posible que algo no se recuerde con la misma claridad o se combine con otros eventos. Declaraciones confiadas como "Sabíamos que esto no habría funcionado" en realidad podrían haber sido "No estábamos seguros de si esto funcionaría, así que probamos varias cosas. Todas no funcionaron". Debes considerar a cualquiera que escriba sobre su pasado como un narrador poco confiable. Cierto, pueden ser los mejores y más informados narradores que tenemos, pero no tienen una perspectiva objetiva de lo que sea que estaban creando. Tienen sus propios prejuicios y razones para las historias que presentan en una autopsia. Trate una autopsia como trataría una autobiografía de una persona famosa: una fuente primaria con una agenda para mostrar el tema de la mejor manera posible.
 
-No hay nada de malo en leer una autopsia sobre un proyecto; podemos aprender mucho sobre cómo se ejecuta un proyecto (o no se debe ejecutar) y qué peligros debemos tener en cuenta si seguimos un camino similar, pero comprende que estás leyendo un informe (ya sea de una persona o de un equipo de personas). Tienen la perspectiva de alguien profundamente involucrado en el conflicto. Estás mirando sus recuerdos de tácticas, no la estrategia general que los trajo al lugar.
+No hay nada de malo en leer una autopsia sobre un proyecto, podemos aprender mucho sobre cómo se ejecuta un proyecto (o no se debe ejecutar) y qué peligros debemos tener en cuenta si seguimos un camino similar, pero hay que comprender que estás leyendo un informe (ya sea de una persona o de un equipo de personas). Tienen la perspectiva de alguien profundamente involucrado en el conflicto. Estás mirando sus recuerdos de tácticas, no la estrategia general que los trajo al lugar.
 
 ## Clasificación de programadores
 
-Hay muchas medidas que la gente usa para clasificar a los programadores. Es probable que hayas visto que estas medidas se manifiestan de diferentes maneras: sitios de competencia, números de _commits_ en un proyecto, medidas de productividad, tiempo para entregar el código y los buenos sentimientos viscerales que podamos sentir como se hacía antiguamente. Nos lo hacemos a nosotros mismos y a los demás. Comparamos nuestro trabajo con el trabajo de nuestros compañeros y gente que admiramos, pero eso puede llevarnos a hacer comparaciones que no son objetivas o no se basan en todos los datos. Puedo compararme con personas que hacen programación de bajo nivel y encontrar que no estoy a la altura en ese ámbito. No importa que no haya hecho mucha programación de bajo nivel; la comparación es válida. O puedo compararme con personas que fueron asesoradas por programadores cuyos nombres son legendarios en su campo. Encontraré brechas entre mi conocimiento y el de ellos, porque no tuve acceso a esos mentores (o peor aún: no aproveché los mentores a los que podría haber accedido. ¡Ups!). Comparaciones como estas no ayudan y nos llevan a castigarnos por no ser otra persona. Nuestra evaluación de nuestros proyectos e historia nos da la conclusión de que no somos esa otra persona, ni podríamos ser nunca esa otra persona.
+Hay muchas medidas que la gente usa para clasificar a los programadores. Es probable que hayas visto que estas medidas se manifiestan de diferentes maneras: sitios de competencia, números de _commits_ en un proyecto, medidas de productividad, tiempo para entregar el código y los buenos sentimientos viscerales que podamos sentir, como se hacía antiguamente. Nos lo hacemos a nosotros mismos y a los demás. Comparamos nuestro trabajo con el trabajo de nuestros compañeros y gente que admiramos, pero eso puede llevarnos a hacer comparaciones que no son objetivas o no se basan en todos los datos. Puedo compararme con personas que hacen programación de bajo nivel y encontrar que no estoy a la altura en ese ámbito. No importa que no haya hecho mucha programación de bajo nivel, la comparación es válida. O puedo compararme con personas que fueron asesoradas por programadores cuyos nombres son legendarios en su campo. Encontraré brechas entre mi conocimiento y el de ellos, porque no tuve acceso a esos mentores (o peor aún: no aproveché los mentores a los que podría haber accedido. ¡Ups!). Comparaciones como estas no ayudan y nos llevan a castigarnos por no ser otra persona. Nuestra evaluación de nuestros proyectos e historia nos da la conclusión de que no somos esa otra persona, ni podríamos ser nunca esa otra persona.
 
 El mayor problema con la clasificación de programadores (o en cualquier caso, clasificación de cualquier cosa) es que los sistemas de clasificación están basados en una serie de criterios. No hay un estándar real para clasificar programadores. Los sitios donde se clasifica y puntúa programadores en base a un número de problemas resueltos o la dificultad de los problemas resueltos solo han determinado que hay una serie de programadores que realmente disfrutan resolviendo esa clase de problemas. También han reunido a un grupo de programadores que dedicarán tiempo y esfuerzo a resolver estos problemas y serán competitivos mientras los resuelven. Nos dice poco sobre las habilidades del programador fuera de esa materia.
 
-También hay otras medidas para clasificar a los programadores. Una medida clásica es revisar cuántas líneas de código usó un programador para resolver un problema (esto a veces se denomina "código de golf", donde cuanto menor sea el número de líneas de código, mejor será la solución). Podemos argumentar cómo de "limpia" es la solución (limpia es otro término algo nebuloso y poco concreto). Podemos determinar la "notación Big O", una notación utilizada para describir el rendimiento o la complejidad de los algoritmos que un programador utilizó en su código. Podemos hacer una prueba de _estrés_ o de esfuerzo del código para determinar cómo de bien se adapta el código a diversas circunstancias. Podemos contar la cantidad de ciclos que requiere un código en particular para ejecutarse y compararlo con un código similar. Muy poco de esto nos dice algo sobre un programador en particular. Lo que sí nos dice es que el programador tiene experiencia que lo lleva a esa solución en particular. Nos dice que el programador ha visto este tipo de problemas antes y se preocupó lo suficiente por el problema como para pensar lo suficiente sobre cómo hacer una mejor solución. Aprendemos que el programador dedicó tiempo y energía a practicar este tipo de problemas. Lo que no nos muestra es una medida general de las habilidades o capacidades del programador. Es similar al cuento apócrifo de un profesor brillante. Este profesor era un genio absoluto en su campo y era una de las personas a las que acudir para obtener respuestas sobre su tema, pero a pesar de su brillantez, no sabía cómo cambiar un neumático en un automóvil. ¿Significa eso que el profesor no era tan brillante como la gente decía que era? Difícilmente. Significa que el profesor pasó más tiempo pensando en su profesión que pensando en cambiar neumáticos. Lo mismo es cierto también para los programadores. Si un programador pasa la mayor parte de su tiempo resolviendo un conjunto particular de problemas, eventualmente se volverá experto en ese tipo de problemas. Pero si ese programador se atasca con un tipo diferente de problemas, eso no descarta sus habilidades generales, simplemente señala las áreas en las que podrían querer trabajar.
+También hay otras medidas para clasificar a los programadores. Una medida clásica es revisar cuántas líneas de código usó un programador para resolver un problema (esto a veces se denomina "código de golf", donde cuanto menor sea el número de líneas de código, mejor será la solución). Podemos argumentar cómo de "limpia" es la solución (limpia es otro término algo nebuloso y poco concreto). Podemos determinar la "notación Big O", una notación utilizada para describir el rendimiento o la complejidad de los algoritmos que utilizó un programador en su código. Podemos hacer una prueba de _estrés_ o de esfuerzo del código para determinar cómo de bien se adapta el código a diversas circunstancias. Podemos contar la cantidad de ciclos que requiere un código en particular para ejecutarse y compararlo con un código similar. Muy poco de esto nos dice algo sobre un programador en particular. Lo que sí nos dice es que el programador tiene experiencia que lo lleva a esa solución en particular. Nos dice que el programador ha visto este tipo de problemas antes y se preocupó lo suficiente por el problema como para pensar lo suficiente sobre cómo hacer una mejor solución. Aprendemos que el programador dedicó tiempo y energía a practicar este tipo de problemas. Lo que no nos muestra es una medida general de las habilidades o capacidades del programador. Es similar al cuento apócrifo de un profesor brillante. Este profesor era un genio absoluto en su campo y era una de las personas a las que acudir para obtener respuestas sobre su tema, pero a pesar de su brillantez, no sabía cómo cambiar un neumático en un automóvil. ¿Significa eso que el profesor no era tan brillante como la gente decía que era? Difícilmente. Significa que el profesor pasó más tiempo pensando en su profesión que pensando en cambiar neumáticos. Lo mismo es cierto también para los programadores. Si un programador pasa la mayor parte de su tiempo resolviendo un conjunto particular de problemas, eventualmente se volverá experto en ese tipo de problemas. Pero si ese programador se atasca con un tipo diferente de problemas, eso no descarta sus habilidades generales, simplemente señala las áreas en las que podrían querer trabajar.
 
 ## Midiendo el rendimiento del programador
 
-También hay una tendencia a medir la productividad del programador por cuántas contribuciones puede hacer el programador a un proyecto. Bajo ciertos sistemas de control de versiones, estos se denominan _commits_. Enumeran un conjunto de cambios que el programador desea realizar en el código. En una era en la que existen sitios para escribir código de manera colaborativa y social como Github o Gitlab, podemos revisar fácilmente los _commits_ que están realizando otros programadores. Dado que podemos medir la cantidad de _commits_, podemos usar esta medida para sentir que no estamos generando la misma cantidad y frecuencia de _commits_ que otros programadores. Y a diferencia de las medidas de antaño (líneas de código en particular, que mide cuántas líneas de código añade un programador a un programa), podemos revisar la calidad de sus _commits_ con un proyecto. Puede ser desalentador ver una gran cantidad de trabajo de calidad realizado por nuestros compañeros. También puede ser fuente de frustración y sentimientos de insuficiencia. "¿Por qué no puedo ser tan productivo o contribuir como esta otra persona?" nos preguntamos.
+También hay una tendencia a medir la productividad del programador por cuántas contribuciones puede hacer el programador a un proyecto. Bajo ciertos sistemas de control de versiones, estos se denominan _commits_. Enumeran un conjunto de cambios que el programador desea realizar en el código. En una era en la que existen sitios para escribir código de manera colaborativa y social como Github o Gitlab, podemos revisar fácilmente los _commits_ que están realizando otros programadores. Dado que podemos medir la cantidad de _commits_, podemos usar esta medida para sentir que no estamos generando la misma cantidad y frecuencia de _commits_ que otros programadores. Y a diferencia de las medidas de antaño (líneas de código en particular, que mide cuántas líneas de código añade un programador a un programa), podemos revisar la calidad de sus _commits_ con un proyecto. Puede ser desalentador ver una gran cantidad de trabajo de calidad realizado por nuestros compañeros. También puede ser fuente de frustración y sentimientos de insuficiencia. Nos preguntamos "¿Por qué no puedo ser tan productivo o contribuir como esta otra persona?"
 
 Es incluso todavía más frustrante cuando otras personas utilizan estas medidas para judgar la productividad y las contribuciones con código. Podemos encontrarnos siendo criticados por nuestros resultados (o la falta de estos).
 
 Los _commits_ y las líneas de código son las medidas más visibles de la productividad al crear código, pero no muestran mucho sobre la práctica real de la programación. No podemos medir la cantidad de tiempo que dedicamos a pensar en el problema con solo mirar un _commit_. No vemos las montañas de material de referencia que usó el programador para encontrar una solución y ciertamente no sabemos si este _commit_ es el resultado de una tarde de trabajo o de muchos días de trabajo (a menos que se hagan _commits_ con más frecuencia). Incluso podríamos descubrir que esta persona está actuando como el punto central de una organización y está integrando el trabajo de varias personas en sus _commits_.
 
-Medirnos a nosotros mismos basándonos en la cantidad de la producción de otras personas es fácil y muy seductor pero no es útil para hacerse una idea de cómo mejorar nosotros mismos en nuestra tarea de crear código (a no ser que sea "generando más _commits_). Esa forma de pensar puede llevarnos a creer que no estamos dedicando el tiempo suficiente a la "programación real" y provocar exceso de trabajo, estrés y agotamiento.
+Medirnos a nosotros mismos basándonos en la cantidad de la producción de otras personas es fácil y muy seductor pero no es útil para hacerse una idea de cómo mejorar nosotros mismos en nuestra tarea de crear código (a no ser que sea "generando más _commits_"). Esa forma de pensar puede llevarnos a creer que no estamos dedicando el tiempo suficiente a la "programación real" y provocar exceso de trabajo, estrés y agotamiento.
 
 ## Compañeros de viaje
 
-Hay momentos en los que es útil compararnos con otros programadores. A veces podemos aprender sobre nuevas tecnologías o nuevas metodologías mirando el trabajo de otros, pero es fácil caer en la trampa de pensar que porque no estamos al nivel de otros programadores somos de alguna manera inferiores a ellos. En lugar de ver a otros programadores como competencia, deberíamos verlos como compañeros. Todos estamos en esta profesión trabajando para mejorar nuestros respectivos proyectos. Con el software libre y de código abierto tenemos una oportunidad única de ver cómo otras personas hacen su trabajo en público. Podemos aprender del código de otros de la misma manera que los científicos pueden mirar los artículos de otros científicos para ver qué funcionó (y pueden mejorar la validez del artículo con una réplica y repetición). Ningún programador está completamente aislado del trabajo de los demás. (Es raro que un programador haya creado el código de todo su entorno de programación desde cero sin el trabajo de otras personas). Todas las personas aprendemos unas de otras, pero en lugar de intimidarnos por el trabajo de otras, podemos desarmarlo y aprender de él. Si tenemos suerte, podemos aprovechar la oportunidad para preguntarles cómo funciona el código y por qué eligieron escribir el código de esa manera.
+Hay momentos en los que es útil compararnos con otros programadores. A veces podemos aprender sobre nuevas tecnologías o nuevas metodologías mirando el trabajo de otras personas, pero es fácil caer en la trampa de pensar que porque no estamos al nivel de otros programadores somos de alguna manera inferiores a ellos. En lugar de ver a otros programadores como competencia, deberíamos verlos como compañeros. Todos estamos en esta profesión trabajando para mejorar nuestros respectivos proyectos. Con el software libre y de código abierto tenemos una oportunidad única de ver cómo otras personas hacen su trabajo en público. Podemos aprender del código de otros de la misma manera que los científicos pueden mirar los artículos de otros científicos para ver qué funcionó (y pueden mejorar la validez del artículo con una réplica y repetición). Ningún programador está completamente aislado del trabajo de los demás. (Es raro que un programador haya creado el código de todo su entorno de programación desde cero sin el trabajo de otras personas). Todas las personas aprendemos unas de otras, pero en lugar de intimidarnos por el trabajo de otras, podemos desarmarlo y aprender de él. Si tenemos suerte, podemos aprovechar la oportunidad para preguntarles cómo funciona el código y por qué eligieron escribir el código de esa manera.
 
-Es valioso hacer preguntas a nuestros compañeros programadores. Tendemos a pasar por alto hacer preguntas por miedo a que vamos a hacer algo obvio o hacer una pregunta que nos haga sentir incómodos para preguntar. Hacer preguntas es muy útil cuando no entendemos qué está pasando con una idea o una pieza de código en particular. Hay programadores a los que no les importa responder preguntas, y espero que los encuentres. De acuerdo, hay algunos programadores que están muy ocupados y es posible que no tengan el tiempo o la predisposición para responder preguntas, pero si realmente estamos atascados y hemos agotado todas las demás vías, tal vez podamos hacerles preguntas que no requieran mucho de su tiempo y esfuerzo. Incluso pueden estar agradecidos por la pregunta porque les da una idea de una perspectiva que de otro modo no tendrían. Cuando hacemos preguntas iniciamos un intercambio de ideas en ambas direcciones.
+Es valioso hacer preguntas a nuestros compañeros programadores. Tendemos a pasar por alto hacer preguntas por miedo a que vamos a hacer algo obvio o hacer una pregunta que nos haga sentir incómodos por preguntar. Hacer preguntas es muy útil cuando no entendemos qué está pasando con una idea o una pieza de código en particular. Hay programadores a los que no les importa responder preguntas, y espero que los encuentres. De acuerdo, hay algunos programadores que están muy ocupados y es posible que no tengan el tiempo o la predisposición para responder preguntas, pero si realmente estamos atascados y hemos agotado todas las demás vías, tal vez podamos hacerles preguntas que no requieran mucho de su tiempo y esfuerzo. Incluso pueden estar agradecidos por la pregunta porque les da una idea de una perspectiva que de otro modo no tendrían. Cuando hacemos preguntas iniciamos un intercambio de ideas en ambas direcciones.
 
-Hacer preguntas es todo un arte y puede ser frustrante cuando las personas no responden nuestras preguntas o nos responden con otras preguntas y sugerencias que son menos que útiles. Esto se manifiesta en intercambios donde la persona A pregunta: "Me gustaría saber cómo hacer X" y las personas B y C responden "Yo en su lugar haría Y". Es frustrante cuando la gente no responde a nuestras preguntas de manera directa. También es fácil verse envuelto en intercambios con la gente sobre los méritos de hacer Y donde Y fue sugerido por otra persona que no tiene nada que ver con la pregunta original sobre X. Pero si volvemos a enmarcar la experiencia como "esta persona está tratando de ayudarme, tal vez haya algo en esta recomendación que pueda ser útil", entonces podemos tener una mejor conversación. Quizás lo que estamos preguntando no es la mejor manera de hacer algo y hacer una pausa para escuchar puede ayudarnos a comprender mejor por qué hicieron su sugerencia.
+Hacer preguntas es todo un arte y puede ser frustrante cuando las personas no responden nuestras preguntas o nos responden con otras preguntas o sugerencias que son menos que útiles. Esto se manifiesta en intercambios donde la persona A pregunta: "Me gustaría saber cómo hacer X" y las personas B y C responden "Yo en su lugar haría Y". Es frustrante cuando la gente no responde a nuestras preguntas de manera directa. También es fácil verse envuelto en intercambios con la gente sobre los méritos de hacer Y donde Y fue sugerido por otra persona que no tiene nada que ver con la pregunta original sobre X. Pero si volvemos a enmarcar la experiencia como "esta persona está tratando de ayudarme, tal vez haya algo en esta recomendación que pueda ser útil", entonces podemos tener una mejor conversación. Quizás lo que estamos preguntando no es la mejor manera de hacer algo y hacer una pausa para escuchar puede ayudarnos a comprender mejor por qué hicieron su sugerencia.
 
 El sacar nuestros egos de la pregunta nos permite estar más abiertos a las respuestas que recibimos. Cuando las personas no entienden nuestra pregunta, es fácil tomarla como algo personal y protestar pensando "no me entienden" o "no me escuchan". Al abstraernos de la pregunta nos permite tomar lo valioso de la respuesta proporcionada "tal cual" y nos da la capacidad de cambiar la pregunta según sea necesario para obtener mejores respuestas.