Para el que no sepa que es una pull request (enlace), se da cuando un desarrollador/a solicita que su trabajo (código fuente) sea revisado para ser integrado en una base de código mayor común.

Si esto es algo nuevo para ti, que la terminología no te haga pensar que no tiene nada que ver contigo. Lo tiene.

Al fin y al cabo una pull request (PR) requiere mostrar tu trabajo a los demás, exponiéndote a las críticas. Esto, en cualquier profesión, puede ser un momento MUY angustioso.

Basándome en mi experiencia, aquí van algunos consejos para hacer la situación más llevadera y —quién sabe— conseguir que incluso la disfrutes. Vamos allá.

No le des más importancia de la que tiene

Déjame comenzar recordándote varias cosas: esto no es el fin del mundo. Es normal estar nervioso/a. Todos/as hemos pasado por aquí. Tras esta PR vendrán más. Por último, poco a poco, irás aprendiendo a desenvolverte con soltura. Garantizado.

Como profesional, esto es lo mejor que te puede pasar. Me refiero a exponer tu trabajo a perspectivas diferentes a la tuya. Es duro —sí— pero necesario. Es aprender al cubo, ya lo verás.

Lo más importante es que te hayas esforzado de verdad, haciéndolo lo mejor que sepas. Esa seguridad interior es lo que te permitiría aceptar críticas y crecer gracias a ellas.

Sé humilde. Siempre.

De nada sirve que intentes aparentar saber lo que no sabes. Cualquiera que lleve algún tiempo en el mundillo se dará cuenta a la primera de que eres un farsante y que careces de lo único que se necesita para aprender: reconocer que desconoces.

Eso es comenzar con mal pie.

Cuando alguien te haga una sugerencia o, directamente, solicite que cambies algo, recuerda que estás aquí para aprender.

Recuerda también que esta es una oportunidad de oro para hacerlo (aprender) de alguien que tiene más experiencia que tú. Así que demuestra el agradecimiento necesario.

Por otro lado quizás pienses que más adelante la humildad se vuelve innecesaria. Error. De hecho es más necesaria que nunca. La soberbia y la edad suelen ir de la mano y son una combinación tóxica.

Recuerda que siempre hay y habrá alguien que sepa más que tú. Una actitud respetuosa y considerada —sobre todo con quien sabe menos—, aunque no te lo creas, es una de las ventajas competitivas más poderosas que existe.

Obtén todos los puntos de vista posibles

Cuando estés creando la PR sé que es tentador añadir a la menor cantidad de reviewers posible. Quizás solo a tus compañeros de equipo. ”Cuantos menos ojos mejor”, ¿verdad?.

Nuevo error.

No intentes minimizar la exposición. Al contrario: busca añadir a todo aquel que tenga contexto sobre la superficie a la que tu trabajo afecta. Si usas GitHub, aparecerán los nombres de las personas relacionadas de forma automática. Sobra decir que debes añadirlos, ya que ellos/as podrán valorar de forma más efectiva tu trabajo.

Aporta todo el contexto que puedas

Debes ponerte en el lugar de las personas que revisarán tu código. Con toda seguridad —igual que tú— son personas ocupadas. Teniendo esto en cuenta, hazles el proceso lo más sencillo posible.

Escribe un buen enunciado. Describe lo que has hecho y por qué lo has hecho. Adjunta tareas y cualquier recurso que añada valor. Incluso (esto lo hago de vez en cuando) graba un pequeño screencast de dos o tres minutos haciendo un tour de lo que has hecho y explicando las partes más importantes.

Cuando seas tú el que tenga que revisar una PR, créeme, lo agradecerás.

Sé proactivo/a

Por otro lado, intenta responder comentarios y peticiones lo antes posible. Nadie te pide que uses GitHub en tiempo real como si fuese Slack, pero tampoco dejes pasar días y días entre cada interacción.

De igual forma, cuando tú seas el reviewer de una PR, trata de realizar el proceso o al menos echar un vistazo el mismo en el que se te ha solicitado.

La clave aquí es mantenerse proactivo/a durante todo el proceso —sin importar en qué lado estés— para hacerlo lo más ágil posible.

Extra

Aunque lo he dejado para el final, ahí va una regla de oro que debes recordar siempre y que no solo vale para una PR sino para cualquier ámbito en la vida

Nunca eclipses a tu maestro/a.

A pesar de que a algunos/as se les llene la boca al hablar de estructuras planas (flat structures), no te confundas: siempre hay alguien al mando. Alguien que decide.

Alguien que está por encima de ti.

Ubícate cuanto antes y aprende cuál es tu lugar en la jerarquía (no el que te han dicho, no el que tú crees, ni el que querrías, sino el de verdad) y, por supuesto, no intentes corregir, sobre todo públicamente, a los que están por encima de ti. No todavía, al menos.

Entiende esto: todas las personas sin excepción tienen su ego e inseguridades. No confundas nunca una actitud tolerante con sumisión ni un intercambio de emojis con amistad.

No en vano, esta es la primera regla de Las 48 Leyes de Poder de Robert Greene (enlace).

Como él mismo dice: olvídala bajo tu propia responsabilidad.

La historia está llena de las tragedias personales de aquellos que lo hicieron.