Wednesday, August 16, 2017

Errores en el trabajo: supercoders solitarios

Entre los errores que he cometido laboralmente, hay uno en particular que veo muy seguido en mis compañeros y yo también lo he cometido groseramente. Generalmente ocurre cuando estamos trabajando en productos nuevos donde las posibilidad de implementaciones son muy variadas y la solución está muy abierta.

Superman o supercoder

Y es así como de a poco me fui emocionando con las formas en las que podía realizar mi implementación, aplicando patrones de diseño, buenas prácticas de codificación, entregando una solución a tiempo, y además preparando el proyecto para las futuras mejoras que posiblemente teníamos que agregar en el mediano plazo.

Todo parecía muy tranquilo, mis compañeros de equipo estaban preocupados en otras partes del proyecto y por fin podía trabajar en algo desde el comienzo. Resolver defectos y agregar pequeñas funcionalidades parecían cosas del pasado. Uno se siente poderoso dibujando cajitas y sus interacciones, mi cerebro parecía trabajar a niveles inexplorados y ya no necesita ayuda de mis compañeros.

¿Quién vigila a los super programadores?

Me encontraba listo para entregar una solución que cumpliera con todos los criterios de calidad, velocidad, tiempo de desarrollo y más.¿Qué podría salir mal? ¿Que cosas estaba dejando de lado? ¿Cuales fueron los errores que cometí en esa solución a la que le dedique muchas horas de mi vida?

Primero dejar en claro que el código y los proyectos no son de una sóla persona, todo lo entregado es del equipo y del cliente. Primero del equipo porque éste tendrá que mantener y hacer nuevas implementaciones sobre el código. Qué tan difícil o fácil sea modificar un proyecto tiene directa relación en cómo el equipo se distribuyó y de las decisiones que tomó. El cliente, por otro lado, es quién utiliza el sistema y conoce cómo producir el dinero, también es quién paga para que los desarrolladores hagan su trabajo. Todos ellos son los vigilantes, interesados y tienen el deber de corregir lo que se está haciendo, en otros casos pedir retroalimentación del producto y entregarla según las responsabilidades que tengan.

A continuación describo algunas observaciones durante este tipo de situaciones:

No revisar ni consultar sobre la implementación


El desarrollador estrella no puede encaminarse sin preguntar a sus compañeros para resolver un problema difícil. Una persona no puede, a menos que sea muy experimentado y le sea muy común entenderse con ese tipo de problemas, diseñar e implementar la solución de forma solitaria. Si lo hiciera asì ¿Para qué existe un equipo?

Nadie más puede entender o quiere entender lo implementado

En muchos casos, y lo menciono porque confío mucho en esas mentes, el desarrollador puede llegar a una muy buena solución para un problema difícil por sí sólo. Sin embargo, las otras mentes también tienen su orgullo y quieren participar de este tipo de soluciones. Si ellos no pueden obtener el contexto de la solución ni ayudar, entonces se hace cada vez más complicado explicarles una solución porque saben poco de la problemática y todo les parece muy enredado, tampoco fueron parte de èsta.

Lo peor, el código será modificado en el futuro y se produce una desmotivación en el equipo


Naturalmente, el equipo se va a ir alejando de esas piezas de código que desconocen. Sienten que es algo que no les pertenece, no entienden y sòlo el super programador que lo creó puede modificarlo.
El resto del equipo no tiene ganas de trabajar en esa parte del proyecto y en casos más extremos, tampoco trabajar con ese superman en la programación.

Confiar y cuidarnos de nosotros mísmos


El futuro no es prometedor en casos como éstos, las mejoras en esos proyectos no son bien recibidas y en muchos casos se termina refactorizando gran parte del código traduciéndose en horas perdidas. Atentos en identificar cuándo nos estamos comportando de esa forma tanto en la programación como en otros tipos de trabajos.

No comments:

Post a Comment