Los errores del ayer
Ya lo decía, Georges Clemenceau, «La vida de un hombre es interesante cuando ha cometido errores; es una muestra de que intentó superarse», uno de los caminos más fructíferos para aprender a programar consiste en tener una relación cordial con los errores.
Si usted ya lleva varios años trabajando como programador o al menos ya tiene un tiempo viendo a otros programar, verá, en determinado momento, que algunos tienen una relación tóxica con los errores, los odian, los detestan, no los quieren ver, y cuando ocurren, se estresan y salen a dar vueltas y vueltas mientras la máquina de café funciona más de la cuenta y sus puños se estrenan contra los muros.
Y es que más de una vez he visto a un pobre individuo con su teclado maltrecho como si lo hubiera estrellado contra una pared, aunque, por lo general es contra alguna cabeza de un jefe o compañero (acaecida en su imaginación, lamentablemente). Ya que por lo general las manos se vuelven los principales proyectiles contra los teclados, el ratón e incluso el monitor, o cualquier cosa que se le cruce en un instante de locura. La programación suele atraer en parte la locura —según me han contado—.
Una locura que viene de que algo no funciona. No hay caso. Luego de varios intentos de arreglarlo, sigue sin funcionar. Cuando algo no compila o no hace lo que requerimos pueden ser por dos motivos: no entendemos lo que nos piden entonces cualquier cosa que hagamos no funciona o no somos capaces de encontrar el error. Para el primer caso es importante tener habilidades comunicativas (con humanos), conversar, saber hacer preguntas y perder la timidez, esto se logra con práctica y con deseo de superación. Por tanto, prefiero escribir sobre el segundo caso.
Es sorprendente la cantidad de personas que programan y no prestan atención a los errores que da el compilador (o cualquier sistema informático). Aprender a leer los errores es una de las principales habilidades que debería procurar saber un programador. Y es que es así como se aprende, y es, en este sentido, la actividad de programar similar a la artesanía. Un constante pulir y sacar brillo. Mientras más errores vemos en nuestra vida más patrones vamos detectando. Ocurren similitudes, algo nos parece familiar, y es que, muchos de los errores que vamos generando —por diversos motivos— se van acumulando en nuestra experiencia, o sea, en nuestra memoria.
Consideré un ejemplo muy simple escrito en C.
#include <stdio.h>
int main()
{
if(1 == 1){
printf("Por supuesto: 1 es igual a 1.")
return 0;
}
El error que devuelve el compilador es el siguiente:
main.c: In function ‘main’:
main.c:6:48: error: expected ‘;’ before ‘return’
6 | printf("Por supuesto: 1 es igual a 1.")
| ^
| ;
......
9 | return 0;
| ~~~~~~
main.c:10:1: error: expected declaration or statement at end of input
10 | }
| ^
El main.c:6:48
significa que falta algo en la línea 6 y en el carácter n.º 48 (de izquierda a derecha). Más tarde aparece un símbolo ^
que nos indica el lugar específico, y entendemos que falta el ;
. Además, este mensaje de error nos menciona algo más: en la línea 9 del return 0;
necesitamos algo más (por lo general, antes de llegar a la línea 9), y es que, si vemos con atención, debemos cerrar el if
con el símbolo }
.
El código correcto sería:
#include <stdio.h>
int main()
{
if(1 == 1){
printf("Por supuesto: 1 es igual a 1.");
}
return 0;
}
Los errores dependen del compilador que, a su vez, depende del lenguaje. Algunos son más inteligentes que otros, o más tontos que otros. Por lo general un lenguaje estrictamente tipado como C te puede ayudar más con los errores. En otros casos, con lenguajes dinámicos, muchos errores de inconsistencia de tipos pueden pasar desapercibidos por un tiempo. Hasta que ocurra algún desastre. Acaso por eso los lenguajes tipados son útiles cuando el código fuente de una aplicación se presume que va a crecer considerablemente.
Debe tomarse su tiempo en entender los errores. Un consejo: genere —de manera deliberada— sus propios errores para comprender mejor la herramienta que usa. Provoque errores de sintaxis, errores de semántica, busque responder a ¿qué pasa si muevo esto, si cambio esto? Aunque tenga presente una cuestión importante: no lo haga con código en producción (de otra forma, LinkedIn es una buena plataforma para buscar trabajo).
Tener una buena relación con los errores es importante para ser mejor programador. Tome la actitud del investigador que busca descubrir la solución a un problema, no la del que se enoja con la máquina por no hacer lo que desea. Mantener una actitud curiosa, como quien busca resolver un acertijo, es la mejor. Y eso se puede cultivar con desconectarse del ordenador por un tiempo; dicen que, por ejemplo, dar un paseo, salir a tomar un café, contarle su problema a un amigo, o dejar dormir el problema por un tiempo, siempre es útil.
A más errores más aprendizaje, siempre y cuando, se tenga una afable actitud.