Antes de comenzar a hablar sobre este tema, quisiera recalcar que lo que voy a mencionar acá es de una de mis secciones favoritas del libro "Código sostenible" de Carlos Blé que más me hicieron reflexionar en mi proceso como profesional. Esto no lo digo para demostrar que lo dicho en este post de mi blog es una verdad absoluta, simplemente por el hecho de que lo leí en un libro, sino para dar en cierta parte créditos y gracias al autor por su aporte con este libro que es muy enriquecedor para cualquier persona que trabaje o esté entrando en esta industria del desarrollo de software.
Dicho esto, comencemos mencionando que escribir código para que este funcione es relativamente fácil, sin embargo, el arte se encuentra en escribir código que otros entiendan y puedan modificarlo. El arte es un acto generoso que requiere una combinación de talento, habilidad, oficio y un punto de vista diferente. Cuando somos capaces de crear una obra transformadora es a lo que podemos llamar arte. Y si lo pensamos bien, un buen software transforma la vida de los demás en cierta medida.
Un código simple, detallado, expresivo y explícito es capaz incluso de transformar la forma en la que el lector o la lectora entienden sobre lo que implica programar. El trabajo que hagamos es importante y valioso para las personas que usarán nuestro software, pero igual de importante es para las personas que darán mantenimiento a este mismo.
Desarrollar software es un trabajo en equipo. Un equipo muy particular que no estará formado únicamente por las personas que trabajan hoy, sino también por las que estuvieron en un pasado y estarán en un futuro. Ya que las que estuvieron en un pasado nos dejaron un software valioso, que genera ingresos y aunque lo hayan hecho lo mejor que pudieron, también nos legaron limitaciones y dificultades con las que tenemos que luchar hoy. Es algo lo cual tenemos que aceptar y seguir prestando servicio, además de mejorar para facilitar el trabajo de quienes vendrán en un futuro. El software tiende a degenerarse con el tiempo, y esto muchas veces es porque no recubrimos con tests de calidad ni preservamos la simplicidad.
La forma que tenemos de evitar lo anterior mencionado en nuestros software es codificar para las personas y no para las máquinas. Ya que esto no va de actos heroicos individuales, sino de inteligencia colectiva.
Crear código sostenible es importante. Primero porque se espera que hagamos un trabajo técnico de excelente calidad. Al final nadie que vaya a pagar un software desea que le entreguen un trabajo mal hecho. Trabajamos para uno de los sectores mejor pagados y debemos estar a la altura ofreciendo los niveles de calidad acordes. Y aquí es donde deberíamos pararnos un momento y preguntarnos qué, si tuviésemos el dinero, ¿invertiríamos nuestro propio dinero en nuestro proyecto? Esperemos que la respuesta sea que sí, ya que eso implica confianza y satisfacción por un trabajo bien hecho.
Estamos al servicio de otros profesionales que esperan una mejora en su productividad gracias al software que construimos para ellos. Mediante el asesoramiento, el acompañamiento y la entrega continua de software que funciona, es una de las mejores maneras que tenemos de ofrecer soluciones ágiles y adaptadas. Ya que es muy difícil entregar un software con la cadencia adecuada si su diseño y su código son insostenibles.
La calidad de código es muy importante para la sostenibilidad del desarrollo, pero bajo mi percepción la calidad de la relación entre las personas es aún más importante. Un grupo de personas que trabaja en equipo siempre llegará más lejos que un individuo, por más voluntad que este le ponga. El esfuerzo que ponemos en realizar un trabajo técnico de calidad día tras día nos puede hacer olvidar de que el código no es de nuestra propiedad, ni mucho menos una extensión de uno mismo, ya que esto puede perjudicar el bien del equipo y no podemos permitir que nuestro orgullo como programador o el cuidado del código esté por encima del cuidado de las relaciones y las personas. El código es parte de todo el equipo y el trabajo que hagamos no consiste precisamente en programar, sino en resolver problemas.
El mayor reto en el desarrollo de un proyecto de grandes dimensiones es el trabajo humano en cierta parte; lleva tiempo que personas con diferentes formas de ver las cosas, experiencias, habilidades y conocimientos choquen contra los de nosotros o los de otros miembros del equipo, al punto de que esto nos consumirá energía. Es algo que requiere cuidado, ya que a diferencia del código que no se arruina en un solo día, las relaciones entre las personas podrían romperse en una simple discusión. Un lema que nos recuerda Carlos Blé es, «firme con el asunto, pero flexible con la persona». Si ves que un miembro del equipo hizo o hará algo que pueda llegar a afectar al desarrollo del software o bien romper alguna de las reglas del equipo de desarrollo, siempre es bueno optar por preguntar, buscar el diálogo. Y creo que esto es algo de valorar, el ver como se opta por asumir en buena voluntad, en vez de acusar o reprochar. Dejar comentarios afilados de manera asincrónica (por ejemplo, pull/merge request) no es algo sano. Va a ser más barato, efectivo y rentable tener una conversación cara a cara.
Para finalizar, quisiera mencionar que quizás yo no sea el mejor ejemplar para hablar sobre estos temas, ya que soy un programdor aún en aprendizaje y con apenas más de tres años de estar aprendiendo sobre este mundo. Pero eso no significa que no pueda aprender sobre los testimonios de los demás para así nutrir de la mejor manera mi carrera como profesional. Y esto se los comparto porque de la misma manera que fue muy enriquecedor los consejos y experiencias contadas por Carlos Blé, puede serlo para ustedes también. Sé que estos suelen ser temas de mucho debate, pero siempre y en cuánto se intercambien ideas desde la humildad y de una manera sana se podrá seguir aprendiendo sobre este y muchos temas más. Recuerden programar no solo para ustedes, sino sobre todo para los demás. 👨💻