2013/10/30

Ajedrez Mental

¿Qué tan buenas partidas de ajedrez puedes jugar mentalmente?

Imagina un grupo de personas reunido para resolver un problema. Luego de acomodarse en el lugar, comienzan a hablar. Y hablar. Y solamente hablar.

La reunión, usualmente tediosa, termina después de un tiempo, usualmente largo, donde los asistentes, usualmente cansados, han llegado a una solución, usualmente sub óptima.

En cambio, en otros lugares se usa una pizarra, o un papel mural, donde los participantes pueden expresar con libertad las ideas que van exponiendo.

Cuando el problema se puede ver escrito en un lugar, nos ahorra el esfuerzo de mantener su imagen mental, y así tenemos más energía para imaginar otras cosas. Quizás la solución. 

Es significativamente mayor el nivel de dificultad de los problemas que podemos resolver usando un diagrama o mapa de la situación en lugar de tratar de imaginar todo, todo el tiempo.

Cuando se trabaja mentalmente, probablemente la imagen mental de cada asistente sea distinta a la del otro. De modo que pronto se encuentran con malentendidos y discusiones fuera del tema. Es bastante fácil que la gente pierda la pista, desista, y finalmente se imponga la ley de la jungla de personalidades, favoreciendo a la más fuerte o carismática.

En cambio, un diagrama o mapa de conceptos está ahí mostrando de qué estamos hablando. Ayuda a mantener el foco de la reunión. Asegura los avances que se van logrando y permite construir una estructura. La sinergía se logra con más facilidad.

Y debería ser más obvio que eso habría de esperarse -si no lo es, habría que preguntarse dónde está escondido el león ;-)

Los tratos por escrito son más seguros que los realizados solo de palabra. Los comerciantes y abogados lo saben. Porque aun cuando las partes actúen honestamente, la memoria es frágil y puede recordar, o dejar de recordar, cosas que la otra persona no.

Los acuerdos escritos ayudan a que evitemos estar peleando una y otra vez las mismas batallas. Y cuando tenemos esa energía liberada, podemos emplearla para pasar al siguiente nivel de complejidad y desarrollo.

Inténtalo en tus reuniones. Escribe qué quieres lograr, escribe qué es lo que tienes y cuál es la situación. Experimenten con ideas de cómo podrían alcanzar lo que quieren. Escriban las conclusiones y acuerdos.

Podrás ver la partida que juegas. Podrás imaginar más variantes y jugadas. Será más fácil volver sobre ella y reflexionar. Será más fácil mejorar las cosas e ir mejorando.

2013/10/29

Solucionando problema vista dinámica en blogger

Puede ser que al usar la plantilla de vista dinámica en blogger, hayas notado que el fondo ya no aparece, o que la mayoría de imágenes no se ha cargado.

Esto se debería a que blogger colocó un script para prevenir que la carga de una página demorara demasiado.

Sin embargo, el tiempo asignado por default es muy poco. Y por eso paginas que antes cargaban bien ahora aparecen con aspecto tristón.

Para solucionarlo, ir al administrador del blog, entrar a Plantilla, Editar HTML y buscar al final del documento u código similar al siguiente:

<script language="javascript" type="text/javascript">
  setTimeout(function() {
    blogger.ui().configure().view();
  }, 1000);
</script>

Observar que he cambiado el 0 que estaba por 1000 milisegundos (1 segundo).

Guardar la plantilla y ver la mejora en la carga.

2013/10/02

Spaghetti code


Se nos ha enseñado acerca del código spaghetti. Como los producidos por abusar del goto en BASIC. O por abusar de los callbacks en Javascript.

Algunos se precipitan en afirmar que los goto no son buenos. Y aunque es un poco difícil afirmar lo mismo de los callbacks, a veces se apresuran en tomar esa postura.

Lo cierto es que el goto puede ser útil, igual que el callback. Lo que no nos parece bueno es el spaghetti que se produce cuando se abusa de ellos. Es importante notar la diferencia.

Los lenguajes de programación modernos tienen la tendencia a eliminar la posibilidad de abuso de goto limitando las estructuras de control de flujo. Es más fácil controlar un problema si no hay opción de que se produzca, en primer lugar.

Sin embargo, más allá de eso, resulta que desde el punto de vista de la máquina, tanto el código spaghetti como uno más estructurado son igualmente correctos y válidos. La buena estructura es una preferencia humana, para facilitar el desarrollo y mantenimiento. El spaghetti code le da igual a la máquina, es al humano el que tiene problemas con él. También es importante recordar eso.

Si hubiera alguna manera de moverse con facilidad y seguridad por el código spaghetti, no habría tanto problema. Me pregunto si habrá algún modo de manejar ese aparente caos, en lugar de evitar que se produzca.

Quizás nunca se puede evitar del todo la ocurrencia del caos, tan solo postergarlo lo más posible. Es conocido que, según crece un proyecto de desarrollo, es más complicado mantenerlo estructurado y oponerse al caos.

Pero, ¿sería posible manejar el caos, en lugar de huir de él? ¿alguna metodología? O, si es demasiado para un humano, ¿sería posible hacerlo con ayuda de un asistente?, ¿podríamos pasar de ser autoempleados en programación a procurarnos la ayuda de la computadora y pasar a otro nivel?