Hace algo más de un año comencé a trabajar en Pivotal, una empresa donde no he dejado de aprender desde el día uno. A finales de 2016, tras descubrir la web We Do TDD (una gran iniciativa) y unirme al canal de Slack, se me ofreció la posibilidad de ser entrevistado para describir la forma en que trabajamos, cómo utilizamos TDD, etc. Acepté en paralelo al mismo tiempo que un compañero de Berlín (Oleksii, más conocido como That TDD Fellow), por lo que decidimos hacer la entrevista conjunta, cosa que, por otra parte, encaja bastante bien con la cultura de nuestra empresa, donde el pair programming es una constante.
Esta semana hará tres meses que inicié mi andadura como Anchor en un proyecto de mi empresa. Diría que la experiencia está siendo muy buena en todos los sentidos, y me está sirviendo para aprender un montón de cosas. Quizás la más importante de todas ellas sea como gestionar la comunicación dentro de un equipo de forma eficiente, y en este post voy a repasar muchas de las conclusiones que he ido sacando en claro.
El libro me lo recomendaron en el foro interno de mi empresa, como guía para enfocar correctamente el nuevo rol que me ha tocado este año, pero una vez finalizado, me atrevo a decir que más que una guía para Technical Leaders es un playbook para que un programador con algo de experiencia (pongamos un par de años) sepa encarrilar los siguientes pasos de su carrera.
Dejamos nuestro repositorio en el siguiente estado:
.
└── hello.txt
Es decir, un directorio con un fichero hello.txt, fichero que contiene el texto “Hello World”. Tras hacer nuestro primer commit y añadir un tag, nos quedó la siguiente estructura interna:
