Una hay famosa frase que dice «Nadie es profeta en su tierra» que hoy en día me resuena muy frecuentemente. Durante 10 años trabajé como consultor, mis clientes me llamaban para resolver ciertas cuestiones. En cierto modo, los equipos con los que trabajaba me venían como «el profeta» que traía «la palabra». Más allá de que nunca me sentí cómodo en ese rol, me resultaba muy curioso que en más de una ocasión mis propuestas no eran muy distintas a las que algún miembro del equipo ya había hecho. Pero claro, nadie es profeta en su tierra. Por alguna razón, si la sugerencia la viene un compañero con el que trabajas a diario, es como que la sugerencia tuviera menos valor. Pero si la sugerencia la hace alguien externo, es como si resultase de mayor valor.

Hoy en día, estoy trabajando en un equipo y me encuentro en la situación inversa a la que me encontraba antes. Propongo algo y no se le da mayor importancia, pero eso mismo lo dice un externo y es palabra santa. Pero el problema no termina aquí. Hay una gran cantidad de cuestiones (casi todas) para las que no hay un consultor externo y en esos casos me encuentro yo solito intentando convencer a mi equipo. Durísimo, en gran medida porque en el equipo somos todos «veteranos de guerra», gente con ~20 años en la profesión, cada uno con sus experiencias, mañas y gustos e intentando trabajar en un esquema bastante horizontal en lo que refiere a las decisiones técnicas.

El desafío me resulta interesante pero también desgastante y hasta frustrante por momentos. En una ocasión llegué a tener una discusión porque un colega insistía en que hacía demasiadas pruebas y que eso hacía más lento el desarrollo. Y por ello pretendía que yo escribiera menos pruebas. Yo no podía creer lo que estaba escuchando. De hecho inicialmente no lo entendí. En un momento me sentí como Fantino diciendo: «Pará pará pará, ¿vos me estas diciendo que queres que yo escriba menos pruebas?». Naturalmente al hacer TDD uno suele escribir más pruebas que cuando se agregan las pruebas a posterior, con lo cual podría decirse que es cierto «hago muchas pruebas». Pero de ninguna forma creo que eso haga más lento el desarrollo, al menos no en un grado relevante. O sea, es cierto que si hiciera menos pruebas podría llevarme menos tiempos ¿pero cuanto menos? ¿5 horas en lugar de 6? No creo que esa diferencia en tiempo justifique «romper» mi proceso. Trabajo de una forma que me da seguridad y me permite trabajar de una forma eficiente, confiable y predecible.

Menos mal que uno ya está curtido y muchas balas no le entran, porque este tipo de cuestiones no hacen más que poner en tela de juicio las aptitudes personales y podrían destruir la autoestima y motivación de gente más sensible.

Por suerte, más allá de las diferencias profesionales, es toda gente bien intencionada y hablando (casi siempre)se puede logran consenso, pero no es fácil.

En fin, esta situación me llevó a buscar ayuda, por un lado hablando con algunos colegas y por otro buscando en biblioteca donde encontré un librito muy útil aunque no muy popular: «Driven Technical Change» (de Terrence Ryan) que me dió algunas ideas que estoy probando. En un par de semanas (o meses) les cuento que tal me va.