Una vista desalineada: priorizar a los pares sobre los usuarios
¿Cuántas veces has mirado el código de alguien y dicho:
No estoy usando esto porque no se ve bien escrito.
Y en este caso, "parecer bien escrito" podría ser un sustituto de:
- “se ve como yo lo escribiría,"
- "Parece tener sentido para mí".
Claro, hay momentos en los que usar código fuente abierto es arriesgado. Lo sabemos por los diversos software y servicios que aparecen con vulnerabilidades. Pero, al menos para esta publicación, trátelos como la excepción, no como la regla.
Esto significa que nos quedamos mirando algo que podemos usar pero optamos por no usar porque no parece estar escrito de la manera en que pensamos que debería estar escrito.
Priorizar a los pares sobre los usuarios
El desarrollo es complicado porque hay varias concesiones que nosotros, u otro desarrollador, tenemos que hacer cada vez que construyen algo.
Mirando de adentro hacia afuera
Tenemos que considerar:
- limitaciones de tiempo y presupuesto,
- qué paradigma nos ayudará a entregar un sólido dentro de dichas limitaciones,
- ¿La solución final realmente resuelve el problema central?
- ¿Habrá costos de mantenimiento asociados con la forma en que armamos algo?
Y la lista podría seguir.
Considerar los diversos aspectos del desarrollo y debatir las filosofías de cómo se debe construir algo no es nada raro en nuestra industria.
Pero también requiere mucho tiempo, y puede resultar ser un ejercicio que arroja un resultado neto cero porque no resulta nada. (Sí, a menudo puede ser una experiencia de aprendizaje, pero no siempre).
Photo by José Alejandro Cuffia on Unsplash
Mirando afuera hacia adentro
Sin embargo, en términos prácticos:
- ¿El uso del paradigma para construir la solución afecta su uso del software?
- ¿El software en cuestión resuelve el problema?
- Si no pudieras ver cómo se montó el proyecto, ¿qué conclusión sacarías sobre el software?
Y el último punto puede ser el más crítico en lo que respecta al software de código abierto.
He trabajado en la industria el tiempo suficiente para saber que a menudo las personas quieren una solución funcional que resuelva su problema y asumen que está construida de forma segura.
Los desarrolladores, por otro lado, examinarán el código más que la solución que proporciona y el problema que resuelve.
Si eres un desarrollador, hay absolutamente un momento y un lugar para ambos. Pero si permite que este último le impida enviar el primero, es posible que nunca obtenga algo para que otros lo usen porque está demasiado preocupado por lo que puedan pensar sus compañeros.
Y cuando estás resolviendo un problema para otras personas, deberían ser ellas las que importen más que tus compañeros.