English version: https://medium.com/@ger86/5-habits-that-will-make-you-worse-as-a-developer-c1b93df2cac6

Ayer me puse a recopilar una lista de malos hábitos en los que diría que todos hemos caído alguna vez vez y que actúan como “frenos” en nuestro objetivo de mejorar como desarrolladores. Es decir, en este artículo encontrarás una serie de actitudes contra las que conviene estar prevenido pero que a menudo es difícil identificar: al fin y al cabo desarrollar suele ser un trabajo solitario y no es habitual que alguien esté pendiente de corregirnos. Además, cuanto antes seas capaz de reconocerlos antes te podrás desprender de ellos; ya sabes lo difícil que es quitarse de costumbres que llevamos haciendo “toda la vida”.

Así que espero que este artículo te ayude a evitar las malas prácticas o atajos de los que voy a hablar y que al final para lo único que sirven es para delegar los marrones en nuestro “yo del futuro”.

¡Vamos a verlos!

“Mí código es el mejor”

No hay nada que mas nos hinche el ego que ese momento en el que estamos con otros desarrolladores y nos toca el turno de hablar de nuestro código o de la forma en que resolveríamos un problema (a nuestra manera, claro).

Si bien es cierto que soy de los que defienden que la dosis justa de ego (visto como confianza en uno mismo) es un valor positivo, también creo que un ego desmedido a menudo provoca que seamos incapaces de mejorar (y de esto hay mucho pues creo que tendemos a ver nuestro código como una especie de hijo al que nadie puede criticar).

Por tanto, si entramos en la dinámica de creernos siempre mejores seremos incapaces de valorar otros puntos de vista que aporten soluciones distintas a las que se nos ocurrirían a nosotros algo que siempre aporta:

• nuevo conocimientos
• una mayor apertura de mente, es decir, si somos capaces de ver cómo piensan otros tendremos más recursos a la hora de buscar soluciones.

Como dice el refrán:

Tu aprendizaje termina el día que empiezas a creer que no tienes nada nuevo que aprender

Esto lo hago “en 5 minutos”

Nos encanta tomar “atajos”. Si algo podemos hacerlo en una hora en vez de en dos probablemente escojamos la primera opción aunque tengamos que sacrificar calidad. Esta situación a menudo se agrava si donde trabajamos se mide la productividad en líneas de código o, peor aún, en tareas resueltas. ¿Te suena el concepto de “deuda técnica”? Pues la toma de atajos es una de sus causas.

Creo que ser buen programador y en general buen trabajador (sea el sector que sea) implica saber distinguir las situaciones en las que es necesario sacrificar calidad en favor del tiempo y viceversa. Es decir, a veces simplemente no hay tiempo para escribir un código que respete todos los principios SOLID y que sea 100% reutilizable, pero ¡ojo! Cuanto más te acostumbres a reservar tiempo para encontrar la mejor solución (que a menudo no es la más rápida) mayor será la calidad del código que desarrollares y, sobre todo, menor el tiempo que posteriormente tendrás que invertir para mantenerlas.

Así que si has cogido el mal hábito de emplear atajos de forma constante respira y acostúmbrate a emplear tiempo en pensar antes de escribir. Eso o cambia de empresa. 😝

“Qué pereza documentar”

El otro día me topé con la siguiente frase de Dick Brandon que poco le falta para convertirse en un meme:

“Documentation is like sex; when it’s good, it’s very, very good, and when it’s bad, it’s better than nothing.”

En lo que a mí respecta, he conocido pocos desarrolladores a los que les guste documentar su código. Es más, no es la primera vez que escucho por las redes que mucha gente no documenta su código con el fin de sentirse irremplazable y que nadie pueda hacer su trabajo.

Sin embargo, creo que todos deberíamos acostumbrarnos a explicar todas aquellas partes que parecen “mágicas” y cuya razón de ser no parece evidente de un primer vistazo. Esta práctica la deberíamos adoptar tanto por los demás desarrolladores como por nosotros mismos ya que:

• probablemente tengamos que volver allí en algún momento y no hay nada más tedioso que rebuscar por toda la aplicación el motivo de un cálculo o de una determinada comprobación.
• nuestro trabajo es aportar valor a nuestro equipo y facilitar las cosas al resto de compañeros, no poner trabas para “sentirnos mejores”.

Eso sí, tal y como dice Robert C. Martin en su libro Clean Code: A Handbook of Agile Software Craftsmanship no caigas en la tentación de escribir comentarios en cualquier línea (“silly comments”), sino aprende a identificar las partes más complejas y explica el motivo de haberlo resuelto así.

Por tanto, líbrate del hábito de no escribir documentación y reserva tiempo para documentar tus aplicaciones, API’s o escribir comentarios en aquellas partes más confusas del código. Y por favor, mantén esa documentación actualizada. 😌

¡No he sido yo!

Que levante la mano quien no ha exclamado alguna vez esa frase. Cuando aparece un fallo siempre parece haber una excusa en vez de ser lo suficientemente maduros como para reconocer que ha sido culpa nuestra.

De verdad, no pasa nada por fallar. Nadie es perfecto.

Si queremos crecer debemos acostumbrarnos a fallar y a dejarnos enseñar para no volver a caer en el mismo error. No hay nada mejor si queremos estancarnos laboralmente que tomar como hábito la costumbre de echar la culpa al empedrado cuando aparece un problema. “No he sido yo”, “el usuario no lo está haciendo bien”, “nadie me había dicho eso” son excusas que tenemos que abandonar si queremos centrarnos en mejorar y ser más respetados dentro de nuestro equipo. Al fin y al cabo a nadie le gusta trabajar con alguien que no para de echar balones fuera como si nada fuera con él.

Te animo a que recuerdes esta frase: “cuanto antes admitas tus errores, más tiempo tendrás para aprender y solucionarlos”.

Ésto “ya está”

Creo que es muy habitual que demos por hechas tareas que desde el punto de vista del cliente o del usuario todavía no están resueltas. No se nos debe olvidar que debido a nuestra profesión nos encontramos en la cúspide de la pirámide que representa las habilidades para enfrentarnos a una aplicación informática pero no todo el mundo tiene esa facilidad para desplazarse por menús o ventanas. Es más, un gran diseñador UX que conozco siempre que dice que todas sus interfaces las prueba con su madre para saber si son válidas.

Por tanto, creo que conviene desprendernos del hábito de pensar que como lo hemos hecho nosotros es la mejor solución y comenzar a escuchar al resto del mundo: la cantidad de información que podemos obtener de ellos suele ser muy valiosa de cara a abordar problemas similares y es otra forma de adquirir nuevos conocimientos.

Esto por supuesto también se aplica a las “code reviews” y a los “pull requests”: tenemos que acostumbrarnos a escuchar que algo todavía no está terminado o que podría implementarse de otra forma.

Conclusión

Creo que la mejor forma de terminar el artículo es resaltar una palabra:

Equilibrio

Equilibrio a la hora de valorar nuestro código, de recibir opiniones y críticas ajenas e incluso en el momento de documentar nuestros desarrollos.

Irse a los extremos es una actitud que no suele dar buenos resultados. Aprende a situarte en el medio cuando se trata de un aspecto clave de tu vida diaria y verás como la mejora y el progreso vienen solos.

Otros artículos recomendados

¿Quieres recibir más artículos como este?

Si te ha gustado este artículo te animo a que te suscribas a la newsletter que envío cada domingo con publicaciones similares a esta y más contenido recomendado: 👇👇👇