La vida es la suma de todo lo que sucede y de lo que nosotros y el colectivo, tenemos conocimiento. Parte de la vida, consiste en problemas; son parte de ella y son inevitables; esto no es una opinión ni una cuestión democrática... los problemas existen y ya. Así como en la vida, en el campo de la tecnología también tenemos problemas. Y respecto a ellos, podemos:
• no hacer nada.
• dejar al problema ser, si es leve.
• pedir ayuda.
• esperar que alguien más lo resuelva.
• reiniciar la aplicación o la PC - a veces esto funciona.
• formatear la PC para ahorrarnos la frustración y evitar buscar la solución.
• comprar otra PC -como algunos de mis amigos hacen.
• hacer distro hopping.
• pagar por soporte.
• hacer muchos clicks cuando la PC se traba y pretender que estamos resolviendo el problema mientras la PC toma su tiempo para resolver el problema por su cuenta (es un equivalente a orar en el mundo real).
• DIY: do it yourself.
Yo opto por el DIY; se requiere un poco de pelotas extra, el hacer las cosas por cuenta propia. Esto no te hace "más especial" o "úniko", pero te aporta cosas buenas como ser humano. Te da paciencia, ejercita tu mente, te vuelve más resiliente a las frustraciones, te hace pensar de forma no-convencional, simplificar las cosas, descomponer los problemas, pensar en distintas maneras de resolver un mismo problema, te vuelve recursivo, creativo, pragmático, organizado, etc. Te vuelve un poco menos lento y dependiente de otros.
Ahora, tener la buena voluntad no basta. Estoy seguro que más de alguna vez, muchos de nosotros tuvimos las intenciones de resolver un problema con nuestras distros alguna vez y luchamos hasta que nos venció. Esto pasa, no porque el problema sea imposible de resolver (sí existen problemas imposibles, pero son muy inusuales), sino porque nos hace falta método, experiencia y conocimiento necesarios para resolverlo.
Para todo qué, hay un cómo. Esta entrada no es un manual técnico como tal, sino que constituye un resumen de lo que he aprendido en mi vida laboral como técnico en hardware.
Para resolver un problema, primero tenés que entender el problema.
Una de las cosas que quiene trabajamos en esta industria aprendemos con el tiempo, la práctica, los clientes y la experiencia es eso: identificar el problema es lo primero. Esencialmente se trata de procurar un diagnóstico correcto del problema, para proveer la solución efectiva. No se puede poner la cola al burro si no se sabe dónde está el jodido burro.
Sólo este primer paso involucra un montón de cosas de qué hablar. Tal vez luego ampliemos la explicación.
Una vez hemos identificado el problema, tomamos acciones correctivas.
Una vez sabemos cuál es el pedo, sus causas e implicaciones, buscamos las soluciones; puede que ya existan soluciones a él; puede que haya una sola o varias. Lo importante es, tomar acción e implementar las soluciones que tenemos disponibles. Este paso no es realizable, o si lo es, no es eficiente ni efectivo si no hemos cumplido con el anterior. Ojo.
Una vez resuelto el problema, implementamos acciones preventivas.
Curarse en salud. Esto varía según la causa del problema y el control que tenemos de las variables del entorno: si tuvimos un un problema causado por un controlador de video y resolvimos usando otro controlador, pues será inevitable que surja el mismo problema si nos vemos forzados a reinstalar el mismo sistema operativo (aunque aquí ya no sería tan problema, porque tenemos conocimiento previo, y resolverlo debería entonces, implicar menos tiempo y esfuerzos).
Las acciones preventivas pueden ser tan simples como anotar las cosas que hicimos para resolver el problema y guardarlas en un lugar seguro (el artículo anterior es una forma de acción preventiva que tomé respecto a un reto/problema que resolví), hasta reportar un bug, educar a un usuario, crear documentación que antes no existía al respecto, cambiar código fuente, implementar un proceso nuevo, replantear un algoritmo, etc. Cualquier cosa que te ayude a evitar en el mejor de los casos o mitigarlo en caso de reincidencia a futuro.
Cierre.
El closure es algo necesario; los cierres implican el fin de un ciclo y el inicio de otro. Hacen bien tanto mental como emocionalmente. En todas las culturas, sucesos importantes, celebraciones y demás eventos, y cada uno tiene un cierre. Ayuda al individuo para recuperar el sentido de perspectiva respecto al tiempo y el espacio. Personalmente, una vez haya resuelto un problema o no haya podido resolverle (de nuevo, no todo puede resolverse), hago una evaluación personal: ¿qué aprendí de esto? ¿cómo me beneficio de ello? Al final, ganar o perder no importa tanto como sacar lo mejor de ambas circunstancias para uno y los demás. Perder es ganar si uno es capaz de pensar en términos de funcionalidad; ganar es perder si fuera del sentimiento de logro uno no aprende nada de la circunstancia. Una vez has reconocido las lecciones aprendidas, es hora de cerrar capítulo y moverse.
Por ahora eso es todo. Como dije antes, esta no es un manual detallado como una descripción a grandes rasgos de un proceso que nos puede ayudar a todos a mejorar nuestras habilidades de resolución en GNU/Linux y por qué no, la vida en general :)
*Salvadoreñismo: achicopalarse.
