Aunque hay excepciones, es cierto que los programadores somos muy celosos de nuestros desarrollos y muy críticos con lo que hacen los demás. ¿Por qué a la mayoría de los programadores sólo nos gusta nuestro código?
El feedback negativo
Lo primero que más nos cuesta es dar feedback positivo a lo que otro programador nos enseña sin añadirle feedback negativo acompañado de sugerencias y mejoras. Por ejemplo, nos enseñan una nueva funcionalidad en una aplicación y es muy fácil que el comentario que hagamos sea "está muy bien, PERO le falta esta funcionalidad". A mi me cuesta dar sólo el feedback positivo ¿Y a ti? ¿Por qué nos empeñamos en aportar nuestro granito de arena siempre?¿Nunca te ha pasado a ti recibir feedback negativo cuando estás enseñando algo con toda tu ilusión? ¿Qué has sentido cuando te lo han dicho?Personalmente te puedo decir que yo lo hacía y desde hace un tiempo trato de corregirme y convertir en hábito el dar sólo el feedback positivo. No es fácil, porque cuando hablamos de programación nos pasa, sin embargo con otros temas no nos ocurre con tanta facilidad.
¿Qué yo tengo que usar y mantener el código de otro programador?
Volviendo al título del artículo hay un segundo aspecto muy generalizado entre los programadores. A ninguno nos suele gustar mantener el código de otro programador. Salvo por obligación preferimos rehacer el programa a nuestra manera antes de utilizar o mantener lo desarrollado por otros programadores.¿Por qué?Creo que hay dos grandes respuestas: el orgullo y la comodidad.
El orgullo
Es bueno sentirse orgulloso de lo que uno hace. Lo que no es positivo es creer que tus programas son los mejores del mundo y están desarrollados con los mejores criterios. Tampoco es positivo asumir que lo que yo no he programado o está mal o me costará más entenderlo que hacerlo, sin embargo, lo habitual es que entre aprovechar el código de otro programador y rehacerlo nosotros hay una clara victoria de la segunda opción.
La comodidad
Aquí es donde entra la comodidad. Nada es más cómodo que movernos por nuestras aplicaciones, todo está en su sitio, los criterios de organización y nomenclaturas son conocidos al 100% así como la relación de los objetos y procesos. Sin embargo, hacer un cambio en el programa de otro supone un esfuerzo extra, primero para conocer y comprender como está desarrollado y segundo para encontrar las cosas que están organizadas con otro criterio antes de poder modificarlas. Este desconocimiento lleva asociado el sentimiento de miedo a que la modificación que realizamos pueda tener efectos secundarios no previstos.
Beneficios
En definitiva, orgullo y comodidad se unen para hacer un frente común contra el uso de lo desarrollado por otros programadores. Y aunque, como es lógico, habrá ocasiones en que es mejor rehacer que reaprovechar, esta mecánica cognitiva hace que perdamos las grandes ventajas de usar programas de otros desarrolladores:
- La suma de lo de todos me hace crecer más rápido.
- Cuántas veces el código de otro programador me ayuda a aprender nuevas tecnologías.
- Aprendo de los métodos de programación de otros y viceversa.
- No tengo que mantener todos los módulos que uso e implanto.
- Puedo focalizarme en mi especialidad.
- Puedo vender mi código a otros desarrolladores.
- Seré más rápido implantando soluciones.
- Las mejoras de los demás mejoran mis soluciones implantadas.
- Mi negocio será más rentable.
Obviamente obtener estos beneficios me obligan a pagar un precio y asumir que:
- Lo que otros hacen no será igual que lo que habría hecho yo.
- Siempre me faltarán o sobrarán cosas.
- Debo buscar y aceptar la simplicidad que es lo complicado de conseguir.
- Tengo que valorar el trabajo de los demás y el ahorro que eso me supone.
- Aunque por dentro el código sea diferente, visualmente el usuario no debe notarlo.
En definitiva, aunque no sea como yo lo haría debo asumir que lo que sobra y falta se compensa con todas las ventajas anteriores. Para conseguirlo necesitaré usar herramientas comunes como:
- Una guía de diseño de la interfaz.
- Una guía con normas de programación.
Estamos en marcha
En Velneo ya hemos dado pasos en cuanto al diccionario de abreviaturas y normas de programación y estamos trabajando en una guía de diseño de interfaz. En todos los casos deberán tomarse como guías de recomendaciones que nos ayudarán a obtener los beneficios antes nombrados y que, a la vez, nos da flexibilidad para introducir nuestros propios criterios de programación.¿Te sientes identificado con el perfil de programador descrito en el artículo?
