Pull Requests y otras herramientas de controlPull Requests and other control tools
Desde hace tiempo es recurrente el debate acerca de las Pull Requests en nuestro sector. Espero que sea sólo mi impresión, pero me parece que es la forma de trabajo que se ha impuesto en proyectos y empresas de todo tipo. Y es que, habiendo trabajado con y sin ellas, reconozco que es una forma de trabajo a la que veo muchos inconvenientes y me preocupan sus consecuencias a largo plazo.
Tengo la sensación de que, los que llevamos más tiempo en el mundo del desarrollo, hemos cambiado las normas del juego cuando a nosotros nos ha interesado. Cuando contábamos con más experiencia, lo que nos colocaba como gente más fiable a la hora de revisar, hemos decidido adoptar un sistema en el que se debe revisar todo el código que se escribe en el equipo. Y yo me pregunto:
- ¿Hasta qué punto esto responde a una estrategia de control y no de trabajo colaborativo?
- ¿A cuántos de nosotros nos han revisado cada línea de código que escribíamos cuando estábamos empezando?
- ¿Qué hubiera pasado si así fuera? ¿Nos hubiera ayudado a mejorar antes? ¿O hubiera causado el efecto contrario, frustrándonos, quitándonos la confianza y afectándonos profesionalmente?
Seguramente dependería de quién nos hubiéramos encontrado por el camino pero, personalmente, me da miedo poner esa responsabilidad en una fuente externa. Porque el error es el mejor de los maestros y más aún cuando el que te das cuenta del error eres tú mismo a través de las consecuencias. Porque en nuestra profesión, que tiene gran parte de creatividad, no hay una única manera de hacer las cosas y puede ser perjudicial imponer una visión por encima del resto. Porque la calidad es iterativa e intentar verlo de otro modo tiene una gran parte de ingenuidad y puede impactar en el producto/proyecto y en las personas que trabajan en él.
Además hemos tomado esta decisión cuando aún, por desgracia, no hemos avanzado en una de nuestras tareas pendientes que es la de dar feedback. Nos hemos puesto a dar feedback por escrito y en asíncrono, lo cual lo hace mucho más difícil, sin haber aprendido, practicado y sin haberlo recibido antes nosotros, sobre personas que están empezando y lo que necesitan son cercanía, guía y confianza.
También me resulta curioso cuando la gente habla de que las alternativas a las Pull Requests como el pair programming o mob programming son idealistas o irrealizables. Yo me pregunto, ¿en qué momento dejamos de considerar como una opción válida no ponernos a vigilar y corregir cada línea de código que hace otra persona?
Mis primeros años como desarrollador
Creo que no seré el único de los que llevamos más tiempo programando a los que les cuesta acordarse de un momento en sus primeros años de profesión en los que revisaran su código. Los momentos en los que alguien miraba mi código eran momentos de transferencia de conocimiento, al entrar en una empresa principalmente, momentos en los que estaba atascado y pedía ayuda, o momentos en los que quería enseñar o me querían enseñar una funcionalidad importante o relevante para el equipo.
Al ser momentos más espaciados los sentía como enormemente valiosos. Estaba deseoso de absorber todo el conocimiento que pudiera, y la otra persona también se dedicaba al 100% a mostrar todo aquello que le parecía importante. Eran momentos que venían después de aprendizajes, de caer en errores y frustraciones, que los hacían mucho más provechosos al haber sufrido las consecuencias de los errores y tener tiempo para digerirlo y aplicarlo.
¿Hice código de baja calidad? Por supuesto. Y me fui pegando con él, aprendiendo, mejorándolo, buscando conocimientos que me faltaban, viendo las cosas que funcionaban y las que no para crecer como desarrollador. Y llegué a la conclusión de la importancia del código limpio, de los tests y de muchas otras buenas prácticas, por mí mismo y de una forma que nunca voy a olvidar. No digo que esa sea la única forma válida, pero creo que viene bien la reflexión de cuáles son las consecuencias de los flujos de Pull Requests para la gente que está empezando, de imponer todas estas enseñanzas desde fuera y de un modo tan acelerado.
Mi quiero y no puedo con las Pull Requests
En la anterior empresa en la que trabajé me sentía muy identificado con el proyecto en el que participaba. Entré en la empresa cuando había sólo un prototipo y me involucré totalmente para convertirlo en un producto, aplicando todos los conocimientos que tenía en ese momento e intentando asegurarme de que fuera un producto de calidad, lo que me llevó a liderarlo.
Definimos la arquitectura de manera modular, teníamos análisis estático de código, una cobertura de tests alta, y un CI con pruebas de sistema que se corrían cada noche para asegurar que todo seguía funcionando. Seguro que habría cosas que mejorar, pero a mí me parecía increíble y me sentía orgulloso y responsable de ello.
En ese momento otro de los equipos de la empresa empezaba a trabajar con el flujo de Pull Requests y yo tenía muchas ganas de implantarlo. No tuve tiempo, y me alegro de ello porque casi seguro que lo hubiera utilizado como mecanismo de control de un producto que sentía mío y me hubiera portado como un gilipollas con mis compañeros.
Con el producto más asentado entró una persona nueva al equipo que venía directamente desde la universidad. Creo que por mi forma de ser (me identifico mucho con la gente que entra a trabajar ya que me parece uno de los momentos profesionales más duros que hay) siempre he estado muy pendiente de los compañeros que se incorporan a mi equipo. En este caso, al ser más junior y liderar yo el producto, me sentí aún más en la obligación de ayudarle, mentorizarle y guiarle en lo que pudiera para que conociera el producto y por qué era importante seguir los estándares de calidad que nos habíamos marcado.
Un tiempo después, tuve que alejarme del código para ocuparme de otras tareas y mi compañero tuvo que responsabilizarse de varias funcionalidades importantes. Al volver a centrarme en desarrollar, reconozco que vi algunas cosas que no me gustaron y me arrepentí de no haber sacado el tiempo para implantar el flujo de Pull Requests. Nos juntamos, lo comentamos y fuimos mejorando juntos el código que podía tener algún problema.
Volví a tener que alejarme un poco más del código y al volver me di cuenta de que ese mismo compañero había conseguido sacar funcionalidades muy complejas con una alta calidad. No fue magia. Fue dedicación y, sobre todo, fue confianza. Confianza en que cualquier persona es capaz de crecer sin la necesidad de tener siempre a alguien corrigiéndole. También de reconocer que tu forma de hacer las cosas no es la única válida y que la calidad es iterativa.
Con la perspectiva del tiempo me alegro mucho de no haber tenido el tiempo para implantar el flujo de trabajo de Pull Requests en este proyecto. Siendo síncero, en muchos momentos no hubiera tenido el tiempo suficiente para hacer una revisión en profundidad y hubiera bloqueado el trabajo de todo el equipo. No hubiera permitido fallar a una persona sin experiencia y no le hubiera visto crecer tanto como lo hizo en ese tiempo. Me hubiera sentido dueño de un código que era de todos. Y además, hubiera creado una dependencia que se hubiera vuelto contra todos, yo incluido, cuando decidí terminar esta etapa.
Conclusiones
Las Pull Requests son un mecanismo más a la hora de trabajar en equipo, que es útil para aceptar colaboraciones externas de personas menos familiarizadas con la base de código, como los proyectos open-source desde las que nacieron, pero que no termino de encajar en el día a día de un equipo. Pueden ser utilizadas para dar seguridad a personas que comienzan o entran en el equipo, pero el objetivo debería ser dejar de necesitarlas, no hacernos más dependientes de ellas.
Y es que, en muchos casos, los flujos de Pull Requests ocultan una necesidad de control. Desarrolladores con más experiencias nos hemos colocado como maestros del bien y del mal y hemos privado a otros desarrolladores con menos experiencia de descubrir por si mismos las mejores formas de desarrollar software. Hemos impuesto nuestra visión en un trabajo muy subjetivo, con revisiones a las que normalmente no podemos dedicar el tiempo suficiente, y que muchas veces pecan de ser demasiado caprichosas y aleatorias. Les bloqueamos constantemente, les hacemos dependientes y no les permitimos sentirse productivos en su trabajo y ganar confianza en si mismos, para también aportar sus propias ideas. Además, estamos tan centrados en ellas que muchas veces nos olvidamos de dedicar esfuerzos en sistemas de integración contínua, análisis estático del código y formación, mucho más útiles e importantes para un equipo.
No digo que haya casos en los que aplicarlo y formas positivas de trabajar con ellas, pero creo que conviene recalcar que un flujo de Pull Request:
- No da seguridad, ya que es difícil que revisando detectemos un error en el código.
- No da consistencia, ya que su contexto está muy limitado al código que estamos cambiando.
- No forma, ya que difícilmente conseguiremos enseñar o convencer a una persona con un simple comentario en su código.
- No es la única forma de hacer revisiones de código, ni mucho menos la mejor.
Por ello creo que los flujo de Pull Requests distan mucho de ser el estándar que aplicar a todos los proyectos y equipos, y que, al menos, es necesaria una reflexión más profunda de por qué y cómo los usamos.
The debate around Pull Requests in our industry has been recurring for a while now. I hope it's just my impression, but it seems to me that this has become the dominant way of working in projects and companies of all kinds. And having worked both with and without them, I admit it's a way of working I see plenty of drawbacks to, and I'm worried about its long-term consequences.
I have the feeling that those of us who've been in software development longer have changed the rules of the game whenever it suited us. Once we'd gained more experience — which positioned us as more trustworthy reviewers — we decided to adopt a system in which all the code written by the team must be reviewed. And I ask myself:
- To what extent is this a control strategy rather than collaborative work?
- How many of us had every single line of code we wrote reviewed when we were starting out?
- What would have happened if that had been the case? Would it have helped us improve sooner? Or would it have had the opposite effect — frustrating us, eroding our confidence and affecting us professionally?
It would surely depend on who we crossed paths with along the way but, personally, it scares me to place that responsibility in an external source. Because the mistake is the best of teachers, all the more so when the one who realizes the mistake is you yourself, through its consequences. Because in our profession, which has a large creative component, there isn't a single way of doing things, and it can be harmful to impose one vision above all the rest. Because quality is iterative, and trying to see it any other way is largely naive and can impact the product/project and the people working on it.
What's more, we've made this decision when, unfortunately, we still haven't made progress on one of our pending tasks: giving feedback. We've started giving feedback in writing and asynchronously — which makes it much harder — without having learned it, practiced it, or received it ourselves first, and on people who are just starting out and who need closeness, guidance and trust.
I also find it curious when people say that alternatives to Pull Requests like pair programming or mob programming are idealistic or unworkable. I ask myself, at what point did we stop considering it a valid option not to police and correct every line of code someone else writes?
My early years as a developer
I don't think I'll be the only one among those of us who've been programming longer who struggles to recall a moment in their early years in the profession when their code was reviewed. The moments when someone looked at my code were moments of knowledge transfer — mainly when joining a company — moments when I was stuck and asked for help, or moments when I wanted to show, or was being shown, an important or relevant feature for the team.
Being more spaced out, those moments felt enormously valuable. I was eager to absorb all the knowledge I could, and the other person also dedicated themselves 100% to showing everything they considered important. They were moments that came after learning, after falling into mistakes and frustrations, which made them far more rewarding because I'd suffered the consequences of those mistakes and had time to digest and apply it.
Did I write low-quality code? Of course. And I wrestled with it, learning, improving it, seeking out the knowledge I lacked, seeing what worked and what didn't in order to grow as a developer. And I reached the conclusion about the importance of clean code, of tests and of many other good practices on my own, and in a way I'll never forget. I'm not saying that's the only valid way, but I think it's worth reflecting on the consequences of Pull Request workflows for people who are just starting out — of imposing all these lessons from the outside and in such an accelerated way.
My love-hate relationship with Pull Requests
At the previous company where I worked, I felt very identified with the project I was part of. I joined the company when there was only a prototype, and I got fully involved in turning it into a product, applying all the knowledge I had at the time and trying to make sure it was a quality product — which led me to lead it.
We defined the architecture in a modular way, we had static code analysis, high test coverage, and a CI with system tests that ran every night to ensure everything kept working. There were surely things to improve, but to me it seemed incredible and I felt proud of and responsible for it.
At that time another of the company's teams was starting to work with the Pull Request workflow, and I was really keen to adopt it. I didn't have time, and I'm glad I didn't, because I'd almost certainly have used it as a control mechanism over a product I felt was mine, and I'd have behaved like an asshole toward my colleagues.
With the product more settled, a new person joined the team straight out of university. I think because of who I am (I identify a lot with people who are starting a job, since I think it's one of the hardest professional moments there is) I've always been very attentive to the colleagues joining my team. In this case, being more junior and with me leading the product, I felt even more obligated to help him, mentor him and guide him however I could so he'd get to know the product and why it was important to follow the quality standards we'd set ourselves.
Some time later, I had to step away from the code to take care of other tasks, and my colleague had to take responsibility for several important features. When I came back to focus on development, I admit I saw some things I didn't like, and I regretted not having found the time to adopt the Pull Request workflow. We got together, talked it over, and improved the code that might have had some issue together.
I had to step away from the code a bit longer again, and when I came back I realized that this same colleague had managed to ship very complex features with high quality. It wasn't magic. It was dedication and, above all, it was trust. Trust that anyone is capable of growing without always needing someone correcting them. Also recognizing that your way of doing things isn't the only valid one, and that quality is iterative.
With the perspective of time, I'm very glad I didn't have the time to adopt the Pull Request workflow on this project. To be honest, at many moments I wouldn't have had enough time to do an in-depth review and would have blocked the whole team's work. I wouldn't have allowed an inexperienced person to fail, and I wouldn't have seen him grow as much as he did in that time. I'd have felt like the owner of code that belonged to everyone. And on top of that, I'd have created a dependency that would have turned against everyone, myself included, when I decided to end this stage.
Conclusions
Pull Requests are just one more mechanism for working as a team, useful for accepting external contributions from people less familiar with the codebase — like the open-source projects they were born from — but one that I can't quite fit into a team's day-to-day. They can be used to give security to people who are starting out or joining the team, but the goal should be to stop needing them, not to make ourselves more dependent on them.
The thing is, in many cases, Pull Request workflows conceal a need for control. More experienced developers have set ourselves up as the masters of good and evil, and we've deprived other, less experienced developers of discovering for themselves the best ways to develop software. We've imposed our vision on highly subjective work, with reviews we usually can't devote enough time to, and which often err on the side of being too capricious and arbitrary. We constantly block them, we make them dependent, and we don't let them feel productive in their work and gain confidence in themselves, so they can also contribute their own ideas. What's more, we're so focused on them that we often forget to put effort into continuous integration systems, static code analysis and training — far more useful and important for a team.
I'm not saying there aren't cases where it applies and positive ways to work with them, but I think it's worth stressing that a Pull Request workflow:
- Doesn't provide security, since it's hard to detect a bug in the code through review.
- Doesn't provide consistency, since its context is very limited to the code we're changing.
- Doesn't train, since we'll hardly manage to teach or convince someone with a simple comment on their code.
- Isn't the only way to do code reviews, much less the best one.
That's why I think Pull Request workflows are far from being the standard to apply to every project and team, and that, at the very least, a deeper reflection on why and how we use them is needed.