El viernes tuve un día realmente malo en el trabajo pero creo haberlo resuelto correctamente. El caso es que aun hoy sigo dándole vueltas a lo acontecido y reflexiono sobre lo que pasó.
Resulta que el viernes a última hora, un compañero de trabajo y yo modificábamos el mismo archivo pero realizando tareas completamente distintas. Mientra él ajustaba ciertos detalles de apariencia, yo trataba de mejorar algunos aspectos del comportamiento. Mi compañero tiene la costumbre (para mí, arriesgada) de realizar un sólo envío (al finalizar la jornada) al repositorio de versiones mientras que yo suelo subir versiones estables cada menos tiempo (un par de horas o así). El caso que a eso de las 12.00h del viernes mi jefe nos pide mezclar los archivos. Para ello primero subiría los cambios mi compañero y luego yo.
Cual es mi sorpresa cuando mi compañero, abrumado y enfurecido, me pregunta que por qué he subido yo primero y me acusa de haber realizado un montón de cambios. A esto le sigue una sucesión de frases que, sin faltar al respeto en ningún momento, me tachan de soberbio, afirmando que sólo tolero el código que yo creo, que «lo de los demás no vale» y que «por eso tengo encontronazos con todo el mundo» amén de que tengo la mala costumbre de pisar el trabajo de los demás*.
(*) Este asterisco viene de una vez en la que sí metí la pata y me cargué sus cambios al desestimar un conflicto. Volver a una versión anterior y resolver la mezcla me llevó 10 minutos. Es lo bueno de los repositorios de versiones, nada se pierde.
Mi respuesta es invitarlo a comprobar que no he realizado ningún cambio reciente, que el último es de las 10.00h de la mañana y que mi trabajo también incluye la modificación de esos archivos. También le propongo mezclar yo los archivos dado que estimo que no me llevará más de 15 minutos pero él insiste en que ha cambiado demasiado y que la mezcla llevará al menos una hora. Trato de que considere que tales cambios sólo son producto de que mi editor de texto ha reemplazado los tabuladores por espacios y que por eso parece mucho más de lo que hay…
En este momento llegan mis jefes que preguntan que qué pasa. Mi compañero insiste en que he realizado un montón de cambios, que subí los cambios si cerciorame de que nadie estuviera tocando el archivo y que la mezcla durará una hora. De nuevo indico mi intención de asumir la responsabilidad y de mezclar yo dado que reconozco que no pregunté si alguien estaba usando el archivo porque, para mí, el proceso de mezcla es parte del ciclo de desarrollo. Finalmente tomo la siguiente decisión: que se desestimen mis cambios y se reemplace mi versión por la suya. Una vez hecho esto afirmo que podré reconstruir los cambios en unos 15 minutos que es lo que me llevará mezclar el código con mi versión local.
Primeramente indico al visor de diferencias que no tenga en cuenta los espacios en blanco lo que convierte los dos grandes bloques de modificaciones en algunas líneas sueltas. A continuación resuelvo la mezcla en 20 minutos. Ni más ni menos. Compruebo que mis cambios en ese archivo a penas llegan al 10% de los totales. Pero la verdad, esto ya lo sabía.
Lo que me dejó preocupado y es fuente de esta reflexión fueron las acusaciones respecto a lo de que «sólo lo mío vale». Reconozco que llevaba un cabreo mayúsculo, me dolía la cabeza y apenas podía concentrarme pero me armé de valor, me tragué el orgullo y decidí hablar con mi compañero para decirle en qué no estaba de acuerdo asi como para pedirle disculpas por el estado de preocupación al que le había llevado y dilucidar aquello referente a mi soberbia. Le dije que no era quien para juzgar mi relación con mis compañeros (dado que no he tenido ningún encontronazo con ellos) y que no entendía a qué venía eso de que «sólo lo mío vale» cuando en muchas ocasiones no sólo he estado de acuerdo con él sino que he defendido su posición.
Esto llevó al quid de la cuestión. Reveló que ya se las llevaba guardando un tiempo porque encontraba código que él había escrito, cambiado a algo que hacía lo mismo pero escrito de una manera distinta y he de reconocer que esto es totalmente cierto. Hay código que él escribía con el que yo no me sentía cómodo y cambiaba mientras trabajaba en él. Así, la pregunta es ¿tengo derecho a cambiar el código con el que estoy trabajando?
Quizá a respuesta dependa del escenario y, principalmente, de la metodología de trabajo. Con una división clara de responsabilidades, la situación no debería producirse. La representación estaría diferenciada de la funcionalidad y dado que nuestras tareas serían distintas, el código de cada cual debería presentarse invisible de cara al otro.
Ahora bien, aquí seguimos la metodología scrum y se anima a la existencia un equipo multidisciplinar: no debe haber un sentimiendo de «su trabajo y mi trabajo» sino de «nuestro trabajo». Entiendo que para esto un ideal es contar con «miembros polivalentes»: cada uno quizá experto en algo en particular pero con voluntad para asumir otro tipo de tareas no relacionadas con sus áreas directas o para identificarse con los objetivos del proyecto. Con el proyecto en sí
Esto significa que si sé de todo, no puedo tener preferencias manifiestas. No puedo rechazar un trabajo porque no es mi área o no me interese: un día toco representación, otro día comportamiento y otro algoritmia o diseño del sistema. Ahora, ¿puedo refactorizar el código que resulta ser mi trabajo en un momento dado? Parece que la respuesta obvia es «si funciona, no lo toques» pero ¿y si no estoy a gusto con mi entorno de trabajo? ¿Si me cuesta leerlo o encontrar alguna funcionalidad es obtuso?, ¿si hay redundancia innecesaria o tramos muertos de código?, ¿nombres desafortunados?, ¿fallos de concepto? No estoy diciendo que en el código de mi compañero haya nada de esto, tan sólo lo cuestiono a un nivel general. Si el código, en definitiva, está mal escrito y me resulta un engorro… ¿entonces qué? Y lo que es peor, si eso va a hacer que produzca un código del que no me siento orgulloso, ¿debería bajar mis estándares por respetar la metodología de otro?
Y para ser del todo franco, a veces sí he pensado que mis refactorizaciones resultan en un mejor código y aquí la pregunta muta y adquiere un aspecto más social y problemático: ¿estoy despreciano el trabajo de otro por llevar a cabo la refactorización? ¿Es un acto de soberbia por mi parte?
La respuesta es muy personal, toma forma analizando la intención tras nuestros actos. No os voy a mentir, a veces, al ver código de mis compañeros he pensado «¿qué m**rd* es esto?» y me he apresurado a cambiarlo convencido de que mi código era «mejor». Sin embargo, pocas veces hay nada personal en mi proceso de crítica. No pienso que fulano sea peor profesional por escribir peor código… a lo mejor no es lo suyo, cada cual tiene sus fuertes. Creo que la respuesta definitiva tiene que ver también con la predisposición personal a asumir el mismo tipo de situación. ¿Y si fuera mi código el cuestionado? ¿Cómo me sentiría al verlo cambiado por otro haciendo lo mismo?
El trabajo de uno es una cuestión muy personal, un reflejo de los ideales personales, de los mínimos de calidad, una especie de espejo del alma. Valorar el trabajo es tener amor propio. Sus autores, antes de irse a la cama y en privado, saben cuándo un trabajo les representa más o menos, cuándo han puesto más o menos esfuerzo en la labor; sin embargo, ante la crítica externa, el trabajo se convierte en una especie de hijo al que hay que proteger a toda costa. Nuestro carácter se torna defensivo, consideramos el cambio como un insulto a nuestra capacidad, como una ofensa a nuestra inteligencia y a nosotros mismos. Continuando con la metáfora, nos comportamos como esos padres que regañan al profesor por exigir a sus hijos unos cuadernos libre de faltas de ortografía.
Al término de la charla con mi compañero recibí unas disculpas también. He obtenido dos buenos resultados de mantener esa conversación y escribir todo esto:
La primera es que los problemas deben hablarse inmediatamente. Lo he puesto en práctica con mi novia durante 6 años (gracias Bea por escucharme en los buenos y malos momentos), con mi familia, con mis amigos (gracias también a todos por el apoyo prestado) y ahora, profesionalmente. Tengo la certeza de que es lo correcto.
La segunda es que, para mantenerme coherente a mis ideas, debo mostrarme abierto a la crítica y humilde en el talante. Desde que trabajo, me voy a la cama con la sensación del deber cumplido y bien cumplido, eso debería ser suficiente. Si encuentro mi código cambiado preguntaré por qué y esperaré una respuesta convincente.
El efecto colateral que encuentro es que he perdido parte de la confianza a la hora de trabajar y mezclar archivos, no quiero pisar el trabajo de nadie pero tampoco quiero demorar el mío. No me parece justo. Si le toca mezclar a otro, que lo haga, yo estoy dispuesto a ayudar cuanot esté en mi mano… Pero como no hay mal que por bien no venga, ahora me fijo muchísimo más en las mezclas. x)
1º pide perdón por el tocho xD
La verdad es que depende mucho del tipo de proyecto, la cantidad de gente implicada, del método a seguir… para poder tocar más o menos el código de otro. Me explico: en un equipo grande muchas veces se toma el trabajo de los demás como una caja negra, o casi, muchas veces por el tamaño del código en sí. Pero en un equipo pequeño, donde el código es manejable, yo creo que tienes todo el derecho del mundo (ojo, habrá gente que diga que ese trabajo ya estaba hecho, y que puedes estar perdiendo el tiempo cambiando cosas que no funcionan, pero como tu dices, que un código gane en claridad hace ganar tiempo para todos) a hacer cambios.
Si yo un día hago un código, tu lo mejoras en algún aspecto, y yo lo veo, puedo sentirme de varias formas. Puedo sentirme ofendido (como inicialmente el caso de tu compañero) porque pienso que no se respeta lo que hago. Puedo sentirme indiferente (me la pela, me pagan xD). O puedo aprender y hablar contigo, a lo mejor la forma de resolver un problema no ha cambiado, sólo un poco la estructura, lo has podido hacer más elegante, etc
Y obviamente esta última manera creo que es la correcta, y yo creo que de hecho es lo que haces tú.
Para terminar, piensa en gente que hace commits con –overwrite y se la pela todo xDDDDDDDDDDD esos son el verdadero problema
Perdón por el tocho. jeje.
El tiempo es un buen factor de decisión. Si el código funciona y la refactorización te impide realizar tus labores quizá no sea el momento de refactorizar… es un buen punto de vista. A tener en cuenta. Gracias por el feedback.
Bueno cielo, yo no puedo ayudar mucho aquí porque no he trabajado nunca en este tipo de trabajos. De todas formas, creo que la clave de todo está en que el que está orgulloso de su trabajo lo va a defender por esto mismo. Es correcto que ambos defendáis vuestro trabajo, y también es correcto que lo hayáis hablado para concretar esto.
Eso sí, yo no tendría miedo al mezclar archivos si sabes reponerlos con un daño inexistente. Faltaría más, hombre.
Además, ya sabes que estoy aquí para que me lo cuentes cuando quieras y te daré mi opinión lo mejor que pueda (y sepa). ^^
¡Besitos!
IMHO cambiar el código de otro sin decir nada está feo. Vería mucho más positivo que si un compañero considera que mi código se puede hacer mejor de otra manera, me lo diga y me explique/convenza de que es así, y entonces se cambia si es necesario. De nada sirve que vayan cambiando tu código si tú no aprendes de ello para ponerlo en práctica y no repetir fallos en el futuro.
Parece que la crítica constructiva está deprecada (también es cierto que mucha gente no sabe decir las cosas con tacto y a otros no les gusta asumir que su código no es perfecto y aún tienen mucho que aprender)
¡Hola Diana!
Es justo lo que ando haciendo ahora. Hablo cualquier cambio que quiero efectuar, le planteo por qué creo que es mejor pero sólo lo hago cuando detecto algún problema crítico.
Creo que así nos va mejor y no parece molestarle.
Sobre lo de decir las cosas con tacto… puede ser, sólo que a veces prefiero que me suelten el bofetón claro que no cuarenta pellizquitos poco concretos. Con que me lo digan con educación, en principio, podremos discutirlo tranquilamente pero quiero saber cuál es exactamente el tema de la discusión. Sin rodeos, vamos.
Hola amigo interesante blog muy bueno la verdad pero en
«Del amor propio a la obsesión por lo que es mío»
No estoy de acuerdo contigo me parece que eres una persona de mas soberbia eso de andar borrando y modificando código a tu gusto solo por que tu piensas que es mejor es bastante egoísta, la verdad no se que tipo de proyecto tengas en mano pero si trabajas en «equipo» para alguna empresas, te tienes que comunicar con tus compañeros y ver que es lo mejor para el proyecto pero ese es el problema como bien tu dices
«al ver código de mis compañeros he pensado “¿qué m**rd* es esto?”»
eres de esas personas que solo lo que tu haces esta bien y que todo lo que hacen tus compañeros es solo para corregirlo
deberías de pensarlo bien ese trabajo donde estas no es lo tullo tu deberías de tener un cargo como jefe del proyecto ya que así podrías hacer el proyecto a tu gusto
y bueno seria genial así harías todo a como tu piensas y ni hablar de que tengas algún equipo de trabajo por que nunca serán suficientemente buenos ti
Te recomiendo que reflexiones
Bueno, es que, precisamente, el articulo es una autocritica.
Creo que primero hay que pasar por esto para luego llegar a ser un buen jefe de proyecto. No se nace con la razon sobre los hombros.