“It’s great to be back!”

Michael Abrash es uno de mis héroes de programación. Es el gurú indiscutible de la programación a bajo nivel, de la más original y extraordinaria optimización, el descubridor del Modo X, autor de excelentes artículos para la Dr. Dobbs Journal (de él aprendí a escribir, expresarme y predicar usando analogías), autor del Graphics Programming Black Book (Disponible gratis en la web) y programador junto con John Carmack de Quake.
Siempre he querido saber qué es de su vida actualmente, pero no hay información actualizada de su persona en la web.

“It’s great to be back” es un artículo que me gusta leer de cuando en cuando y siempre lo encuentro refrescante y energizante. De allí viene mi mantra “No asumas,” que es crítico para todo programador.

No importa si no programas; mi hermano, que es Ingeniero Civil, me comentó una vez que le gusta bastante ese artículo. Les recomiendo altamente una leída.

Y todavía sigue funcionando!

Hay una historia interesante en la web, en algún foro, de una laptop que se cayó en una autopista y un motociclista la encontró y funcionaba igual de bien. La historia más se centraba en el motociclista descubriendo la vida de la otra persona a través de la laptop y buscarla para devolvérsela (a pesar que anhelaba quedarse con la máquina).
Como esa, hay otras historias de computadoras y aparatos que han sufrido caídas o golpes espectaculares y, contrariamente a lo que uno piensa, siguen funcionando.

Cuando todavía estaba en primaria de colegio dí una caída a gran velocidad en el recreo, lo cual hizo volar mi reloj Casio y repartirse en partes. Yo tenía la manía de desarmarlo, por eso se abrió fácilmente. Recogí las piezas y volví a armarlo y, efectivamente, seguía funcionando y debería seguir haciéndolo de no ser porque ya no tiene pila y no marca el año 2000.

Tenía un celular Nokia, ya no recuerdo el modelo exacto, era de esos que parecen un jabón. El hecho es que esa cosa era durísima. Había sufrido un par de caídas y no le pasó nada. Era tal la confianza que tenía a ese celular que, mientras le contaba a una amiga lo duro que era, lo dejé caer desde la altura de mi codo. El celular rebotó y la tapa de la batería se salió, pero el celular siguió funcionando feliz.

En 1998, Ica sufrió una inundación. Varias personas me comentaban de sus computadoras, que después de haber flotado en el agua y el lodo trataban de recuperarlas. Algunas personas decían con orgullo, “Y todavía sigue funcionando!”

Lo que notamos en estos objetos, sea del tipo que sean, es la calidad de la construcción. Sea un vehículo, un celular o hasta una persona misma, la calidad o fuerza del diseño se hace claramente visible cuando lo sometes a una prueba no concebida para su uso.
Una vez por tantear a ciegas poner el conector de mi disco duro, con la computadora encendida, hice un mal contacto dándole corriente a un pin que no se supone debía recibir corriente. Hubo un sonoro “poc!” y toda la computadora se apagó. Ya se imaginan mi rostro de pánico, oraciones mil, volver a encender la computadora y probar el disco duro mientras me maldecía a mí mismo por semejante brutalidad.
El disco duro funcionó sin problemas, no pasó absolutamente nada.

Uno no puede evitar una sorpresa en ese instante, ¿verdad?

Ok, ok, ¿Qué quiero decir con esto? Cuando desarrollemos un programa, sea una aplicación web o un script para un firewall (¡Habla chochera!), la calidad de ese desarrollo se hace ver cuando lo sometemos a algo inesperado. Me gusta probar desarrollos webs en PHP de otros moviendo las variables en la URL.
Pongamos de ejemplo un catálogo en línea que reciba el ID del producto de esta forma:

catalogo.php?id=0001826

Entonces lo que hago es quitarle el ID y dejarlo así:

catalogo.php?id=

Refresco la página y miro qué pasa. La reacción de la aplicación en ese instante demuestra el cuidado y diseño del programador o equipo de programadores. El caso más común es que el sistema muestra el supuesto detalle pero con todos los campos vacíos. Es decir, siguió buscando un registro en la base de datos a pesar que no había ningún ID.
En otros casos, sale un error de SQL o PHP. Otras veces, se queda en blanco — al menos tuvieron el cuidado de desactivar el reporte de errores.

La primera ley de Lambeck (sobre diseño de maquinarias) afirma que debemos construir cierto margen en nuestro diseño por posibles desviaciones de manufactura o de uso del cliente. Esta ley puede ser aplicada también en nuestro desarrollo en PHP, sobre todo porque la web es muy vulnerable.

La segunda ley de Lambeck dice que cuando hay un problema, cualquier acción es mejor que ninguna (esto es, ¡No te quedes parado, haz algo!). Lo que yo frecuento hacer cuando no hay un ID, o el ID no es un número o el ID no existe en la base de datos es saltar a otra página. Lo ideal sería mostrar un mensaje de error “No existe ese registro” o “Oops! Hubo un problema” — mas cualquier acción es mejor que ninguna.

Esta segunda ley persigue el mismo fin que la frase dicha por Bobby Knight, un entrenador de basketball, que todos juntos deberíamos aplicar en todo aspecto de nuestras vidas: “Sé un buen líder o un buen seguidor, y, si no puedes ser ninguno, por todos los cielos, quítate del camino.”

Las leyes de Lambeck están reproducidas en su totalidad en esta dirección.

Cómo aprender PHP

Como saben, me gano el pan haciendo aplicaciones web en PHP. Frecuentemente recibo preguntas de muchos tipos, así que intentaré contestar algunas.

Empezaremos con ésta: ¿Cómo puedo aprender PHP?

La respuesta más precisa es a la vez la más genérica: Tal como aprenderías cualquier otra nueva habilidad. Leyendo, investigando y practicando, practicando, practicando. Como en toda cosa valiosa, esto toma trabajo y esfuerzo duro. Como podrás leer a continuación, no todo es tan fácil como parece.

En primer lugar, hay una distinción importante que hacer: aprender PHP no es lo mismo que aprender a programar, así como aprender a escribir el abecedario no es lo mismo que aprender a escribir poesía.

– “Aprender PHP” es aprender la sintaxis del lenguaje, cómo se escribe un programa, cuáles son las funciones, sus estructuras de control, bucles, etc.
– “Aprender a programar” es aprender a resolver problemas usando un lenguaje de programación.

Muchas personas confunden ambas cosas, y cuando piensan en “aprender PHP” están metiendo ambos conceptos en la misma bolsa, y no es así. Tu primer paso es diferenciar ambas cosas.

Probablemente habrás sentido curiosidad por PHP al ver lo fácil que es, y es muy cierto. PHP es un lenguaje muy fácil de aprender. Pero ojo, eso no significa que aprender a programar sea igual de fácil.
Es por este motivo que muchos diseñadores web intentan hacer programas con PHP y el resultado no es una aplicación robusta, ni segura, ni escalable. [1] Es por ello que vemos muchos websites hackeados porque sus autores no saben programar. Saben PHP y no es lo mismo.

Entonces vamos a reformular nuestra pregunta: “¿Cómo puedo aprender a programar y aprender PHP?”

Eso está mejor, pero todavía está incompleto.

Verás, PHP es un lenguaje para programar aplicaciones web. Es cierto, se puede usar fuera del contexto de la web (cosa que personalmente hago a menudo), pero cuando nos referimos a “programar en PHP” estamos hablando de “programar una aplicación web.”

Entonces lo segundo que tenemos que aprender es cómo funciona la web. Debes ser capaz de entender los siguientes conceptos:

1) El concepto de cliente/servidor.
2) El protocolo “http”.
3) Métodos GET y POST — cómo funcionan y cómo se diferencian.
4) El lenguaje HTML.
5) Cómo funciona a grandes rasgos un navegador web.
6) Cómo funciona a grandes rasgos un servidor web.

Ya puedo ver sus caras de “TODO ESO TENGO QUE APRENDER!?” Como les dije en un principio, aprender PHP requiere trabajo y esfuerzo duro. Ok, pasemos a una pregunta más sensible: “¿Pero Jaime, es realmente necesario que conozca todo esto?” La respuesta es “No.”
Entonces, ¿por qué razón hago esta lista? Porque tarde o temprano la falta de estos conceptos te va a traer problemas. [2]

Depende mucho de hasta dónde quieres llegar. ¿Quieres hacer un par de cosillas con PHP, un contador por aquí, un gráfico al azar en la portada y nada más? Perfecto, no es necesario que te tragues esa lista.
¿O quieres ser un buen programador? ¿De aquellos que buscan la excelencia y definen el futuro? Oh, entonces coge tu taza de café y vamos a aprender lo que es necesario aprender. De tí depende.

Una vez que tengas los conceptos de la web bien aprendidos, el siguiente paso es aprender poco a poco PHP y poco a poco programar. Hay tutoriales regados por la web, varios en español inclusive. Te recomiendo que busques un tutorial que te enseñe primero lo básico del lenguaje. Aquí unos tips en tu aprendizaje:

1) No copies y pegues. Escribe cada uno de los ejemplos a mano. Debes ser capaz de poder escribir cientos de líneas de código a mano. Debes ser capaz de recordar la sintaxis de PHP. No quiero decir que debas saberte de memoria cada una de las funciones de PHP, llevo cerca de cinco años en esto y todavía tengo que consultar la sintaxis de str_replace. Lo que quiero es que te familiarices con la forma del lenguaje, de cada comando.

2) Lee todo el manual. Si, todo. O para ser más literales, échale un vistazo a todo el manual. Un desliz frecuente es implementar todo un programa y luego descubrir que había una función en PHP que hacía eso. La idea de echarle un vistazo a toda la librería de funciones es que sepas qué cosas hay disponibles, de modo que más adelante al menos puedas pensar: “Hmmm… me parece haber visto una función que hacía eso.”

3) Elige un pequeño proyecto. Piensa en algo que te sea útil y te gustaría tener, que sea sencillo y simple. Por ejemplo: una lista de direcciones web, una tabla de colores HTML, una lista de tus gastos, etc. Luego mira qué es lo que te falta saber para poder implementarlo y averigua cada cosa, un paso a la vez. “Ah, necesito saber cómo guardar cosas en un fichero,” entonces lee el manual de PHP sobre ello o busca en Google tutoriales. “Ok, necesito saber cómo guardar lo que escribí en esta caja de texto,” entonces mira el manual de PHP o busca en Google por algún tutorial.

Se me acabó el tiempo. Este post no pretende ser ninguna guía exhaustiva, a este paso creo que voy a terminar escribiendo un libro. Si tienen alguna pregunta o duda, escriban un comentario o un mail a j@jgwong.org. Les aviso que soy tardo para contestar, así que no desesperen.

Espero que esto les sea útil. La programación es fascinante.

Notas
[1] Debo aclarar que no tengo nada en contra de los diseñadores que deciden aprender PHP; todo lo contrario, les animo a que aprendan a programar lo cual les puede abrir innumerables puertas para competir con la mejor de las ventajas: la diferenciación.

[2] Las personas que carecen de estos conceptos fundamentales son los que más tarde tienen confusión entre el cliente y el servidor. Muchos se confunden pensando que PHP puede hacer lo mismo que Javascript, que PHP puede imprimir, etcétera. Esta es la sencilla razón.

Fuera de Contexto

Ultimamente estoy escuchando mi colección de música con el modo “al azar.” Antes elegía a mano las canciones, muchas veces todas las de un solo álbum o artista juntas. Ya me había aburrido de mi colección y ya no sabía ni qué canción poner, así que me puse a probar dejarlas al azar.
Al principio escuchaba un pedacito de canción y pasaba a la siguiente. “Esta no, esta tampoco,” etc. Por ahí aparecía una favorita y la dejaba sonar.

El efecto interesante de poner música al azar es que algunas canciones que no eran tan preferidas sonaban bien fuera de su contexto, es decir, después de otra canción que no era del mismo grupo de canciones con quien siempre lo escuchaba. Estaba marcando el ritmo de cierta canción pop cuando de repente le sigue una balada de los Blue Nile que cae perfectamente como continuación.
O a veces es lo contrario, tienes una de esas canciones tristes y preciosas (Adagio de Secret Garden!) y le seguía una que te volvía a alzar los ánimos, o que contrastaba de manera apropiada el flujo musical.

A veces escuchar las cosas fuera de contexto puede resultar en sorpresas. Si tomamos esta premisa, podemos aplicar esta idea fuera de contexto. Qué pasa si cogemos un método A y lo aplicamos con el problema B, donde A está fuera de contexto? Podría resultar en sorpresas.

Por ejemplo, el libro The Hacker’s Diet. Su autor es John Walker, presidente de Autodesk, autor de las primeras versiones de AutoCAD. Como Walker mismo nos cuenta en su libro (que de paso, se los recomiendo bastante), tenía este problema de sobrepeso, así que un día se le ocurrió aplicar su misma metodología hacker de resolver problemas para resolver el problema de sobrepeso.
Tienes un método A (“ingeniería”) y un problema B (“sobrepeso”) y lo aplicas.

Otro ejemplo, el afamado físico Richard Feynman. Feynman aplicaba la física a todo cuanto ganaba su curiosidad (como la caída de una gota de agua). En una temporada en la que estaba desganado, sin motivación y sin rumbo, se percató del movimiento curioso que hizo un disco cuando uno de los muchachos de la universidad lo lanzó en la cafetería. Así que se puso a investigar ese movimiento.
Tienes un método A (“física”) y un problema B (“por qué gira así el disco?”) y lo aplicas.

A veces el resultado te da sorpresas: esa curiosidad inicial llevó a Feynman por un camino nuevo que resultó en un premio Nobel.

No todo es aplicable con todo, pero a menudo sacar algo de su contexto puede abrirte la mente a ideas que de otro modo no habrías considerado. Aquí unas ideas que se me ocurren:

– Administración de empresas y el levantarse tarde.
– Construcción de un puente y notas bajas.
– Teoría musical y la disciplina de los hijos.
– Fotografía y ordenar mi cuarto.
– Coser y pedir un aumento de sueldo.
– Cocinar e impuntualidad.
– Electrónica y obtener un empleo.
– Radiografía y comprar una casa.

Cómo ser un buen profesor

Traducido de una página de Paul Graham:

Voy a ser un profesor. Cómo puedo ser uno bueno?
Los mejores profesores que recuerdo del colegio tenían tres cosas en común:

(1) Tenían standards altos. Como niños de tres años probando a sus padres, los estudiantes probarán a los profesores para ver si pueden seguir de largo con trabajo de baja calidad o mal comportamiento. Ellos no respetarán a profesores que no les llamen la atención.

(2) Nos querían. Como los perros, los chicos pueden decir con precisión si es que alguien les desea bien o no. Creo que muchos de nuestros profesores nunca les gustó mucho los chicos, o se cansaron y dejaron de gustarles. Es difícil ser un buen profesor una vez que eso sucede. No puedo pensar en un solo profesor en todos los colegios a los que asistí que sea bueno a pesar que le disguste sus alumnos.

(3) Estaban interesados en el tema. La mayoría de los profesores de colegio público que tuve no estaban realmente interesados en lo que enseñaban. El entusiasmo es contagioso, así como el aburrimiento.

Redefiniendo y reentrevistando el Miedo

Esta es la tercera y última parte de una serie de posts:
Redefiniendo y redibujando el Miedo
Redefiniendo y reprogramando el Miedo

Mi hermano es Ingenierio Civil. El año pasado sacó su título y es, oficialmente, “Ingeniero Wong.” El siguiente proyecto en su vida era encontrar un trabajo decente, así que pasó a las filas de los que devoran los avisos clasificados e imprimen currículums con la esperanza de encontrar un puesto de trabajo ideal.
Como creyente, y al igual que yo, mi hermano tiene criterios inamovibles para elegir un trabajo, pero eso es tema de otro día. Lo que quiero contarles hoy es esa experiencia que repetidas veces tuvo que pasar y que a muchos nos llena de miedo.

Sí, las entrevistas. Horror de horrores!

A todos nos da miedo, pues necesitamos el trabajo y queremos causar una buena impresión y queremos hacer todo lo posible para que todo salga Perfecto. El problema son los nervios que lo descontrolan a uno y la horrible posibilidad que te hagan una pregunta que no sepas.
Mi hermano fue de entrevista a entrevista con la respuesta clásica: “Nosotros te llamamos.” Ya se imaginan, no lo llamaron y mi hermano tuvo que seguir buscando y seguir buscando.

Mi hermano me contó de algo que le iluminó el panorama. No recuerdo bien los detalles, el quid del asunto fue que estuvo presente durante la entrevista de otras personas. Estaban entrevistando señoritas para secretarias y allí notó un contraste importante.

Una señorita que fue entrevistada estaba a todas luces nerviosa. Movía inquietamente las manos, voz temblorosa, etcétera. Le preguntaron: “Y usted sabe computación?”
“Sí, sí, llevé un curso de informática y computación para secretariad–”
“Sabes Excel?”
“Mmmm, sí.” Pausa incómoda. “Más o menos.”
Pasaron a otro grupo de preguntas más y la entrevista con esta muchacha terminó.

Entre las siguientes entrevistadas resaltó esta muchacha que carecía completamente de nervios. Fue un contraste amplio después de ver bastantes caras de nervios e inseguridad (que son comprensibles). Su forma de contestar era serena y directa. Nada de rellenos.
“Y sabe computación?”
“Sí, tengo computadora en mi casa.”
(Una pausa, esta vez del entrevistador)
“Sabe usted Excel?”
“Sí.”
(El entrevistador asintiendo con la cabeza)
“Sabe cómo hacer [COSA AVANZADA EN EXCEL]?”
“No, pero sé [OTRA COSA AVANZADA SIMILAR]. En todo caso, aprendo rápido.”

Tras esta educativa experiencia, mi hermano hizo un cambio en sus planes. Empezó a presentar currículums a lugares donde no cumplía los requisitos o donde no le interesaba trabajar, con una finalidad específica: fallar a propósito.
Empezó a entrevistarse sabiendo que no era la persona que buscaban, que no lo tomarían en cuenta, etc. Su meta era perder el miedo, ganar experiencia. No tenía que impresionar a nadie, no tenía que dar la Respuesta Correcta, no tenía ningún requisito o carta a su favor.

La parte graciosa de la anécdota fue la entrevista donde contestó todo completamente tranquilo, y al final ya estaban considerando contratarlo al instante. El horario era inadecuado, así que igual no se pudo.

Al punto que quiero llegar es que la única forma de perderle el miedo al miedo es enfrentándolo. Leí una vez frases acerca del coraje, y lo que más me llamó la atención es que coraje no significa ausencia de miedo. Coraje es hacer lo que se tiene que hacer a pesar del miedo. Coraje es sentir miedo y aún así seguir marchando hacia el campo de batalla.
Si quieres librarte el miedo, tienes que darle la cara. No hay atajos, no hay caminos fáciles, no hay escapatoria mas que ir y pegarle, enfrentarle, confesarte, exigir, declararte… una y otra vez, una y otra vez, hasta que le pierdas el miedo. Hasta que llegues con la completa confidencia y soltura del mundo y respondas todas las respuestas correctas, pidas el aumento de sueldo, reclames lo que es tu derecho exigir.

A las personas les impresiona mucho una persona con confidencia. Puedan no estar de acuerdo contigo, o negarte lo que dices, pero guardan esa impresión de tí con una nota mental en sus cabezas: “Esta persona no tiene medio de decir lo que quiere.” Si hay algo que las mujeres encuentran irresistiblemente atractivo es alguien seguro de sí mismo; y a quién no?

Como dice la canción de Coldplay, “nadie dijo que era fácil / nadie dijo que
sería así de duro.” Pero la actitud es de los héroes de las pelis de artes marciales, que cuando viene el gigantesco contrincante, dicen un gracioso “Oh no” y proceden a intentar atinarle un golpe. No los ves huir cobardemente.

Así que aquí vamos.

(Oh no.)

Redefiniendo y reprogramando el Miedo

Este es el segundo de una serie de tres posts. Haz click aquí para leer el primero.

Me es frecuente ver en las listas de correo del PLUG (el Grupo de Usuarios de Linux de Perú) personas que hacen preguntas que tendrían una respuesta inmediata si se atrevieran a probarlo.
Es entendible que la persona puede tener miedo a arruinar la configuración o malograr algo si intenta un comando o programa que le es desconocido. Es perfectamente razonable, sobre todo si la computadora o servidor es crítico o pertenece a un cliente.

Pero esto entra en contraste con la actitud hacker. Qué quiero decir con la “actitud hacker”? A aquella que no tiene miedo de romper algo para entender cómo funciona.

Es importante detenerme un instante y aclarar el término “hacker.” NO me estoy refiriendo a aquellos vándalos que destruyen por diversión o por falta de autoestima. NO me estoy refiriendo a personas que hacen daño. Estoy hablando de hackers en su término original: desde los fans de modelos de locomotoras hasta Leonardo Da Vinci.

Has visto a esos niños que les regalas un auto de juguete y a las pocas horas ya lo rompieron o desarmaron? Sí? Hay de los dos tipos:

a) Aquellos que lo hacen por descuido, por placer o por un intento triste de llamar la atención de sus padres.
b) Aquellos que lo hacen por curiosidad.

Los futuros Hackers pertenecen al segundo grupo. Su curiosidad por saber cómo es que el auto se mueve por sí solo es más fuerte que su deseo de conservar el auto intacto. Intentarán armarlo nuevamente, pero eso es un plus, una parte del reto.
Dicho en otras palabras, disfrutan más satisfacer su curiosidad que jugar con el juguete en sí. No les importa romper el plástico o perder un tornillo por ahí.

Obviamente, a veces lamentas haberlo roto. Todo tiene un precio.

La curiosidad te lleva a hacerte preguntas y a cuestionar cosas que otros dan por sentado, cosas que otros no quieren ni pensar porque les incomoda la idea que algo podría estar mal. Esta misma curiosidad con frecuencia te mete en problemas (Galileo, alguien?); pero el hacker vive resolviendo problemas. Su mundo está lleno de acertijos por revelar, problemas por resolver, barreras por romper.
Tengo una amiga que cuando vio la chapa de la puerta de mi oficina dijo: “Esta es de las fáciles.” Es la misma que me pidió que desarme mi celular nada más verlo y la que le brillaron los ojos cuando abrí el interior de mi primera laptop — para luego decepcionarse cuando ya no quise desarmarla más.
Lo tiene escrito en la cara: HACKER. Me muero de ganas de enseñarle todo cuanto sé.

La persona que mencioné al principio, la que tiene miedo de echar a perder algo, puede ser un gran entusiasta de la computación, considerarse un gran experto, leerse todas las revistas de computación y un largo etcétera; pero nunca va a llegar lejos, porque carece lo esencial, la pasión que define y caracteriza a un verdadero hacker: la curiosidad que no tiene miedo de malograr.

Así es como muchos borramos todo nuestro disco duro por error. :) Por supuesto que no queremos volver a pasar por eso, pero eso no nos detiene a recompilar el kernel conociendo la posibilidad de que no vuelva a reiniciar. No nos detiene a desarmar inexpertamente la PC para instalar una Sound Blaster Pro conociendo la plausibilidad de que no vuelva a encender. No nos detiene de mandar un hombre a la Luna conociendo la desconcertante tragedia que no podamos traerlo de vuelta con su familia.

Tienes miedo de malograr? Malogra.

Es como esa obra de arte llamada “Buscando a Nemo,” donde el extremadamente desconfiado papá le dice a su acompañante sobre Nemo, su hijo perdido:

– “No quiero que le pase nada!”
Ella, pensativa – “Eso es extraño…”
– “Qué cosa?”
– “Pues si lo proteges para que no le pase nada… pues nada le va a pasar.

Es como participar en esos programas concurso donde puedes elegir el premio o perderlo todo con solamente elegir una puerta. La puerta ganadora? La puerta que te robe todo? Eliges abrir la puerta o quedarte con lo que has ganado hasta el momento?
Oh sí, puedes conformarte con lo que tienes hoy, con la seguridad del momento y no arriesgarte a ganar o perder.

No elijas esa opción. Elige abrir la maldita puerta. Sí, puedes perderlo todo, pero también puedes ganar. Y si no lo intentas, si no te arriesgas vas a vivir hasta el resto de tus días con la pregunta hiriente de siempre: “Y qué si hubiera ganado?”

“Y qué si me lo concedían?”

“Y qué si ingresaba?”

“Y qué si me daban el aumento?”

“Y qué si ella también me quería?”

Como dice mi amigo Oliver, “Sólo hay una forma de saberlo.”

No me importa que no tengas una computadora. Tú eres una máquina. Hackéate a tí mismo.

Sí, te puedes romper las rodillas en el intento. Sí, puedes perder tu trabajo, perder todo tu dinero, ir a la cárcel, ser objeto de burla, que te asalten, que hagan trizas tu corazón, que te mates saltando del avión a más de mil metros de altura.

“Qué rayos estás haciendo?” te van a decir. “Estás loco!”

Y qué vas a contestar?

“Sip. Se me perdió un tornillo por ahí.”

Redefiniendo y redibujando el Miedo

Este post es un extracto de una carta que le escribí a una amiga que no logró una meta importante. Menciono al artista argentino Juan Giménez, uno de mis héroes de juventud, a quien de chico intentaba copiar (con escaso éxito).

Solía dibujar todo a lapicero. No me gustaba el lápiz por dos motivos: había que sacarle punta y manchaba. Oh, por supuesto que el lapicero también manchaba, y manchaba peor! Pero allí estaba yo, dibujando con lapicero, donde cada error lo tienes que disfrazar con otro trazo o, peor aún, con una sombra, o la clásica del cabello negro.

Pasar del lapicero al portaminas fue un progreso. Cada vez que hacía una línea chueca, podía borrarla y dibujarla hasta que quedara bien o hasta romper el papel. Usualmente pasaba lo último.
Dibujar con lapicero es difícil, porque no te da lugar a errores. Y si los cometes, tienes las siguientes opciones:

a) Dejarlo allí.
b) Disfrazarlo (que implica frecuentemente cambiar la idea original).
c) Descartar todo el dibujo.

Con el portaminas y un borrador te das permiso para cometer errores. Lo que hacía era borrar y deshacer las líneas que me habían salido mal. U ojos o bocas que no me salían bien. Borrar está bien, pero había algo que todavía no había aprendido, que todavía no había hecho click! en mi cabeza.

Pasar del borrar un trazo a borrar todo un dibujo entero fue otro progreso, y uno muy grande. La lección es muy clara: “No tengas miedo de borrar,” pero eso tiene un significado enorme. Muchas veces me ha pasado esto: he dibujado un rostro y no he quedado del todo contento. Lo borro para volverlo a dibujar y me sale peor! Y luego lamento haber perdido el rostro original para siempre (nunca lo puedes volver a dibujar). Así que no quería borrar. Empezaba otro dibujo o hacía cambios mínimos.

Empecé a mejorar bastante cuando le perdí el miedo a borrar.

Cometer errores es parte de crecer. Borrar y deshacer cosas está bien. A veces borramos cosas y luego nos lamentamos, pero del mismo modo otras veces obtenemos algo mejor. A veces se gana, a veces se pierde. Lo importante es aprender de las pérdidas. Aprender de los errores. Rescatar la lección.
Tenemos que darnos permiso para borrar. A fallar. A ser humanos. A dejar el lapicero y aprender a:

a) No dejarlo allí, sino hacer algo con ello.
b) No disfrazarlo, sino corregirlo, y estar dispuesto a cambiar de planes.
c) Descartar todo el dibujo.

Aún hoy no dibujo como Juan Giménez, pero definitivamente dibujo mucho mejor que antes. Una razón es haber estado dispuesto a ver mis errores y corregirlos. La actitud y la perseverancia tienen mucho que ver aquí. No se trata de llorar o lamentarse por no ser tan bueno dibujando, sino de hacer algo por ello.

Ahora, una cosa es querer algo y otra cosa es estar dispuesto a pagar el precio por ello. Muchas personas quieren cosas pero no están dispuestas a sacrificar otras cosas con tal de obtenerlo. Es un querer que no llega más allá a un capricho, a un vano anhelo. No es un querer apasionado, del que rompe barreras, del que te amaneces, del que te aferras a ello a pesar de lo feas que se ponen las cosas alrededor tuyo.

Muchas personas sienten pasión y encuentran la cura para una enfermedad rara. Otras, lanzan un avión entero contra las Torres Gemelas. La diferencia entre unas y otras es lo que Dios opina de ambas motivaciones.
Si Dios me ha dado este talento para dibujar no es para que lo use para mi propio provecho, o para mi propia gloria, sino para Su gloria, y para Su uso. Porque así como El me dió estas manos, igual me las puede quitar.

Si prosperamos en algo, es porque Dios lo permite. Si anhelamos algo, como creyentes que somos debe ser siempre para gloria Suya, para uso Suyo. Dios no nos quiere dar algo sabiendo que lo utilizaremos para alejarnos de El. Nuestro Padre nos quiere cerca, lejos del peligro, lejos de Satanás. No quiere que nuestra pasión sea otra cosa que no sea El mismo.

El quiere darnos lo mejor.

Muchas veces “lo mejor” no significa salir siempre victoriosos. “Lo mejor” es a veces fallar, porque de ese modo aprendemos. Porque de ese modo entendemos que quien tiene el control es El, no nosotros. De ese modo aprendemos a depender de El. De ese modo conocemos que El tiene un propósito en nuestras vidas, y que en ese propósito somos completos y felices.

Cómo podemos saber qué es lo que El quiere? Cómo podemos saber cómo ser completos y felices? Esa es una respuesta muy larga que Dios hace tiempo quiere contestarte.