Hola 👋
¿Estás aquí porque alguien te ha dirigido a esta publicación en respuesta a una idea que propusiste sobre cómo se podría mejorar Exercism?
Antes de que nuestro equipo dedique tiempo a explorar tu idea, esperan que leas esto y te plantees si puede que alguien ya la haya pensado antes y qué escollos podría esconder.
Si añades esas consideraciones y los posibles escollos a tu propuesta, y te planteas por qué puede que tu idea no se haya implementado ya, es probable que recibas una respuesta más rápida y más positiva.
¿Qué significa «la valla de Chesterton»?
La valla de Chesterton es una idea inspirada en una cita del libro The Thing, que el escritor G.K. Chesterton publicó en 1929.
Se hizo muy conocida porque John F. Kennedy la citó.
Esta es la cita original:
En tal caso existe una determinada institución o ley; digamos, para simplificar, una valla o una puerta levantada en medio de un camino.
El reformador de tipo más moderno se acerca alegremente a ella 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 tú no ves para qué sirve, yo desde luego no te voy a dejar que lo quites. Vete y piensa. Cuando vuelvas y me digas que sí ves para qué sirve, puede que te permita destruirlo».
La idea de la valla de Chesterton es que, si no entiendes por qué está ahí algo, probablemente tampoco entiendas por qué debería quitarse.
Del mismo modo, si no entiendes por qué algo no está ahí, probablemente tampoco entiendas por qué se ha dejado fuera.
Una regla sencilla para recordar es: «No quites una valla hasta que sepas por qué se puso ahí en primer lugar».
¿Y esto qué tiene que ver con Exercism?
En Exercism tenemos la suerte de que continuamente se une muchísima gente a nuestra comunidad y publica sus reflexiones e ideas.
Muchas de esas ideas son nuevas, innovadoras, emocionantes y nos desbloquean la mente.
Así que, si tienes una idea o una sugerencia, ¡nos encantará recibirla!
Sin embargo, lo más habitual es que la gente publique ideas que ya se han debatido muchas veces antes.
Responder a esas ideas y volver a abordar o a justificar nuestras decisiones puede agotar muchísimo a nuestro equipo.
Este artículo pretende ayudar a proteger ese tiempo y esa energía.
Miles de personas muy talentosas han diseñado, desarrollado y construido Exercism.
Es un producto en el que todo es intencionado: las cosas están porque se ha diseñado que estén, y a menudo se dejan fuera porque se ha diseñado que se queden fuera.
Casi todo lo relacionado con Exercism se ha debatido, discutido y rediseñado muchas veces.
Así que, antes de publicar tu idea, pregúntate si es posible que ya la hayamos considerado 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, preséntala con las posibles salvedades y los posibles escollos ya incluidos.
Si sientes el impulso de decir «¿y por qué no simplemente...?», casi con toda seguridad cae en esta categoría.
¡Que nunca te dé miedo publicar, pero piénsalo bien antes!
¿Tienes algún ejemplo?
Una frustración habitual es que los estudiantes envíen a los mentores código que no pasa los tests.
Una sugerencia igual de habitual es: «¿Y 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 no tiene más que llamar a un comando para ejecutar los tests y no dejar que el estudiante los envíe si fallan.
Así que, en primer lugar, ¿qué significa «simplemente llamar a un comando para ejecutar los tests»?
Significa escribir un script para cada uno de los 52 lenguajes de Exercism que sea capaz de ejecutar los tests y comprobar el resultado.
Es un poco de trabajo, pero es factible.
Pero también significa escribir ese script de forma que funcione en Windows, MacOSX y Linux, en todas y cada una de las versiones y configuraciones posibles. Eso supone muchísimo trabajo (por no decir una cantidad ilimitada).
«¿Y por qué tiene que ser cada configuración?», te preguntarás.
Pues porque estarías bloqueando activamente a alguien para que no pueda usar Exercism a menos que consiga ejecutar ese script.
Eso también significa que nunca puede fallar.
Si por algún motivo el script no se ejecuta, el estudiante se 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 se prueba eso?
No se puede.
Pero, dirás, bastaría con añadir un flag --skip-tests.
Es una buena sugerencia, pero nos devuelve al punto de partida: que la gente puede saltarse los tests siempre que quiera.
Solo que ahora nos encontramos en una situación en la que es algo menos probable que se envíen tests rotos, así que los mentores lo esperan menos, lo que hace que sea 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, en algunos lenguajes en los que ejecutar los tests tarda 0,5 s.
Pero en lenguajes en los que ejecutar los tests tarda 20 s, tener que esperar 20 s de más para enviar resulta increíblemente frustrante para los estudiantes, así que saltarse los tests finales se volvería algo habitual.
Independientemente de en qué acabe 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 pensar y la constatación de que los tracks difieren lo bastante como para que algo rápido y sencillo para uno sea un suplicio para otro.
Así que, en lugar de plantear la sugerencia de «¿y por qué no ejecutar los tests antes de enviar?», hagamos una pregunta: «¿Por qué publica la gente soluciones que no pasan los tests?».
Y entonces la cosa se pone interesante.
La respuesta general es que están atascados o confundidos.
Y necesitan ayuda.
Lo cual significa que enviar tests rotos es una pista muy importante para los mentores de que ese 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 (cosa que la mayoría de los mentores hace con las soluciones no triviales) y entonces saben con un 100 % de certeza si es correcto o no.
Y los estudiantes que están atascados y necesitan ayuda no acaban más atascados ni necesitando más ayuda, sino que llegan a un mentor que puede ver las correcciones y sugerirlas más rápido.
Nota: En realidad estamos resolviendo esto ejecutando los tests en el servidor, una empresa grande y costosa, pero que merece la pena por la mejora en la 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 merece la pena leerlo. La cita «No quites una valla hasta que sepas por qué se puso ahí en primer lugar» proviene de esta publicación.
-
The Thing, de G.K. Chesterton, está disponible aquí: https://archive.org/details/G.K.ChestertonTheThing.
- Es posible que tu idea sea de verdad nueva y buena. ¡No tengas miedo ni vergüenza de proponerla!
