learning-front

Nivel 12 · Cómo es el trabajo de verdad

Soft skills

Lo que ningún linter detecta y más decide si trabajas bien en equipo: escribir para que te lean, comunicación asíncrona, una buena descripción de PR, code review con respeto, dar y recibir feedback con SBI y pedir ayuda bien. Sin autoayuda: cada habilidad con su par mal/bien.

El capítulo anterior cerró con una idea: el ownership casi siempre se nota en cómo te comunicas —cómo levantas un bloqueo, cómo dices que algo no cuadra, cómo dejas escrito por qué hiciste algo—. Esa capa es la de las soft skills: lo que ningún linter detecta y, sin embargo, lo que más decide si trabajas bien en equipo. Un desarrollador técnicamente brillante con quien nadie quiere trabajar rinde menos, en la práctica, que uno correcto que comunica de maravilla.

La palabra “soft skills” arrastra fama de charla motivacional, así que aquí no va a haber nada de eso. Cada habilidad viene con un par mal/bien concreto, porque “comunica mejor” no se aprende como consejo, se aprende viendo la diferencia.

Escribir para que te lean#

La habilidad base, de la que cuelgan casi todas las demás: escribir claro. En un equipo —y más en remoto— la mayor parte de tu comunicación es escrita: PRs, tickets, mensajes, documentos. Y la lee gente que no está contigo en ese momento.

text
MAL:  "oye una cosa del filtro, ¿lo miramos?"
BIEN: "En TB-42 (filtro por rol), dudo si al desactivar el filtro debe
       recordarse el último rol o resetear. ¿Cómo lo ves? Yo tiraría por
       resetear, que es lo que espera el usuario."

El primero obliga a una conversación entera para sacar lo que el segundo dice de una. ¿Y qué? Si escribes claro, el equipo actúa sin pararse a preguntarte; si escribes en clave, generas trabajo de ida y vuelta para todos. Escribir bien no es estilo: es engrasar el equipo.

Comunicación asíncrona#

Lo anterior se vuelve crítico en asíncrono, que es como funcionan los equipos modernos: te comunicas por escrito y el otro lo lee cuando puede, quizá en otra franja horaria. La regla de oro del mensaje asíncrono es que se pueda responder en un solo turno: incluye el contexto, lo que necesitas y, si aplica, qué harás mientras.

text
MAL:  "¿el endpoint de héroes está listo?"
BIEN: "Para cerrar TB-42 necesito el endpoint de héroes. ¿Está en staging?
       Si no, ¿una fecha aproximada? Mientras, sigo con la UI para no pararme."

El mensaje malo parece más corto, pero arranca un ping-pong: “¿para qué?”, “¿staging o prod?”, “¿y mientras?”. ¿Y qué? En asíncrono, cada vuelta es una espera que puede ser de horas. El mensaje bueno cuesta treinta segundos más y ahorra medio día, porque trae todo lo necesario para una respuesta única. Y, como hábito por defecto, escribir asíncrono gana al “¿tienes un momento?”: no interrumpe a quien está concentrado y deja registro consultable para el siguiente con la misma duda.

La descripción de un Pull Request#

Un Pull Request no es solo código: es comunicación hacia tu revisor. La descripción es donde le explicas qué va a leer. Una buena descripción responde tres cosas: qué cambia, por qué, y cómo probarlo.

text
MAL
Título: cambios
Descripción: (vacía)

BIEN
Título: Filtrar el roster por rol
Qué: tres filtros (tanque, daño, soporte); al activar uno, la lista
     muestra solo ese rol; al desactivarlo, vuelven todos.
Por qué: primera historia del epic de filtros (TB-42).
Cómo probar: abrir el roster, pulsar "Tanque", comprobar que solo
     quedan tanques. Caso límite: un rol sin héroes muestra un aviso.

¿Y qué pasa con un PR sin descripción? El revisor tiene que reconstruir tu intención leyendo el diff línea a línea. La revisión se eterniza o, peor, se aprueba a medias porque entenderlo cuesta demasiado, y los bugs se cuelan. Treinta segundos de descripción convierten una revisión penosa en una rápida.

Code review con respeto#

El code review —revisar el código de un compañero antes de integrarlo— es de los mejores sitios para repartir conocimiento… o para hacer daño. La regla de oro: se critica el código, no a la persona. Y los comentarios van concretos y accionables.

text
MAL:  "esto está fatal, ¿en qué pensabas?"
BIEN: "nit: este map puede ser un find, que corta en cuanto encuentra;
       en una lista grande importa. ¿Lo cambiamos?"

El primero ataca a quien lo escribió y no dice qué hacer; el segundo señala el código, explica el porqué y propone una acción. Ese “nit:” del ejemplo es una convención útil (de las conventional comments): marca el comentario como menor (“nit” = nitpick, una nimiedad), para que el otro sepa qué es bloqueante y qué es opcional. ¿Y qué pasa con los reviews hostiles? La gente se pone a la defensiva, deja de pedir revisión y el review se vuelve un trámite que todos temen, en vez de la red de seguridad que debería ser.

Dar y recibir feedback#

Tarde o temprano tendrás que decirle a alguien algo que no hizo bien. La forma de hacerlo decide si mejora o si se cierra en banda. Un modelo sencillo y muy usado es SBI: Situación, Comportamiento, Impacto.

text
MAL:  "eres un descuidado, siempre haces lo mismo"
BIEN: "En la demo (situación), enseñaste el filtro sin probarlo antes
       (comportamiento), y falló delante del cliente, que perdió algo de
       confianza (impacto). ¿Lo probamos juntos antes de la próxima?"

El malo cuelga una etiqueta a la persona; el bueno describe un hecho observable y su efecto. ¿Y qué? Una etiqueta genera defensa y no da nada que cambiar; SBI es accionable (se sabe qué hacer distinto) y se puede escuchar sin sentirse agredido. Y callar “para no incomodar” tampoco es amabilidad: es negarle al otro la información que necesita para mejorar.

Recibir feedback es la otra mitad, y cuesta igual. La clave: separar tu ego de tu código. Un comentario sobre lo que escribiste no es un ataque a ti. Ante un comentario que te parece injusto, lo profesional es entenderlo primero, preguntar si no ves el porqué y, si de verdad discrepas, argumentarlo con datos —no ponerte a la defensiva ni, en el otro extremo, tragar con todo sin pensar—.

Pedir ayuda bien#

Estar atascado es normal; pedir ayuda mal hace perder el tiempo a dos personas. Una buena petición trae: qué intentabas, qué esperabas, qué pasó (el error concreto) y qué has probado.

text
MAL:  "no funciona, ¿me ayudas?"
BIEN: "Al filtrar por rol, espero ver solo tanques pero sale la lista vacía.
       El array de héroes llega bien (lo veo en consola), así que sospecho
       de la comparación del rol. He probado a bajar todo a minúsculas sin
       suerte. ¿Se te ocurre algo?"

¿Y qué? “No funciona, ayuda” obliga a quien responde a sacarte el contexto a tirones; la petición buena se responde de una. Y hay un efecto extra: ordenar el problema para escribirlo bien (lo que llaman “explicárselo al patito de goma”) hace que muchas veces des tú con la solución a media frase. Preguntar bien no es molestar; es respetar el tiempo del otro y, de paso, el tuyo.

Discrepar y comprometerse#

Última pieza, porque trabajar en equipo es decidir juntos y no siempre gana tu opción. La actitud sana se resume en “discrepar y comprometerse”: defiendes tu postura con argumentos mientras se decide, y una vez tomada la decisión, te subes a ella y la apoyas de verdad, aunque no fuera la tuya.

¿Y qué pasa si no? El boicot pasivo —cumplir a regañadientes, recordar a cada rato que tú avisaste— envenena al equipo y frena el avance más que cualquier decisión técnica regular. Se discute antes; después, se rema todos a la vez.

Comprueba lo que sabes#

Pregunta 1 de 9

¿Por qué se dice que, en un equipo (sobre todo en remoto), la comunicación escrita es la habilidad blanda más importante?

Tu turno#

El ejercicio es puro oficio de equipo: escribir los tres artefactos de comunicación de una jornada normal —la descripción de tu PR, tu update de la daily y un feedback a un compañero con SBI—. Hazlos tú y compara con las soluciones, que suben de “plano” a “claro, accionable y respetuoso”.

Ejercicio · hazlo en local

Tres artefactos de comunicación

Sobre tu jornada en el Team Builder, escribe la descripción del PR de la feature de filtros, tu update de la daily (con un bloqueo) y un feedback escrito a un compañero usando SBI. Las soluciones muestran los tres en tres niveles de calidad. Hazlos tú primero y compara.

Paso 1: Los tres artefactos, aunque planos

  • Escribes la descripción del PR, el update de la daily y el feedback.
  • Se entiende, a grandes rasgos, de qué va cada uno.

Cómo hacerlo en local

Clona el repositorio del curso, entra en la carpeta del ejercicio y abre el index.html en tu navegador. Toda tu solución va en solucion.js. 

git clone <repo>
cd exercises/nivel-12/soft-skills
# abre index.html en el navegador y edita solucion.js
Ver soluciones 
# PR

Título: Filtro

Arreglado el filtro de roles.

# Daily

Ayer con el filtro, hoy sigo. Todo bien.

# Feedback al compañero

Te faltan los tests, eso no se hace. Añádelos.

Por qué este nivel

  • Los tres están, que es más de lo que algunos entregan. Pero ninguno comunica: el PR ("arreglado el filtro") no dice qué ni cómo probar, la daily es un "todo bien" sin bloqueo, y el feedback ("eso no se hace") es un reproche que ataca sin explicar ni proponer nada.
  • La consecuencia: el revisor del PR tiene que adivinar, el equipo no se entera de que estás bloqueado hasta que es tarde, y el compañero se pone a la defensiva en vez de arreglar los tests. Comunicar de menos cuesta caro, solo que el coste lo paga el de enfrente. El tier "mejor" añade el contexto que falta.