Tinselcity

Resolver problemas

Hay un pequeño juego de móvil que uso de vez en cuando. Más que un juego es una recopilación de un montón de diferentes puzzles de lógica. Algunos se parecen entre sí, pero en general cada uno tiene diferentes mecánicas y poder ir cambiando de uno a otro hace que se mantengan como un entretenimiento casual para pequeños ratos. Los puzzles originalmente vienen de aquí.

Tienen, como todos los puzzles similares, un pequeño problema: llega un momento en que los resuelves. Uh, ¿no es ese el objetivo? Ah, quiero decir… llega un momento en que resuelves el problema general, encuentras las reglas o pasos que te llevan a resolver cualquier “instancia” del puzzle. Se vuelve mecánico.

Una cosa buena que tiene el jueguecito de Chris Boyle, es que te deja que aumentes la dificultad todo lo que quieras. En general, casi siempre, la forma de aumentar esa dificultad es aumentando el tamaño del puzzle. Es decir, un puzzle como por ejemplo signpost en un tamaño de 4×4 se resuelve de forma casi trivial. El mismo puzzle en un tamaño de 20×20 se hace sustancialmente más complicado. Todo tiene un limite, claro, porque en la pantalla de mi móvil más de, digamos, 10×10, se hace difícil de usar con mis dedos y mis ojos. Pero aún así, sigo jugando de vez en cuando en niveles de dificultad que lo mantengan por lo menos entretenido para unos minutos.

Las "reglas"

La mayoría de los puzzles tienen una serie de reglas que se pueden aplicar de forma totalmente mecánica con las que se puede llegar a resolver los puzzles hasta tamaños relativamente grandes. Sí, sin más. Sigues las reglas, clic, clac, cloc, y todo encaja y se resuelve sin tener que pensar demasiado.

Cuando abordas tamaños mayores, complejidades mayores, ocurren dos cosas. En general lo que siempre ocurre es que el juego tiende a volverse más “aburrido”. O quizá debería decir que se vuelve menos una diversión y más un reto. La segunda cosa que ocurre es que, con la experiencia que has ido ganando al llegar a estos retos, vas encontrando nuevas “reglas”. Porque en general las primeras reglas son bastante sencillas, pero muchos de las topografías de los puzzles hacen que escondan además, reglas más sofisticadas.

Un ejemplo típico es slant. En slant primero descubres las reglas más sencillas, en las que intervienen, por ejemplo, 2 nodos adyacentes con ciertos valores.

Por ejemplo, estos dos unos nunca pueden unirse Por ejemplo, estos dos unos nunca pueden ir unidos.

Pero a medida que vas jugando encuentras reglas en las que intervienen otras configuraciones, más complejas, con más nodos, etc

Y aquí me da igual todo lo demás pero esas 4 conexiones deben ir así. Y aquí, da igual todo lo demás; esas 4 conexiones deben ir así.

En fin, la mayoría de los puzzles terminan resolviéndose de manera mecánica sin necesidad ninguna de fuerza bruta o prueba y error.

Aprendizaje

Lo interesante es que ese aprendizaje lo haces a base de experiencia. De jugar repetidas veces, de enfrentarte a patrones que se van repitiendo. Aprendes a identificar esos patrones, luego las reglas que hay detrás de ellos y cómo se solucionan de forma general. A veces, encuentras reglas derivadas, aplicables de forma más general que otras. Por ejemplo, en ese último patrón de slant, no importa cuántos doses haya entre los dos unos. Ninguno, uno, ocho… Es igual. Cualquier secuencia similar implica que esas cuatro líneas deben ir así.

Con el tiempo parece que llegues a olvidar por qué cierto patrón se resuelve así. Parece que te quedes solo con la solución. Parece. Lógicamente, si haces las cosas bien, no lo olvidas realmente. Lo que haces es interiorizar el patrón. Sabes que es así. Lo has resuelto muchas veces y ya no necesitas resolverlo más porque lo comprendes de una forma más inmediata.

Aunque, como decía, la mayoría de puzzles se pueden llegar a resolver de forma totalmente mecánica, llega un momento en el que no merece la pena.

Experiencia

Cuando te enfrentas a los puzzles de tamaños más grandes terminas desarrollando pequeñas intuiciones. Confiar en ellas puede ser arriesgado. Es el punto en el que pasas de aplicar una regla que has identificado de forma clara y precisa, a aplicar soluciones que intuyes que son buenas pero de las que no tienes una confirmación explícita.

Esto representa un riesgo. Mejor dicho, representa dos riesgos diferentes.

Hay un riesgo más inmediato, más pequeño también, que es el de cometer un error. Aplicas una solución, resulta ser equivocada y has cometido un error. Un error en esta instancia, en este puzzle concreto. El coste de ese riesgo es variable pero en general limitado. Vas a tener que desandar unas cuantas jugadas, desde el momento actual donde has descubierto el error hasta el momento original en que hiciste esa jugada dudosa. Corriges la jugada original y luego arreglas todo lo que se hubiera derivado de ella. El error puede ser más o menos costoso, claro. Y ese coste normalmente depende de cuánto tiempo pasa desde que cometiste el error originalmente hasta que llegaste a la situación en la que te has dado cuenta de que hay un error. Quizá sólo necesitas deshacer un par de movimientos, quizá necesites deshacer casi todo el puzzle.

En cualquier caso es un riesgo con un coste limitado porque solo afecta a ese juego, a esa instancia del puzzle. El segundo riesgo que existe es más “profundo”. Es el riesgo de aprender mal y de no aprender bien. Si empiezas a aplicar reglas sin verificar puedes terminar creyendo que esas reglas son correctas cuando no lo son. Porque quizá funcionan sólo bajo unas circunstancias específicas o en una situación concreta, pero no de forma general como tú crees. Has aprendido mal. Has aprendido algo que no es correcto. Y a la vez, al no verificar tu conocimiento, es muy probable que no hayas llegado a una regla correcta que puede estar ahí realmente pero que necesitaba que dieras algunos pasos más hasta ella. Has dejado de aprender bien.

Un último detalle de interés es que, en ocasiones y como adelantaba antes, puede llegar un momento en que no merezca la pena resolver el puzzle de forma completamente mecánica, exclusivamente mediante la aplicación de reglas probadas.

En un caso como el de filling hay una serie de mecánicas que puedes ir aplicando gradualmente hasta llegar a la solución. Pero también hay muchas situaciones en las que ocurre que el coste de cometer un error es suficientemente bajo como para que sea más rentable simplemente probar. Eso sí, probar de una forma ordenada y razonable. Filling te permite que, llegados a una solución parcial segura1), cometas algunos errores pequeños con un coste muy bajo, sin tener que deshacer movimientos sino simplemente ajustando y corrigiendo. Es más, en ocasiones, aplicar una solución aproximada te deja ver las limitaciones de la misma y cómo debe ser corregida para que sea correcta, con un coste menor que aplicando estrictamente movimientos mecánicos.

Desarrollar software

En cierta medida, desarrollar y aprender a desarrollar software conlleva un proceso similar al de estos puzzles.

Hay diferencias, por supuesto. El coste de los errores puede ser tremendamente variable y se puede tratar de formas muy distintas. También puede pasar muchísimo más tiempo hasta que los descubres. También es verdad que algunas de las reglas no son tan estrictas y que muchas veces la solución no es en absoluto única como en estos puzzles.

En cuanto al aprendizaje, sin embargo, creo que sí que comparten unos fundamentos muy similares. Aprendes a través de la experiencia. Aprendes, en gran parte, haciendo. Haciendo, eso sí, de manera consciente e intencionada. Tratando de descubrir y entender esas reglas subyacentes. Buscando los porqués que te permitan verificar la corrección de una solución. Identificando las cosas que haces repetidamente y los resultados que obtienes. Dedicando algún rato también a investigar cierta solución, cierta regla, cierta mecánica, su aplicabilidad, su validez.

Y por supuesto aprendes evitando aprender mal. Evitando supersticiones como “ahora se lanza esta herramienta, aunque no sé por qué” y “esta línea de código hay que ponerla aquí; no sé para qué sirve pero así funciona”. Y sobretodo siendo responsable de lo que haces. Demasiados desarrolladores evitan tener que responsabilizarse de sus errores haciendo que sean otros los que tengan que venir luego a arreglar los problemas que dejan.

A veces, también, aprendes despejando tu mente de otros problemas durante unos minutos con un jueguecito.

1)
Es decir, habiendo aplicado reglas mecánicas probadas y verificadas hasta ese punto