Hace unos días estuve en la CommitConf dando una charla sobre «Estrategias branching: trabajando con git y personas» y aquí os cuento un poco la experiencia de preparar una charla, ponerte delante de gente y recibir feedback.
¿Cómo fue el proceso?
A mediados de Abril se abrió el «Call for Papers» y me animé a enviar dos propuestas de charlas: una charla sobre refactoring que finalmente no fue escogida y otra sobre estrategias de branching.
Todos conocemos Git. Sabemos hacer commit, hacer pull y push. Pero y cuando trabajamos en un equipo ¿como lo hacemos?
propuesta de la charla Estrategias branching: trabajando con git y personas
Hay estrategias de branching como GitFlow, Trunk based, environment Based,… al final lo que termina pasando es cuando las ramas son grandes acabamos haciendo carreras por ser el primero en hacer merge para que los conflictos sean para otro. En esta charla veremos algunas estrategias de branching como trunk based, environment branch (una rama por entorno) y como son las mejores maneras de hacer trabajar con git y las ramas sin que eso sea un caos
Mi idea era dar una charla de iniciación: que son las estrategias de branching, porqué no es necesario saber muchísimo de git para usar una, contar distintas estrategias y ejemplos reales de como trabajamos con distintas estrategias para conseguir objetivos de negocio y que es lo que nos ha servido a la hora de trabajar con ramas. Pero no tenía nada más allá de unos pocos artículos en el blog: Estrategias de branching – No solo existe git-flow, Una buena manera de afrontar la ramificación (branching) en Git, ¿Qué hacemos para mejorar como equipo?, equipos, Intentando hacer buenos commits, Consejos y trucos en Git,
Total que en Agosto me llevo una alegría que no me esperaba. Mi propuesta sobre «Estrategias branching: trabajando con git y personas» había sido seleccionada. Ahora venía lo divertido… buscar un poco más de información sobre estrategias de branching, como implementarlas, conversaciones de Twitter para analizar como estaba el tema, etc. Poco a poco fui recopilando enlaces para tenerlo todo a mano (aquí los comparto) y poder armar la presentación
Con la presentación más o menos lista ya tenía el 30% del trabajo, ahora quedaba ensayar. Gracias a la ayuda de Sevilla Java User Group (SVQJUG) pude hacer un ensayo delante de público donde me dieron feedback sobre como mejorar la presentación y además pudimos compartir una conversación muy interesante al final.
La charla
Llegan los 2 días de la CommitConf y por suerte mi charla era el primer día y de las primeras. Con lo que fue justo llegar, hacer el checkin, saludar a los compañeros de coches.com y subirme al escenario.
Ya sabía que me tocaba una sala grande (en los días previos se podía votar por las charlas para adecuar el aforo) y además que se retransmitiría por Youtube. Y llegó el día. Llevaba mi Mac con la presentación y un montón de nervios encima.
De la charla recuerdo los nervios pero con una sonrisa. Fue una gran experiencia, no solo por lo que aprendí preparándola, ensayándola y presentándola. Sino por lo mucho que me queda por mejorar.
Commitconf
Después de la charla pude disfrutar del resto de charlas. Para tener un poco de contexto Commitconf es una conferencia gigante: 9 tracks simultáneos + 2 talleres + este año una sala para unconferences. Mucha gente (es impresionante como la organización monta tan bien un sarao tan grande), muchos temas molones en las charlas y muchas ganas de reencontrarme a compañeros y amigos ahora que ya no vivo por Madrid.
Intenté ir sobre todo unconferences porque nos se graban y al ser un dialogo entre todas las personas de la sala podías preguntar, comentar y ver ejemplos de situaciones reales. Me dio tiempo a pasarme por IndieMad para jugar un poco a algunos videojuegos y bajar a la sala de relax para jugar al futbolin.
Feedback
La charla era de iniciación, pero creo que demasiado beginner. No supe adecuarme bien al público que había, estaba muy nervioso y no encontré ese «clic» para que la charla enganchase. Aunque gracias a todo el feedback, tanto el recibido a través de la plataforma de la commitconf, como hablando con la gente después, DM de Twitter,… se que tengo que darle una vuelta y me llevo un montón de consejos y aprendizajes para la próxima.
Por un lado, es cierto que al principio no mola recibir malas puntuaciones, porque te has currado la charla. Pero por otro lado, si no te dicen que tienes que mejorar, como hacerlo mejor, o como contar la idea de otra forma, es muy difícil seguir creciendo y mejorando. Al final el público que va a la Commitconf ha pagado una entrada y tiene «derecho» a recibir un contenido de calidad y si no lo recibe puede comentarlo.
De un modo un otro ponerse delante de público para dar una charla es exponerse y puede que recibamos comentarios que no terminan de agradar, pero todo eso te sirve (o al menos a mi) para hacerte un poco más fuerte, para dar un paso más y seguir mejorando .Lo que digas puede gustar a veces y otras no, por eso hay que saber afrontar esos comentarios, aprender y mejorar para la próxima charla.
Eso sí, hemos hablado de recibir feedback algo para lo que hay que estar preparado. Pero también hay que saber dar feedback, porque puede ser disuasorio, herir, o no ser bien interpretado. Por eso os dejo una serie de post y de hilos de twitter super interesantes:
- Laura Lacarra da unos buenísimos consejos sobre como dar feedback de calidad: https://softwareyotrasdesvirtudes.com/2018/11/26/no-todo-el-mundo-sabe-o-debe-dar-feedback/
- Hilazo de Twitter: https://twitter.com/LauraLacarra/status/1067069308256305154
- Los datos de las votaciones de la Commitconf: https://gist.github.com/jabadia/aa859765f7da324ccf882a008ae13baa
- Un hilo de Jorge https://twitter.com/flipper83/status/1067047424844288000