Es usual para un Desarrollador de Software ingresar a distintos foros en búsqueda de ayuda cuando se suscita un problema o cuando uno no sabe por donde iniciar, así que me puse a pensar cuantas veces lo hice a lo largo de los años, como podrán imaginar es una pregunta que carece de sentido, si bien no puedo contarlas me puse a tipificarlas y ponerles un nombre, es así que nacieron los siguientes arquetipos de Desarrolladores de Software a la hora de afrontar un problema, me puse un tanto estricto con su definición así que entenderán que esto es algo serio.
Comencemos por el más conocido, Copypaster ¿Cómo se que soy un copypaster?, este tipo de programador(a) navega en la web en búsqueda de funcionalidades a implementar, funcionalidades que son lo suficientemente genéricas como para encontrarlas y pegarlas en el código. Puedo asegurar con convicción que toda persona que aprendió a picar código paso buen tiempo con este arquetipo como si de un escudo y espada se tratasen.
¿Qué podemos aprender de este arquetipo? Si nos paramos a pensar un momento, podemos identificar que los apartados de Quickstarts y Examples en las documentaciones de las distintas libs, frameworks y otros te incitan a ser un copypaster, pero no lo malinterpretes, nunca mencioné que ser un copypaster sea malo, es un gran habilidad siempre y cuando entiendas lo que estas copiando o adaptando. ¿Eres un copypaster?.
Pasemos al siguiente arquetipo, Kernel Panic ¿Ya recordaste la referencia?, un kernel panic es un error del cual difícilmente se logra recuperar una distribución Linux, cuando esta ocurre y tienes un montón de configuraciones y archivos importantes en tu computadora que no te gustaría perder, comienzas a buscar una solución como si no hubiese un mañana; en foros, blogs, youtube, la desesperación se apodera de ti, al menos esta situación ocurre en tus primeros días experimentando una distribución de Linux (es una calurosa bienvenida a la comunidad), si no te sucedió, ese momento llegará, ten paciencia, para un Linuxero incluso es una señal divina para cambiarse a una nueva distro, pero no perdamos el foco, de esta referencia quiero rescatar ese sentimiento de desesperación y búsqueda incesante.
Pongámonos en contexto con otro ejemplo para entender este arquetipo. Es viernes ya tienes el 90% de un feature que acordaste tener para hoy, 30 minutos antes de la hora del review surge un error que no lo habías esperado, tienes dos opciones, dejarla y señalar que el código que desarrollaste es inestable o encontrar el error a como de lugar, tu como yo preferimos al menos encontrar el error y elegir la primera opción como última alternativa ¿Cúal es la práctica común en este caso?, copias todo el error que señala la consola y la pegas en un buscador, ¿Qué tan efectivo es eso?¿Qué pasaría si no tuviésemos los potentes motores de búsqueda de hoy en día?¿Por qué copias todo el contenido de la consola?, exacto, eres victima del pánico, de ahí el nombre Kernel Panic.
En ese sentido, el arquetipo Kernel Panic se adueña de ti cuando realizas búsquedas y tratas de solucionar un problema con la menor brevedad posible. Detente, respira y recita el siguiente mantra… (claro que no), pero detente, lo más seguro es que des unos disparos al aire antes de darle uno certero a tu objetivo, ¿Cómo puedes librarte de este arquetipo?.
Consejos:
- Identifica los valores y referencias más importantes del log de error suscitado. A menudo el 70% de un todo un log de error es inútil y disminuye tus posibilidades de encontrar una solución si la buscas tal cual (en crudo).
- Busca primero el error en el código que generaste antes de empezar a pensar que es un problema con la tecnología que usas (lib, framework y otros). El log de error señala que archivo de tu código genero el error, el resto te lo delega a ti.
Pasemos al siguiente arquetipo, Handshaker. Te pones el traje de un Handshaker cuando preguntas acerca de tu problema/error/bug a una persona cercana a ti, a la cual consideras lo suficientemente experimentada como para darte una solución en minutos (un apretón de manos), lo más probable es que esta persona no pueda ayudarte eficientemente, ya que no basta con un pantallazo o screenshit, si con «i» ya que no siempre es de utilidad, tu problema puede tener muchos orígenes, si consultas a alguien por un error, asegúrate de brindarle toda la información necesaria para que entienda cual es el problema. Este arquetipo es muy útil cuando trabajas en equipo, así que asegúrate de que te entiendan y entiendan tu problema, en los detalles se encuentran las grandes respuestas.
El siguiente arquetipo es reciente y lo denomino como Pair Programmer, hace unos días vi que GitHub ya me habilitó la opción de usar GitHub Copilot, si no lo conoces GitHub Copilot es una IA que te genera código útil en función a tus necesidades expresadas en lenguaje natural como comentarios en tu código. Estuve probando como trabaja y me dí cuenta que ahorraría mucho trabajo y tiempo a un Copypaster novat@, lo que me preocupa es que aquellos programadores que andan iniciando la adopten, saltándose así algunas de esas etapas que te preparan para afrontar los distintos retos y problemas que implica el desarrollo de software. Y no, GitHub Copilot no quitará el trabajo a nadie, probablemente ayude a disminuir tiempos en los procesos de desarrollo, una vez se tenga estadísticas concretas haré un Post al respecto, mientras, quedémonos con meras especulaciones. Eres un Pair Programmer si usas GitHub Copilot y eres un buen Pair Programmer si lo usas con sabiduría, por el momento me abstendré de usarlo ya que prefiero seguir cometiendo errores controlables, suena un tanto improductivo, pero no olvides que un ser humano recuerda más sus errores que sus victorias, parte de aprender es equivocarte constantemente y parte de equivocarte es saber disminuir el impacto.
Todos los arquetipos expuestos son meras tipificaciones de patrones encontrados en Desarrolladores de Software a la hora de afrontar un problema/error/bug, este post ha sido redactado con fines de entretenimiento. Si te sentiste identificad@ con alguno de estos arquetipos hazlo saber en los comentarios, se aceptan más arquetipos ;D.
No quería cerrar el Post sin poner un arquetipo netamente positivo desde la raíz, a continuación les detallo al Bruteforcer, como su nombre lo indica es una persona que intenta resolver una y otra vez sus problemas sin rendirse ante las dificultades, una que constantemente busca el porque de las cosas y no le pone pausa ni trabas a su empresa, aquella que a las 5 de la mañana se va feliz a la cama habiendo resuelto sus problemas, es muy complicado ser un Bruteforcer de tiempo completo, ya que agota, muchos de los lectores habrán adoptado este arquetipo alguna vez (créeme, puedo notar tu sonrisa de satisfacción), pero como mencioné, no es tan fácil mantenerse en esa sintonía con un mundo que te ofrece tantas alternativas y escapes. Te invitó a ser un Bruteforcer de medio tiempo hasta superar los retos que te propusiste. En relación al Bruteforcer rescato una frase de Elliot Alderson en Mr. Robot (es un personaje ficticio, pero la frase esta genial).
Most coders think debugging software is about fixing a mistake, but that’s bull****. Debugging’s actually all about finding the bug, about understanding why the bug was there to begin with, about knowing that its existence was no accident. It came to you to deliver a message, like an unconscious bubble floating to the surface, popping with a revelation you’ve secretly known all along.
Mr. Robot – S1.Ep3: eps1.2_d3bug.mkv
Llegamos al final de este Post, continúa tu camino, no te saltes experiencias y aprende de tus errores. Hasta otro Post.
Redacción: EHCGroup / Mauricio Matias C.
