Saltar al contenido

¿Deseas suscribirte al blog y recibir mis últimas actualizaciones? Haz click aquí.

That javascript framework was so this morning (and so was that problem)

Una de las cosas que un ingeniero disfruta (o debería) es solucionar problemas, es una actividad naturalmente atractiva para quienes deciden dedicarse a esta fina profesión. Esa misma curiosidad nos hace constantemente buscar otros desafíos.

Particularmente, en el desarrollo de software, buscar soluciones a problemas pequeños es una constante que usualmente nos mantiene entretenidos y ocupados sin embargo, es común que nos bloqueemos al grado de no querer continuar con nuestro trabajo, una especia de «Sindrome de bloqueo del escritor»

¿Por qué perdemos el interés en la tarea actual, el proyecto o a veces nuestro empleo?

A todos nos ha pasado: estamos horas tratando de resolver un problema, diseñar un algoritmo, el programa no compila o no corre, en fín, infinidad de obstáculos que después de una cantidad razonable de tiempo se vuelven tediosos y nos aburren. Algunos se levantan de su escritorio a caminar y pensar un poco, otros van a la tienda por una coca, otros se fuman un cigarro… después regresamos a nuestro escritorio con la mente un poco más despavilada a tratar de solucionar el problema.

Otros, como yo, simplemente necesitamos un poco de concentración. A mi particularmente me ayuda estar solo, sin ruido. Es común que mientras trabajo no esté escuchando música como muchos de mis compañeros lo hacen, yo lo relaciono con mi poca capacidad de multitasking (aunque honestamente, no creo que ningún ser humano sea capaz de hacer varias cosas a la vez, o no bien al menos) incluso me es a veces necesario aislarme por completo sin presencia de nadie para poder pensar en la solución más adecuada a un problema, como Sherlock con su «palacio mental«.

El aburrimiento

Estar aburridos creo que es la principal causa de bloqueo u obstáculo para solucionar un problema y tiene todo el sentido del universo, es decir, si no estamos cautivados por lo que nos encontramos haciendo en este mismo instante, es decir, sumamente interesados ¿Cómo nó vamos a estar aburridos? Aunque en este caso el estar aburrido creo es la consecuencia y no la causa, además, estar aburrido es una de las cosas mas naturales y humanas que podemos experimentar los homo sapiens. Osho, conocido (y controvertido) gurú hindú, comentaba en una de sus entrevistas:

No animal is ever bored. Look at a buffalo, chewing grass, the same grass every day, sitting and chewing and chewing, never bored. You may get bored looking at her: she is not bored. No animal is ever bored, you cannot bore an animal. Too thick, too dense a mind -how can you bore? For boredom a very, very high sensitivity is needed, the higher your sensitivity the higher will be your boredom, the more will be your boredom.

Los humanos tenemos una sensibilidad profunda y somos emocionales lo cual fomenta cambios de ánimo, como el estar aburrido y contrario a ser algo negativo es un indicador de que somos seres que razonamos y buscamos adquirir conocimiento constantemente, hasta el día de nuestra muerte.

Estar aburridos, insisto, sería una consecuencia y no una causa.

Distractores

Obviamente lo primero que se nos viene a la mente son las redes sociales, el teléfono, etc. Aunque conozco muchos colegas que se distraen fácilmente con estos, llamemosle «artefactos«, hay quienes aun sin este tipo de distracción pueden perder el interés. Existen otros detonantes para distraernos de nuestro trabajo ya sean problemas personales, familiares, deudas, el resultado del partido del domingo, un viaje, etc. Creo que todos estos distractores los conocemos bien y no son específicos de nuestra profesión sino de cualquier persona que no sepa hacerse responsable de su trabajo.

Existen otros distractores, sin embargo, que hacen que nos enfademos de nuestro trabajo y que curiosamente los tenemos todo el tiempo entre nosotros, están escondidos ahí, como soldados aqueos en un caballo de madera.

A los primeros les llamaría yo distractores «naturales», es decir, vienen de paquete con el hecho de que somos humanos y que necesitamos «despavilarnos» de cuando en cuando. El uso (y abuso) de los mismos es responsabilidad de cada individuo: hay trabajadores huevones que siempre buscarán un pretexto para no hacer bien su trabajo y hay otros que simplemente necesitan un «break» e independientemente del tiempo «fuera» cumpliran sus metas.

Al segundo tipo de distractor les llamo «artificiales» porque de alguna manera los desarrollamos inconcientemente, sin saber que estan ahí.

¿Cuáles son estos distractores artificiales, particularmente para los programadores?

Aquí un claro ejemplo:

El tweet anterior no solo es sarcástico y gracioso también es certero. ¿Cuántos nuevos frameworks de desarrollo nacen con la simple justificación de ser nuevos, de ser diferentes?

Programming «Gamification«

El término gamification se entiende como la actividad o metodología de «premiar» simbólicamente a un individuo por completar tareas, cumplir metas o resolver problemas. Por ejemplo, un caso contemporaneo es foursquare / swarm o untappd para los amantes de la cerveza: cuantos más lugares conocemos o más tipos de cerveza probemos se nos proporciona un badge, o medallita que, aunque nos hace sentir que competimos, es igual de relevante que las estrellitas que nos pegaban en la frente en el jardín de niños.

Algo que he notado en programadores, sobre todo en los menos experimentados, es precisamente una necesidad de obtener algún tipo de reconocimiento por la cantidad de conocimiento con la que cuentan sin que necesariamente este se traduzca a algo útil para los usuarios finales quienes son, al final del día, la razón por la cual estamos desarrollando nuestro producto.

Conocer más lenguajes modernos, entender los frameworks más inovadores y radicales, cantidad de repositorios en github, todas actividades muy loables y necesariamente perseguibles para no quedarnos atrás con las nuevas tecnologías y perder práctica, sin embargo debe existir un balance saludable entre teoría, práctica y productividad.

Es mas o menos como juzgar un proyecto de software por su cantidad de líneas de código y deducir que a mayor cantidad es mejor, lo cual es obviamente falso. De la misma manera, tener cientos de commits a un proyecto no necesariamente aportan valor. El valor se encuentra en la utilidad de dicho código para quien pretenda utilizar nuestro software.

Como «project manager» constantemente me encuentro con código poco probado que el desarrollador asegura está listo o que incluso pasa las pruebas unitarias y que desde la perspectiva de desarrollo «sirve» pero desde la perspectiva de calidad de producto deja mucho que desear y la razón por la cual sucede esto es precisamente una aparente e innecesaria prisa por entregar rápido y pasarnos al siguiente problema porque ya nos aburrimos del anterior.

Similar a esto, algún colega, desarrollador de PHP comentaba recientemente en un foro el hecho de que muchos programadores apenas tienen algo de experiencia en un lenguaje o herramienta, se brincan a otra para poder solucionar otros problemas con paradigmas diferentes (y que si lo sabemos quienes aun tocamos PHP). Tal es el caso de node.js, tecnología completamente diferente a otros lenguajes o plataformas mas tradicionales que precisamente trata de solucionar problemas diferentes, no los mismos problemas con diferente código.

Desarrollar en tecnologías «viejas» como PHP o Java puede no ser cool, pero puede ser productivo. Desarrollar en nuevas tecnologías solo porque están de moda no necesariamente solucionará nuestros problemas.

En general podría decir que quienes buscan ser productivos se preocupan menos por las herramientas y más por el producto mientras que quienes buscan brillar en la comunidad haran lo contrario: estar al grito de la moda en tecnologías aun cuando no signifique algo laboralmente hablando. Ambos buscan reconocimiento, los primeros de sus clientes y usuarios, los otros de sus propios colegas. Los primeros son relevantes para quien usa el software, los segundos no tanto.

La generación Github

Una de las cosas mas espectaculares que le ha sucedido al gremio de desarrolladores es github y el trabajo en colaboración por medio de Internet ya que propicia inovación sin lugar a duda. Como hub de desarrollo, camaradería y aprendizaje es una plataforma excelente, sin embargo esto no necesariamente significa que todo lo que encontramos en ese vasto sitio sea de calidad.

La idea de colaboración open source no es nueva. Existieron sitios anteriormente como sourceforge, berlios y otros. Incluso antes de que colaborar y compartir código  por Internet fuera razonablemente posible existieron comunidades de desarrollo abiertas por medio de mailing lists, canales de IRC y simples servidores de FTP.

Es precisamente la comunidad de desarrollo abierta la que más experiencia tiene en este tema, la de la vieja escuela. Una de las razones (ampliamente discutida por expertos en el tema) por las cuales, por ejemplo, muchos productos open source o libres no terminan de «cuajar» es por el protagonismo tanto de sus autores como de sus contribuyentes: cuando el autor original de un producto rechaza un parche por mala calidad, no seguir los lineamientos del proyecto o simplemente porque considera que es un feature que no va de la mano con el objetivo del software era común que dicho contribuyente creara un fork o versión alterna del proyecto, que persiguiera los objetivos del segundo. Esta actitud ha dañado al ecosistema de software open source por años, particularmente al software de escritorio. La razón generalmente era la misma: búsqueda de reconocimiento por encima de buscar solución a un problema.

Esta mentalidad se ha ido pasando de generación en generación, particularmente en github y comunidades aledañas: crear software desde cero porque nosotros creemos que nuestra manera de abordar un problema es mejor.

Si lo vemos desde el punto de vista de un programador que pudiera aportar conocimiento y esfuerzo a un proyecto entonces vemos que ese potencial contribuyente a dicho proyecto duplicará esfuerzos tratando de resolver exactamente el mismo problema. De igual manera, quienes consumen su tecnología tendrán que aprender, de nuevo, otra nueva tecnología y muy seguramente, aun sin dominarla, tendrán que estar pendientes el nuevo chico de la cuadra.

Pareciera que estoy en contra de las comunidades de desarrollo y el open source ¿Cierto?

Un claro ejemplo de como se busca más el reconocimiento que los resultados tangibles es el caso de OpenSSL, componente de software utilizado prácticamente en todos lados, en todo el mundo, necesario para encriptar casi cualquier cosa que utilicemos como usuarios finales o como programadores ¿Cuántos contribuyentes existen? ¿Cuántos forks? Recientemente y a raíz del bug heartbleed los mantenedores del proyecto tuvieron que pedir ayuda financiera, casi como limosna, en un llamado de emergencia por la poca cantidad de recursos con la que cuentan.

¿Por qué tan pocos programadores han contribuido al desarrollo de OpenSSL? Bueno es muy simple, porque no es un producto particularmente inovador, hace lo que debe hacer y lo hace bien, a nadie le interesa tocar en una banda de jazz, todos quieren ser miembro de la banda de pop de moda, o un rockstar. Y así como hacer playback es más fácil también lo es crear un pequeño framework web. Tocar jazz en este caso es una buena metáfora para la cantidad de conocimiento, técnica e inteligencia que requiere diseñar algoritmos de seguridad.

Enfoque y objetivos como solución

Tener un objetivo de la tarea actual, milestones de nuestro proyecto o del producto final como tal es sumamente importante, y para poder trazarlos debemos:

  1. Entender el problema que debemos solucionar
  2. Procurar investigar si hay una manera ya existente de solucionarlo, no reinventar la rueda
  3.  Entregar calidad: ¿Hace mi software lo que el usuario espera que haga?

Creo que la mayoría de las veces perdemos precisamente el enfoque por estar pensando e invirtiendo tiempo en temas auxiliares al objetivo principal, como que framework usar, convenciones de código, entornos de desarrollo, proveedores de cloud hosting, bugtrackers, etc. Estos puntos deben de tratarse como decisión o consecuencia del análisis de los 3 puntos que mencioné arriba y no al revés.

Muchas veces veo a desarrolladores sumamente inteligentes y astutos ansiosos por aplicar alguna nueva librería, lenguaje o metodología sin embargo no tienen ningún problema que solucionar. Es más fácil (y divertido) encontrar desafíos y problemas técnicos para aplicar tecnología que inventar o aprender tecnología nueva por si «algún dia la necesitamos».

Le llevó años de trabajo a Thomas Alva Edison (y a otro puño) desarrollar un foco con filamentos para solucionar un problema simple: iluminación artificial y llevó otros casi 80 años solucionar un nuevo problema: focos que hicieran uso eficiente de energía. ¿Por qué estamos entonces tan apurados como desarrolladores por solucionar un nuevo problema si aun no hemos solucionado el anterior?

 

Publicado enCiencia y Tecnología

Sé el primero en comentar

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.