Tres trucos para no ser un developer atormentado

¿Cuándo estás atormentado?

¿En qué momento quieres tirar la toalla?

¿Cuándo te sientes frustrado?

• Cuando pierde tu equipo deportivo favorito.
• Cuando tu comida preferida está más salada de la cuenta.
• Cuando tienes una gotera en el techo que no para de crecer.
• Cuando llevas horas con un problema técnico y no eres capaz de resolverlo.

La sal, el equipo de tus amores y los arreglos domésticos son tres temas tan importantes que no me atrevo a entrar en ellos.

Pero al último si que le voy a hincar el diente, porque lo sufro.

Esta misma semana una capa no quería colocarse en su sitio por más que tiraba líneas de CSS. Era por no colocar el “width” apropiado.

La semana anterior se escapaba a mi razón porque no llegaba un correo tras un registro de usuario. Era por utilizar un nombre de método inapropiado.

Los síntomas habituales del tormento pueden ser:

• Pulsado enfermizo de la tecla “Enter”.
• Despliegue de bufidos en varias escalas musicales.
• Insultar con brutalidad a la pantalla (que tendrá su chip interno con sentimientos)

¿A ti también te pasa?

Una solución inmediata es conocer las buenas prácticas y herramientas que me han hecho un developer mucho más optimista.

Apúntate ya a este Curso Gratis en 10 mails y 12 audios.

Saca la cabeza de la pantalla ¶

Un clásico que funciona en un 95% de los casos (porcentaje totalmente subjetivo, no conozco si la Universidad de Wichita tiene algún estudio al caso).

Si te dedicas un buen rato a resolver un problema y no avanzas.

Tu mente se quema.

Forzar esa situación hará que te debilites, gastes más energía y llegues a bloquear completamente la situación.

Ocurría igual cuando en la escuela te enfrentabas a un problema de matemáticas, física o química. Vueltas y más vueltas. Y la solución no llega y las horas pasan.

Levántate, tómate un café, saca al perro, baila, date una vuelta…

Cambia el ritmo de tu pensamiento.

Esto hará que otras partes de tu cerebro se pongan en marcha y se rompa ese bloqueo.

¿Por qué es tan difícil hacer algo tan sencillo? Precisamente porque has obstaculizado cualquier otro pensamiento al tratar de resolver cueste lo que cueste lo que tienes delante.

Todo este punto es un disfraz de la paciencia, tan escasa cuando estamos picando código…

Lee la documentación (otra vez) ¶

Sí, ya sé que sabes lo que estás manejando. Que probablemente tengas años de experiencia con ese lenguaje de programación o ese framework que adoras.

Pero, ¿seguro que estás haciendo lo correcto?

No estarás justo en ese límite del conocimiento adquirido, dónde hay una niebla densa en la que no hay tantas certezas: este método sólo lo he usado una vez, aquella librería la hizo “fulanito”…

Un repaso a la documentación tiene tres grandes ventajas en este punto:

1- Sacas la cabeza de la tarea (excusa perfecta, como la del punto anterior).
2- Vuelves a repasar la documentación de tu lenguaje o framework. Recuerda que es siempre la única fuente de verdad.
3- Aprendes algo nuevo sobre eso que pensabas que tenías dominado (aunque sea un detalle).

A veces confiamos demasiado en nosotros mismos. Y, aunque somos buenos en lo nuestro, la infalibilidad no está a nuestro alcance.

Aísla el problema en otra parte ¶

Este es un método que me parece genial. En este momento se me viene a la cabeza que sólo es aplicable a problemas de programación.

Copiar y pegar para llevarse el problema a otra parte.

Sin que haya librerías que cargan dependencias, entornos locales donde si funcionaba, carga de bases de datos, rutas de controladores, módulos instalados…

Algunos ejemplos prácticos:

• Si el asunto que te atormenta está en la maquetación, abre rápido un codepen.io y replica allí eso que no sale.
• En programación pura y dura vuelve al REPL, al intérprete en línea de comandos, y ejecuta allí lo que no te sale. O crea un proyecto mínimo para estudiar tus casos.
• En sistemas de alto nivel como CMS o CRM una nueva instalación limpia puede desvelar que el fallo está en la configuración del servidor y no en tu código.
• Si estás utilizando TDD o cualquier otro tipo de testing, añade este problema como un caso más a comprobar.

Extra: Comparte tu problema con personas ¶

Este es un recurso mágico. Es como tener una “musa” inspiradora. Contarle a tus compañeros o a colegas el problema que tienes y que, ¡tachán!, se te encienda la bombilla.

No hay conejo en la chistera.

Lo que ocurre es que al verbalizar o escribir lo que pasa se activan recursos diferentes a los que estabas machacando un minuto antes cuando no podías resolverlo.

Te dejo el enlace a otro artículo similar: Dealing with programming frustration: The right way

Disfruta de más contenidos como este en el newsletter dominical #laSelecta.

Apúntate, es gratis.