Llevar sólo lo necesario

Un monje iba por el camino. Debía de llegar al monasterio antes de que cayera la noche.

A mitad del viaje, con el sol fuerte brillando sobre su cabeza, encontró una sombrilla vieja que alguien había tirado. Qué suerte pensó, mientras la abría y contemplaba el cielo azul a través del agujero que tenía. No era demasiado grave y le sirvió muy bien para tener algo de sombra.

Un poco más allá, encontró una vieja olla de bronce. La llevó a un arroyo cercano y admiró el bonito brillo que aparecía cuando la iba puliendo con la arena. Le pareció que se vería muy bonita en la cocina del monasterio, y podría preparar algo allí esa misma noche.

Pensaba en qué podrían preparar para cenar, cuando vio a un granjero que cosechaba papas. Le preguntó si les regalaba algunas y el granjero le dio un par, pero le dijo que le daría un saco si le ayudaba un rato. Imaginando lo contentos que se pondrían en el monasterio, aceptó y ayudó a recoger y embolsar varios sacos de papas. El granjero le agradeció mucho mientras le ayudaba a ponerse el saco sobre los hombros.

Así pues, reanudó el monje su viaje. Aún hacía algo de sol, pero tenía los dos brazos sosteniendo el saco sobre sus hombros, así que la sombrilla iba enrollada y colgada de su cintura, y también la olla de bronce. Todo era un poco pesado, así que descansaba cada cierto trecho.

Para cruzar el río, había un ligero puente hecho de paja que se balanceaba de lado a lado cuando los viajeros pasaban por él. Se dio cuenta que no podría sujetarse bien al puente y sostener el saco al mismo tiempo.

Entonces recordó que había río arriba un puente de madera por el que podían cruzar los carros y caballos. Así que tomó el camino a la montaña, mientras el sol de la tarde le alumbraba ya las espaldas en su descenso.

IDEA
Lo que se recoge en el camino está bien pero hay que saber cuando dejarlo, no sobrecargar el simple viaje

Señales de que debes escribir mejor tu código

Si necesitas un diccionario para entender el nombre de una variable.

Los nombres deberían ser autoexplicativos. Recordar un mapa de nombres vs acrónimos mientras lees código es sobrecarga mental.

Los nombres deberían ser comprensibles fácilmente pero tan simples como sea posible.

Tener que ignorar prefijos no relevantes mientras lees código es sobrecarga mental.


Si necesitas una herramienta auxiliar (como un debugger o papel y lápiz) para comprender cómo se está usando una variable.

Lo que le ocurre a una variable debería ser claro y simple.

Los patrones de uso deberían ser los que espera encontrar un desarrollador estándar.

El código mágico es el que necesita compilación mental para ser comprendido. Puede ser ingenioso, sofisticado, extrañamente hermoso, pero es sobrecarga mental.

Hay muchos programadores que tratan de explicar verbalmente una estrategia, un diseño, un algoritmo. Pienso que si no somos capaces de expresarlo visualmente, de dibujarlo, es que no lo hemos comprendido lo suficiente.

Jugar ajedrez mentalmente puede ser algo curioso, desafiante, admirable. Pero tener que mantener una representación mental de la posición de las piezas es sobrecarga mental. Un territorio del que no puedes alejarte demasiado para explorar las opciones disponibles. La mayoría de las personas juega mejor y realiza jugadas de mejor calidad cuando ve claramente las piezas sobre un tablero.

Cómo escribir código

Escribe el código como te gustaría que fuera el código que leerás de otra persona. Porque pronto serás esa persona.

Antes de escribir código piensa en quién lo usará, además de la computadora. Y además de ti. Recuerda que en unos días no serás tú ahora.

Las cosas deberían ser tan simples como sea posible para el desarrollador a quien va dirigido.

Es importante entender que no se trata de escribir menos líneas de código ni usar menos paquetes. Se trata de procurar que los procesos sean simples de ver, recorrer y desarrollar, aún a costa de usar más líneas de código y más paquetes. No se trata de «menos es más»; se trata de «más simple es mejor».

Lo simple y claro es más difícil de conseguir de lo que parece, y un reto intelectual y espiritual más constructivo.

Lo primero es la gente. Luego la solución, luego el producto, luego el código. Como programador, lo que tocas es código, pero si tu guía es sólo el código, es hora de tomar un respiro y contemplar las cosas desde una perspectiva más amplia. Cuando navegas, siente el agua y la espuma y el viento, pero guíate por algo más allá.

La vanidad y la ostentación parecen surgir por la necesidad de seguridad, de autoafirmación. Procura que la gente esté segura y sea reconocida, para que no necesiten reclamarlo a través de florituras. Ayuda a que se sientan honestamente bien. Uno construye con lo que tiene en el corazón.

Tú no eres tú código. Tú no eres tus obras. Tú no eres tus hijos. Eres el canal elegido para que ellos existan. Honra ese honor. Honra tu inspiración. Respeta su existencia. Acepta que su valor puede estar más allá de tus intenciones iniciales y de tu comprensión.

• https://www.ted.com/talks/elizabeth_gilbert_on_genius