Hola 👋
¿Llegaste aquí porque alguien te dirigió a esta publicación en respuesta a alguna idea tuya sobre cómo se podría mejorar Exercism?
Antes de que nuestro equipo dedique tiempo a explorar tu idea, esperamos que leas esto y te preguntes si quizá ya se habrá considerado antes y qué trampas podría contener.
Al agregar esas consideraciones y las posibles trampas a tu sugerencia, y al pensar por qué puede que tu idea todavía no se haya implementado, es probable que recibas una respuesta más rápida y más positiva.
Entonces, ¿qué significa «la valla de Chesterton»?
La valla de Chesterton es una idea inspirada en una frase del libro de 1929 del escritor G.K. Chesterton, The Thing.
Se hizo famosa porque John F. Kennedy la citó.
Esta es la cita original:
En tal caso existe cierta institución o ley; digamos, para simplificar, una valla o un portón levantados en medio de un camino.
El reformador de tipo más moderno se acerca alegremente y dice: «No veo para qué sirve esto; vamos a quitarlo».
A lo que el reformador de tipo más inteligente hará bien en responder: «Si no ves para qué sirve, yo desde luego no voy a dejar que lo quites. Vete y piensa. Después, cuando puedas volver y decirme que sí ves para qué sirve, quizá te permita destruirlo».
La idea de la valla de Chesterton es que si no entiendes por qué está ahí algo, probablemente tampoco entiendes por qué debería quitarse.
Del mismo modo, si no entiendes por qué algo no está ahí, probablemente tampoco entiendes por qué se dejó fuera.
Una regla sencilla para recordar es: «No quites una valla hasta que sepas por qué se levantó en primer lugar».
¿Cómo se relaciona esta idea con Exercism?
En Exercism tenemos la suerte de que muchísima gente se une a nuestra comunidad todo el tiempo y comparte sus pensamientos e ideas.
Muchas de esas ideas son nuevas, innovadoras, emocionantes y desbloquean nuestra forma de pensar.
Así que si tienes una idea o una sugerencia, ¡es bienvenida!
Sin embargo, con más frecuencia la gente publica ideas que ya se han discutido muchas veces antes.
Responder a esas ideas y volver a abordar o justificar de nuevo nuestras decisiones puede agotar muchísimo a nuestro equipo.
Este artículo busca ayudar a proteger ese tiempo y esa energía.
Exercism ha sido diseñado, desarrollado y construido por miles de personas muy talentosas.
Es un producto muy intencional: las cosas están porque se diseñaron para estar, y muchas veces se dejan fuera porque se diseñaron para quedar fuera.
Casi todo en Exercism se ha debatido, discutido y rediseñado muchas veces.
Así que antes de publicar tu idea, pregúntate si quizá ya la consideramos y por qué puede que hayamos hecho las cosas de forma distinta a lo que propones.
Y recuerda: cuanto más obvia parezca tu idea, más probable es que ya se haya discutido y debatido muchas veces. Así que cuando la presentes, hazlo incluyendo las posibles advertencias y trampas.
Si tienes el impulso de decir «¿por qué no simplemente ...?», entonces casi con seguridad cae en esta categoría.
¡Nunca tengas miedo de publicar, pero eso sí, piensa bien las cosas primero!
¿Tienes un ejemplo?
Una frustración común es que los estudiantes envían a sus mentores código que no pasa los tests.
Una sugerencia igual de común es «¿Por qué no ejecutar automáticamente los tests en la CLI antes de que alguien envíe su código?».
Parece una gran idea: la CLI solo tendría que llamar a un comando para ejecutar los tests y no dejar que el estudiante envíe si están rotos.
Entonces, primero: ¿qué significa «solo llamar a un comando para ejecutar los tests»?
Significa escribir un script para cada uno de los 52 lenguajes de Exercism que pueda ejecutar los tests y comprobar el resultado.
Es un poco de trabajo, pero es factible.
Pero también significa escribir ese script para que funcione en Windows, MacOSX y Linux, en todas y cada una de las versiones y configuraciones posibles. Eso es muchísimo trabajo (por no decir una cantidad ilimitada).
«¿Por qué tiene que ser todas las configuraciones?», quizá preguntes.
Bueno, porque estarías bloqueando activamente a alguien para que no use Exercism a menos que pueda ejecutar este script.
Eso también significa que nunca puede fallar.
Si por alguna razón el script no se ejecuta, el estudiante queda totalmente bloqueado.
Un bug en uno de esos scripts 52*3*n significa que un estudiante ya no puede usar el track en ese sistema operativo.
¿Cómo pruebas eso?
No puedes.
Pero, dirás, podrías simplemente agregar un flag --skip-tests.
Es una buena sugerencia, pero nos lleva de vuelta a nuestro punto de partida: la gente puede elegir saltarse los tests cuando quiera.
Salvo que ahora estamos en una situación en la que es un poco menos probable que se envíen tests rotos, así que los mentores lo esperan menos, lo que significa que resulta más chocante y confuso cuando los tests sí están rotos.
«Pero la gente no haría eso en general», podrías argumentar. Cierto, para algunos lenguajes en los que ejecutar los tests tarda 0,5 s.
Pero para los lenguajes en los que ejecutar los tests tarda 20 s, tener que esperar 20 s extra para enviar resulta increíblemente frustrante para los estudiantes, así que saltarse los tests finales se volvería algo habitual.
Sin importar en qué termine esta conversación, está claro que aquí hay mucha más complejidad de la que parece a primera vista. Hay retos técnicos que considerar, problemas de flujo de trabajo que analizar y la constatación de que los tracks difieren tanto entre sí que algo rápido y fácil para uno resulta doloroso para otro.
Así que en lugar de plantear la sugerencia de «por qué no ejecutar los tests antes de enviar», hagamos una pregunta: «¿Por qué la gente publica soluciones que no pasan los tests?».
Y entonces las cosas se ponen interesantes.
La respuesta general es que están atascados o confundidos.
Y necesitan ayuda.
Lo que significa que enviar tests rotos es una heurística muy importante para los mentores: que este estudiante necesita ayuda.
Sí, es frustrante porque los mentores no saben de inmediato si el código es «correcto» o no. Sin embargo, pueden descargar el código y ejecutarlo para verificarlo (algo que la mayoría de los mentores hace en las soluciones no triviales) y así saber con un 100 % de certeza si es correcto o no.
Y los estudiantes que están atascados y necesitan ayuda no terminan más atascados, necesitando más ayuda, sino que llegan a un mentor que puede ver y sugerir correcciones más rápido.
Nota: en realidad estamos resolviendo esto ejecutando los tests del lado del servidor, una empresa grande y costosa, pero que vale la pena por la mejor experiencia del estudiante y, sobre todo, porque ahorra tiempo y energía a nuestros mentores.
¿Algo más?
Tres cosas:
-
Este artículo de Second Order Thinking vale la pena leerlo. La cita «No quites una valla hasta que sepas por qué se levantó en primer lugar» es de esta publicación.
- El libro The Thing de G.K. Chesterton está disponible aquí: https://archive.org/details/G.K.ChestertonTheThing.
- Tu idea puede ser de verdad nueva y genial. ¡No tengas miedo ni vergüenza de sugerirla!
