🧵 Me pide Manu que explique por qué creo que trabajar con Pull Requests bloqueantes se ha convertido en cargo cult.
Los motivos principales son 2:
1. Todos llevamos un pequeño gatekeeper dentro
2. Promueve un modo de trabajo fácil a corto plazo
x.com/evrtrabajo/status/1723276848883196341?s=20
1️⃣ Todos llevamos un pequeño gatekeeper controlador dentro.
Nos decimos a nosotros mismos que es por la calidad del código. Por la deuda técnica. Que hay que hacer revisiones.
Pero luego todos sabemos la calidad de código y deuda técnica que hay en nuestros repos
Sí, claro que hay que hacer revisiones. Pero hay muchos tipos de revisiones y momentos para hacerlas.
Bloquear todo por defecto durante horas o días por un feedback que la mayoría de veces no corrige bugs es super inefectivo.
Dejemos que el dev sea responsable de decidir qué revisiones necesita. Incluido las bloqueantes.
Si el código funciona, no hay por qué bloquearlo por defecto. Esos cambios se pueden hacer después. No tiene ni por qué hacerlos la misma persona
Si de verdad nos preocupa la calidad del código hay herramientas que son mucho más efectivas:
- Análisis de código estático
- Tests
- Refactoring continuo
Entonces, si las pull requests bloqueantes no son efectivas. Si la calidad de nuestro código sigue siendo deficiente aunque pongamos 2 aprobaciones obligatorias. Por qué lo hacemos?
Porque nos da una falsa sensación de control
2️⃣ Promueve un modo de trabajo fácil a corto plazo.
Empiezo un ticket, programo aislado durante días en mi rama, me dan un OK, cierro ticket.
Una vez cerrado, si pasa algo, digo que yo hice lo que ponía el ticket y si eso que me abran otro ticket.
A quién no le va a gustar?
Este modo de trabajar promueve que el dev se convierta en un mero despachador de tickets. De nuevo, le quitamos responsabilidad y con ello, frenamos su iniciativa.
Pero además sabemos que no funciona.
En los proyectos que van mal siempre escuchas la misma queja: los devs no tienen iniciativa.
No la tienen porque no lo estás promoviendo. Se la has cortado desde el principio.
El trabajo de un dev debe ser resolver problemas llevando software a Producción. No resolver tickets
Es un trabajo más complicado, que requiere mucha más colaboración con personas, implicación y momentos incómodos.
Pero es el trabajo que funciona
Y esto de forma resumida sería todo. Espero que a Manu le haya gustado.
Tenemos ego, falsa sensación de control y comodidad como incentivos.
Era fácil que se convirtiera en cargo cult.
Lo difícil es cambiarlo