Siete hábitos de los programadores inefectivos

Como desarrolladores, saber qué hacer para ser productivo es importante, pero saber qué NO hacer lo es casi más.

El otro día estuve revisando Reddit para estar al tanto de qué se cuece en temas de programación, y me encontré un interesante post de la empresa SitePen donde analizan los siete hábitos de los programadores altamente inefectivos.

Los artículos sobre cómo aumentar la productividad en el trabajo de un desarrollador están a la orden del día: desde aplicar técnicas de gestión del tiempo como Pomodoro, hasta el clásico “empieza/termina el día haciendo ejercicio”. Aunque considero importante saber qué hacer para ser más productivo, también considero igual de importante saber qué no hacer. Verse identificado en errores también nos puede ayudar a cambiar nuestra forma de trabajar.

Miedo a perderse algo (FoMO, Fear of Missing Out)

El miedo a perderse algo (FoMO, Fear of Missing Out) es un estado de ansiedad donde una persona quiere estar siempre al tanto de todo e incluso ser partícipe. Más popularizado a raíz del boom de las redes sociales y los smartphones, el FoMO es el miedo a la exclusión, a no formar parte de un evento o de una situación por estar haciendo otra distinta. Pese a que tiene un transfondo más “social”, también es aplicable al entorno del desarrollo software.

La situación más común ocurre cuando quieres introducirte en una tecnología, buscas un poco y te das cuenta que existen docenas de frameworks, librerías y metodologías distintas. ¿Estoy utilizando la mejor herramienta posible para este desarrollo? ¿Habrá alguna mejor que yo no conozca? Esta pregunta, que todos nosotros nos hemos hecho alguna vez, es el claro reflejo de un estado de ansiedad que, en según qué contextos, puede ocasionar más de un quebradero de cabeza.

Si bien es cierto que elegir las herramientas y frameworks adecuados desde el primer minuto es importante, también es verdad que es imposible saber en muchas ocasiones qué forma tendrá el software. Programar se basa en ir adaptando y refactorizando lo inevitable, y debemos ser conscientes de ello.

Usar una librería porque muchos la utilizan

En algún punto del desarrollo siempre es necesario integrar librerías desarrolladas por terceros: jQuery, Vue.js, ReactJS, algún paquete npm, etc. La elección de las mismas no siempre es tan evidente, y una mala decisión puede conllevar una refactorización infernal.

Sin caer en esa ansiedad que comentaba anteriormente, tampoco es buena idea utilizar algo simplemente porque otros la estén usando. Argumentos como “Mucha gente está utilizando…” o “Tal empresa utilizó para su desarrollo…” no siempre deberían ser suficientes para tomar una decisión.

Esta discusión la sufro a menudo cuando me enfrento a un proyecto y decido hacerlo en una tecnología concreta. Por ejemplo, ahora mismo me encuentro desarrollando un proyecto que tendrá Node.js, MySQL, Express y ReactJS (stack MERN). Pues tranquilamente 10 personas me habrán “sugerido” usar PHP porque “es más robusto”, usar MongoDB porque “es más escalable” o usar AngularJS porque “es más completo”. ¿Sabes lo mejor? Que todos ellos tienen razón, pero este proyecto se va a realizar con estas tecnologías porque estamos en una fase muy inicial, y para nosotros es más que suficiente.

Nuestras decisiones, como expertos, deberían basarse en simples preguntas, como: ¿Qué problema estoy resolviendo? ¿Esta librería me ayudará a medio/largo plazo? A esto, yo personalmente siempre me planteo: ¿necesito todo el contenido de la librería, o sólo un subconjunto? Por ejemplo, jQuery es casi un estándar hoy día, pero en muchas ocasiones es matar moscas a cañonazos. Si sólo necesito realizar tareas sencillas en Javascript, ¿por qué no usar Javascript y ya está?

Porque mi Jefe de Proyectos lo dice

Pese a no ser un argumento muy común en entornos pequeños, es algo muy repetido en entornos más corporativos. Simplemente tu Jefe de Proyectos te dice “usaremos esta tecnología” pese a que tú o tu equipo no está de acuerdo, y además no puedes argumentar lo contrario.

En mi opinión, un desarrollador no debería estar adoctrinado en el uso de un conjunto de tecnologías, sino ser lo suficientemente abierto para adaptarse y saber qué usar según el momento. Yo por ejemplo trabajo bastante con React Native y sé que es una muy buena solución para la creación de aplicaciones híbridas, pero también soy consciente que hay aplicaciones que requieren ser realizadas nativamente en cada plataforma por cuestiones de rendimiento.

En entornos corporativos se utiliza bastante la amalgama de múltiples tecnologías, pagando licencias astronómicas, y cuyos desarrolladores sólo se encargan de unir piezas. Muchas veces esta unión no es sencilla, o da más problemas que inconvenientes (cayendo, a su vez, en esa generalización indebida que hablábamos). Si como desarrolladores no podemos aportar nuestra opinión sobre qué utilizar (aunque tengamos argumentos sólidos), quizás no estamos en el lugar adecuado. Un Jefe de Proyectos debería ser capaz de escuchar los argumentos de todos, y luego tomar la decisión adecuada: el desarrollo software no es dogmático.

Si funciona para esto, funcionará para todo

Uno de los mayores errores que podemos cometer como desarrolladores es suponer que si algo funciona local, con cuatro cambios funcionará a mayor escala. Esto podemos definirlo como la Falacia de Composición:

Algo es verdadero acerca de un todo solo porque es verdadero acerca de una o varias de sus partes.

Un ejemplo típico de esto es suponer que, como los tests unitarios en los módulos de la aplicación han sido satisfactorios, cuando integremos todo no habrá problemas. La solución pasaría por realizar tests de integración y ver cómo se comporta el sistema al completo cuando todo está funcionando a la vez. Lo mismo ocurre cuando testeamos localmente nuestra aplicación, para luego subirla al servidor y comprobar que falla. Aún siendo entornos similares existen factores que muchas veces obviamos y son muy importantes: la versión del sistema operativo, alguna dependencia fantasma que hemos pasado por alto, la localización geográfica del hosting, DNS, etc.

El Aprendiz Experto

Aprendiz de todo, maestro de nada. Es mejor enfocarnos en conocer algo bien, que en saber de todo un poco.
Aprendiz de todo, maestro de nada. Es mejor enfocarnos en conocer algo bien, que en saber de todo un poco.

Suena un poco contradictorio, pero aquí en España tenemos una frase para ello: aprendiz de mucho, maestro de nada.

Veo CVs en LinkedIn que harían temblar al mismísimo Da Vinci por la cantidad de tecnologías que dominan algun@s. Saber muchas tecnologías es algo bueno, pero es imposible dominarlas todas por una pura cuestión de tiempo. Debemos elegir qué es lo que más nos gusta, e intentar ser los mejores en ellos. Intentar tocar todos los palos sin llegar a dominar ninguno afecta muy negativamente a nuestra productividad en el corto-medio plazo.

No reconocer los errores

Que levante la mano quien haya oído alguna vez la frase “pues en local/desarrollo/mi PC funciona”. Como desarrolladores y a lo largo del tiempo vamos creando un ego propio que nos impide discernir cuándo lo estamos haciendo mal, o cuándo hemos implementado una chapuza épica en el código.

Mi opinión es que este ego va gestándose cuando empezamos a hacer nuestros primeros pinitos en la programación, cuando programamos solos y somos dueños absolutos del código. Al no tener a nadie que añada/modifique/borre código en nuestro proyecto, creemos que todas nuestras decisiones son acertadas. De ahí que cuando empezamos a utilizar sistemas de controles de versiones como Git, o cuando entramos en entornos corporativos y recibimos revisiones de código, pensemos “¡pero si mi código es buenísimo!”, incurriendo en discusiones e hilos kilométricos tratando de excusar la baja calidad de nuestro código o nuestras decisiones. Porque sí: todos hemos creado alguna vez código que daba asco.

Es por ello que debemos ser capaces de juzgarnos a nosotros mismos, reconocer nuestros errores y, sobre todo, escuchar. Negar lo evidente y encerrarnos en nuestra propia subjetividad no nos reportará sino una baja productividad, que a veces podría llevar a una exclusión por parte del equipo de desarrollo (“yo con esta persona no trabajo más porque siempre quiere tener la razón”).

Continuamente desanimado

El artículo original lo escribe como “Actively disengaged”, y yo libremente lo traduzco como ese estado en el que nada te complace. Simplemente ha dejado de gustarte lo que haces independientemente del motivo, y eso se traduce en un bajo rendimiento que en ocasiones puede transmitirse al resto del equipo.

Existen muchas soluciones a este problema, desde cambiar de trabajo hasta encontrar cosas que te motiven. Mi experiencia personal me dice que una de las mejores soluciones es hablarlo, a poder ser con gente de tu entorno laboral para que puedan ayudarte y hacerte verte qué podrías cambiar para mejorar esa situación.

Ser productivo es complicado, y darse cuenta de que uno está siendo productivo también. Muchas veces como programadores sentimos que estamos perdiendo el tiempo porque llevamos 1 hora con un bug estúpido que no conseguimos arreglar, porque estamos implementando una característica que no va a usar nadie o porque estamos trabajando en un proyecto que no nos gusta. Todo esto también es parte del trabajo, y no deberíamos caer en el pozo del desánimo por ello. Intentar verle el lado positivo al asunto también funciona, y a la larga veremos como en realidad sí estamos siendo productivos.

Nota: este artículo es una traducción libre del artículo 7 habits of highly ineffective developers publicado por SitePen con anotaciones propias basadas en mi experiencia.

test