Número 10
4 de maio de 2022
|
Hai tempo eu estaba a me iniciar na radio definida por software, e un dos mellores programas era software libre. Iso era xenial, porque así un podía estudar como funcionaba o programa. Pouco despois, o autor molestouse porque había xente que incluía parte del nos seus propios programas, así que cambiou a licencia a unha máis restritiva. Despois, como había xente facendo programas parecidos, o autor enfadouse porque pensaba que llo copiaban e comezou a restrinxila máis e máis. Finalmente, un día retirou o programa, a páxina web e calquera rastro da súa existencia.
Moitos programadores identifícanse cos programas que fan; ás veces identifícanse tanto que toman calquera crítica ou calquera “mal uso” que alguén faga deles coma un ataque persoal. Algúns programadores, nos casos máis graves, acaban por impoñer restricións que lle restan case toda a utilidade ao programa ou, directamente, arramplan con todo e retiran o programa completamente para que ninguén o use. Igualiño que os dragóns das mitoloxías xermánicas, que acaparaban ouro e riquezas nunha morea para se deitar por riba dela sen que eses tesouros puideran beneficiar a ninguén máis.
Non é necesario dicir que non é bo ter tanto sentido da propiedade dos programas que un fai. Se non podemos separar a nosa obra do noso ego, non habemos poder aturar que alguén a critique; e non me refiro a críticas como “ai, que malo é ese programa”, senón críticas como “se cadra o programa iría máis rápido se usara este algoritmo no canto destoutro algoritmo”, “o programa debería usar o mesmo tipo de letra que o resto do sistema operativo” ou “eu pídolle que me sume 2 e 2 e dáme 5”. Se non podemos aceptar críticas ou suxestións ou nada que non sexan louvanzas e parabéns, non imos poder mellorar como programadores.
Polo tanto, se te viches reflectido no que dixen no parágrafo anterior, recoméndoche que comeces a cultivar unha certa distancia entre ti e a túa obra. Tés que ser capaz de vela imparcialmente e poder apreciar que partes son boas, que partes son malas, e como converter as partes malas en boas.
Isto é importante sempre, pero aínda máis se traballas nun equipo, porque os outros membros do equipo van ver o todo código que ti escribas; outra xente vai modificalo de maneiras que ti non esperabas; incluso, ás veces, van borralo. Que vas facer cando alguén che envíe un push request que elimina cinco mil liñas que escribiches ti? Eu sei o que fago: dígolle que “bo traballo” e póñolle un emoji co dedo gordo apuntando para arriba. Ás veces incluso lle poño o emoji da muller bailando flamenco.
E, cando desenvolvemos software profesionalmente, iso é aínda máis importante se cabe. Nunha empresa as persoas cambian de proxecto ou de equipo, ou os proxectos pasan dun equipo a outro, e non podes levar o teu código contigo; tés que deixalo ao equipo que se vai encargar del. Hai xente que, semanas despois de cambiar de proxecto, aínda fisga no sistema de control de versións para ver que cambios fixeron no “seu” código. Que non saiba eu que facedes iso.
Eu entendo á xente que ten un investimento emocional grande nos programas que fai. Ocórrelle a moita xente que traballa en oficios creativos: artistas, artesáns, escritores, deseñadores, arquitectos, … Cando pasas moito tempo matinando como facer algo e despois toma corpo co teu esforzo, dá moitísima satisfacción. Pero igual que os artistas e os artesáns teñen que vender as súas obras e deixar que se enfronten elas soas ao mundo, os programadores temos que aprender a facer o mesmo cos nosos programas.
A ilustración desta Folla está adaptada dunha de “Siegfried e o solpor dos deuses”.
Anterior: “Tempo de proxecto” | Índice | Seguinte: “Apicade as vosas APIs” |
Coding Sheet has an English version of this article: “Software dragons”. |
1 comentario