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

Sobre frameworks

Algunos desarrolladores dicen que prefieren no usar frameworks.

Empiezan desde cero y van completando el sistema con ayuda de los patrones y librerías que les parecen más adecuados.

Felicidades, eso es un framework. Cualquier desarrollador que quiera corregir o agregar algo al sistema tendrá que familiarizarse con las peculiaridades de ese nuevo esquema.

Seamos claros. Siempre se usa un framework. Si no es el de los demás, es el tuyo. Si no lo tienes hecho, irá surgiendo en el proceso.

¿Cuál es la ventaja de un framework propio? Que si el desarrollo es reciente probablemente estés muy familiarizado con él y puedas hacer cualquier cosa más rápido y mejor que alguien que no lo conoce (todos los demás).

En cierto modo, usar un framework propio, alimenta la ilusión de falsa competencia, porque eres el mejor en el juego (que nadie ha practicado tanto como tú).

Por supuesto que hay proyectos que requieren una solución a la medida, particular y específica. ¿Pero pertenece tu proyecto a ese grupo exclusivo de clientes que necesita un sastre? ¿O es como el 90% de los proyectos usuales? Quizás seas un buen costurero, quizás seas un buen sastre, pero, ¿que es lo que realmente necesita el cliente? ¿se sentirá cómodo en la playa con sus shorts de diseño? (el cual no puede forzar mucho porque no ha sido tan probado como los más baratos shorts que pudo haber elegido).

Muéstrame alguien que reniegue de usar un framework conocido y posiblemente encontremos que, aunque sea buen programador, no domina ninguno. Es natural querer usar lo que mejor manejamos, pero no es justo negar la virtudes de lo que no hemos probado o aún no conocemos a profundidad.

No existe tal cosa como un proyecto hecho sin frameworks, sólo con estándares. Lo que en realidad hay es un nuevo framework surgido en el transcurso del desarrollo, impregnado con las particulares opiniones del desarrollador sobre como se deben hacer las cosas correctamente, probablemente con escasa documentación y comunidad mínima (esas cosas requieren más horas hombre que las que pueda pagar cualquier cliente).

Existe la posibilidad de que el nuevo framework tenga alguna ventaja sobre los demás. Entonces, la manera más eficiente de que evolucione es que se vuelva open source. Si realmente es bueno, la comunidad llegará para usarlo, probarlo, documentarlo y difundirlo.

Encontrarás muchas razones por la que un proyecto open source es una mejor opción para hacer mejor software.

Cuando se hace software es importante reutilizar aquello que es bueno. Para reutilizar software, o para mantenerlo, con comodidad, es importante documentación y ejemplos. Para documentar y discutir casos y soluciones, una buena comunidad es grandiosa.

Pienso que un software es mejor cuanto más mantenible es. Algunos piensan que es mejor lo que corre más rápido, pero no se puede hacer muchas optimizaciones sobre código ilegible (y la optimización prematura es el camino a todo tipo de problemas). Otros piensan que es mejor software si usas menos líneas de código, pero no podrá evolucionar con facilidad si esa obsesión de menos líneas conduce a código menos legible que requiera numerosos hacks mentales tan sólo para aclarar la intención.

Además, el código lo va a correr una computadora, a la que le da lo mismo. Todas esas cosas de buenas prácticas, organización, frameworks, etc, no es por ellas, sino para la gente. Así que es más importante escribir buen código para la gente.

Pienso que un código es más mantenible si es más legible y si es más fácil de depurar. No importa que sea muy largo o parezca inocente, porque esa sencillez permitirá obtener versiones optimizadas también con facilidad.

Aprender un framework cuesta, pero usar un framework conocido puede hacer que tu proyecto sea más mantenible y una mejor opción para tu cliente. Si te gusta crear cosas nuevas, suele haber espacio para plugins (y mejor feedback para tu trabajo). Si quieres realmente ser autor de un framework, aprenderás mucho de la comunidad antes de intentar crear una. Puede que te ayude tener mejor perspectiva conocer a otros con muy alto nivel colaborando con entusiasmo en proyectos open source. Aprenderás a valorar la gran cantidad de tiempo y conocimientos que se puede condensar en un proyecto abierto, más allá de lo que puedas imaginar.

Reutilizar código

Hay programadores que parecen tomar la reutilización de código como un mandamiento que hay que cumplir mecánicamente para ser un buen programador.

Pero, como aprendimos con los diez mandamientos, la bondad de algo no está tanto en obedecer mecánicamente sino en comprender el por qué.

Reutilizar código es importante, ¿para qué?

No es por la computadora, a quien le da igual ejecutar el mismo código repetido.

Tampoco el espacio en disco, que es generalmente muy económico.

La importancia de reutilizar código es para facilitar su mantenimiento.

Entonces, se ve con más claridad que no se trata de forzar un componente A para que pueda hacer lo mismo que otro componente B y así quedarnos con un solo componente AB cargado de lógica extra para diferenciar ambos casos y más difícil de mantener.

Más importante siempre es desarrollar componentes que realicen con claridad una función específica.

Componente A para un tipo de función. Componente B para otro tipo de función.Si se nota que hay un parecido entre A y B, una opción es factorizarlos, extraer el común componente C que ambos parecen compartir naturalmente. C es reutilizado por A y B.

Otra opción es ver a ambos como casos particulares de un componente D. D es reutilizado por A y B.

Otra opción es ver a uno como caso particular del otro. A es reutilizado por B, o viceversa.

¿Cuál elegir? El que sea más simple de mantener. El objetivo principal no es que tenga que tipearse menos o ganar el récord de menos líneas de código. No es cierto que menos código sea mejor. Si el problema no lo requiere, la obsesión por menos código se convierte más en una cuestión de gustos.

Lo que es cierto es que es el código más simple es mejor; es más fácil de comprender y compartir.

También es más fácil de mejorar porque deja más espacio mental para pensar en el siguiente paso.

El objetivo principal de reutilizar código es que sea más fácil de mantener. Que se pueda comprender con naturalidad, sin necesidad de excesiva gimnasia mental ni sofisticado debug.

En código que debe ser mantenido por humanos no se trata de «menos es más»; se trata de «más simple es mejor».

Como en un iceberg

Lo que se ve es solo una pequeña parte del total. 90% del iceberg yace debajo del agua.

El código fuente final luce de cierta manera. Pero no se llega directamente a él. En la resolución de un problema, hay muchos esbozos, intentos de diversas aproximaciones, hasta ir descubriendo la solución. Recién una vez encontrada, se va optimizando hasta llegar a la versión final.

Todos esos pasos previos, y el andamiaje necesario, es lo que no se ve. E igual que en el iceberg, aquello que vemos no sería posible sin lo que no se ve.

Si intentas trabajar queriendo lograr directamente la versión final, te llevarás un chasco. Es como querer llegar al décimo escalón de un brinco. Te puedes ir de nariz. O a lo mejor lo logras, pero quizás seas un atleta olímpico. Es mejor subir paso a paso cada escalón hasta llegar al décimo.

Aceptado eso, suena fácil. Si no fuera por la cultura que juega en contra. Hay muchas cosas del colegio y la familia en contra de fallar. Quién sabe por qué, porque cuando resuelves problemas te das cuenta que fallar es parte natural del proceso de solución.

Así que, cuando intentas resolver un problema paso a paso, de rato en rato aparecerá esa voz (tuya, de tu compañero, o de tu jefe), diciendo: "Ya estás cerca, qué tal si brincamos unos escalones, sería genial". No. No y no. Cada paso brinda información. Brincarse los pasos es renunciar a eso.

Parece que es una tentación común en alguien que empieza a conocer un tema el subestimar el valor de la experiencia. Puedes aprender algo en un día, pero hasta que no hayas hecho el ejercicio diez veces, yo diría que aún no habrás conocido aquellas cosas que solo la experiencia te da.

Aprendes un algoritmo. Ok. Aplícalo en diez casos distintos. Aprendes a usar un framework. Ok. Haz diez proyectos diferentes. Intenta hacer a tu modo diez cosas interesantes que veas por allí. Atiende diez pedidos de tus clientes. De cada diez intentos, nueve no salen tan bien como esperabas. A partir de allí, yo diría que ya aprendiste eso.

Introducción

Pintar un cuadro. Escribir una historia. Hacer una casa.

Un cuadro. Una historia. Una casa.

Alguien ve la obra terminada e imagina a grandes rasgos cómo se pudo producir.

Pero si intenta producirlas con esos procedimientos imaginados, pronto se dará cuenta que la realidad puede ser muy diferente.

Por ejemplo, en el caso del cuadro. Como público podemos acercarnos y ver que las formas, luces y profundidad son producidas por aplicaciones de pintura. Algo relativamente fácil de comprender. Entonces, vas a la tienda y compras acrílico y un lienzo para intentar hacer algo parecido. Luego, después de mucho intentarlo en tu casa, vas descubriendo que no es tan fácil como parecía.

Del mismo modo con una historia. Están hechas de palabras. Sabemos escribir. Pero si intentas escribir un cuento, vas descubriendo que no es tan fácil decir algo interesante.

Y también con una casa. Puede ser ladrillo sobre ladrillo, o tabla junto a tabla. También yeso, cemento o pintura. Podemos conseguir esas cosas. Pero cuando intentas levantar la primera pared descubres que no es tan sencillo.

Y es que todas esas cosas, en realidad, se construyen gradualmente. Inician con garabatos, bocetos, maquetas. Se hace armazones y se aplican capas de trabajo sobre capas de trabajo. Se usan máscaras, apuntes, tablas, andamios y otros apoyos. Hay un montón de cosas que el público jamás ve.

Lo que el público ve es el resultado, la obra. Lo que el público no ve es la técnica que produjo la obra.

Para aprender esas técnicas, puedes tardar vidas enteras probando por tu cuenta, o puedes apoyarte en una comunidad que te facilite ese conocimiento. Puedes encontrarla en libros, en institutos o universidades, y en comunidades profesionales.

Y lo mismo es para programar. Como estudiantes de programación, aprendemos la sintaxis de algunos lenguajes, resolvemos varios problemas y aprobamos el curso. Luego, vamos a la galería y vemos las aplicaciones que allí se ofrecen. Es relativamente fácil suponer que se hacen con código similar al que aprendimos. Entonces, vamos a la tienda, nos conseguimos unos libros sobre el tema e intentamos hacerlo. Trabajando en ello, nos damos cuenta de que no es tan fácil como parece.

También aquí, lo que vemos es la obra. Lo que no vemos es la técnica para producir esa aplicación.

Hay muchos lugares donde enseñan programación pero, por alguna razón, pocos donde aprender técnicas para construir programas. Es en el trabajo donde solemos aprender esas cosas. Por prueba y error. O conectándonos a una comunidad con quien compartir experiencias.

Me parece que las analogías de la programación con el mundo de la pintura, la literatura o la construcción, suelen dar una perspectiva interesante sobre las cosas que hacemos.

Por ejemplo, hay gente que intenta programar de modo que a cada instante el código que produce sea el más óptimo posible. Es como alguien que intenta hacer un retrato directamente en limpio. Ojos perfectos. Nariz perfecta. Barbilla. Cara. Cabellos. Entonces, da un paso atrás y se da cuenta de que el conjunto está descuadrado. Que cada una de esas cosas perfectas no está en el lugar ni en la proporción que debería. Es mejor hacer bosquejos primero, maquetas que determinen la estructura general, asegurar primero la base y luego recién ir a los detalles.

Hay gente que programa muy bien, pero no sabe construir programas. Así, se frustra produciendo cosas que no están a la altura de sus habilidades. A veces creyendo que es por culpa del lenguaje que usa, o el framework, o el IDE. Es como alguien que sabe cómo mezclar pintura y obtener cualquier tono. Puede que hasta sepa composición. Pero eso no es suficiente para lograr que la escena se vuelva realidad. Para hacer un programa se necesita más que saber programar. Se necesita conocer técnicas para construir programas.

En el mundo, un porcentaje significativo de los proyectos de software fracasa, incluso los que no tienen retos tecnológicos. Mucho tiene que ver la manera como se organiza la gente. Pero yo creo que también tiene que ver con lo que la gente imagina que hay que hacer. Hay mucha gente por ahí, tratando de construir edificios de software, esmerándose en encontrar la perfección en lenguajes y herramientas. Pero, en realidad, son las técnicas las que determinan lo que son capaces de hacer.

Ojalá podamos compartir aquí las técnicas que vamos aprendiendo. Gracias.