Mentoría y documentación técnica
Ayude a crecer a sus compañeros júnior mediante programación en pareja y comentarios oportunos, escriba ADR para decisiones arquitectónicas y mantenga documentación viva en la que los demás confíen.
Mentoría y documentación técnica es una lección gratuita de Frontend Academy en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Frontend Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Frontend Academy incluye 4 lecciones en total.
Ser senior significa potenciar a los demás
En el nivel senior, su trabajo no consiste en escribir más código, sino en mejorar a su equipo. Sea mentor de los perfiles junior, escriba documentación que amplíe su conocimiento, haga revisiones de código que enseñen y dé forma a la arquitectura para que los demás puedan avanzar rápido y de forma segura.
Mentoría mediante programación en pareja
La programación en pareja es la forma más rápida de hacer crecer a una persona junior. Siéntense juntos (o compartan la pantalla) y deje que la persona junior escriba mientras usted guía. Resista la tentación de tomar el control: explique su razonamiento y haga preguntas socráticas.
Retos adecuados
Asigne a las personas junior tareas que estén justo por encima de su capacidad actual. Demasiado fáciles = no hay crecimiento. Demasiado difíciles = se sentirán desbordadas y frustradas. Calibre el reto: «Creo que puede hacerlo con un poco de ayuda; estaré encantado de trabajar en pareja si se atasca».
La revisión de código como enseñanza
En las PR de perfiles junior, explique el motivo de cada comentario no trivial. Enlace documentación, PR anteriores o artículos relevantes. Mala revisión: «use useCallback». Buena revisión: «esta función se vuelve a crear en cada renderizado; al pasarla a un componente hijo memo'd provoca renderizados innecesarios. useCallback la memoriza. Aquí tiene una PR de ejemplo en la que hicimos esto: #1234».
Registros de decisiones arquitectónicas (ADR)
Un ADR documenta una decisión arquitectónica importante: qué decidimos, por qué, qué alternativas consideramos y qué contrapartidas aceptamos. Su yo del futuro se lo agradecerá a su yo actual.
# ADR-0007: Use TanStack Query for server state
Date: 2026-05-01
Status: Accepted
## Context
We currently scatter useEffect+fetch+useState patterns across the app.
Cache invalidation is inconsistent, race conditions cause stale data.
## Decision
Adopt TanStack Query (@tanstack/react-query v5) for all server state.
## Consequences
+ Built-in caching, deduplication, optimistic updates.
+ Standard pattern across team.
- Adds ~13KB gzipped.
- Team needs to learn query keys conventions.
## Alternatives Considered
- SWR: smaller, but fewer features (no mutations).
- Apollo Client: overkill (we don't use GraphQL).
- Custom hook: doesn't solve cache invalidation.
## References
- React Query docs: ...Dónde se guardan los ADR
Guarde los ADR en docs/adr/ dentro del repositorio y numérelos secuencialmente. Se almacenan junto al código que describen. Herramientas: adr-tools y log4brains para disponer de una interfaz web navegable.
Calidad del README
Cada paquete, biblioteca y funcionalidad importante necesita un README. Incluya: qué hace, cómo instalarlo, cómo usarlo (con ejemplos de código), cómo contribuir, cómo ejecutar las pruebas y cómo depurarlo. Desarrollo guiado por README: escriba primero el README y después construya conforme a esa especificación.
Comentarios de código en línea: cuándo usarlos
Los comentarios deben explicar por qué, no qué. El código muestra qué hace. Los comentarios explican: reglas de negocio, contrapartidas no obvias, enlaces a tickets o errores y advertencias sobre posibles problemas.
// BAD: comment restates the code
// Increment counter by 1
counter++;
// GOOD: comment explains business context
// Stripe webhook can arrive twice — increment only if signature is fresh.
// See: https://stripe.com/docs/webhooks/best-practices#idempotency
if (!seen.has(event.id)) counter++;Runbooks para tareas operativas
Documente cómo realizar tareas operativas recurrentes o arriesgadas: «Cómo rotar la clave de API de Stripe», «Cómo recuperarse de un despliegue fallido», «Cómo depurar una respuesta lenta de la API». Los nuevos miembros del equipo podrán seguirlas sin tener que avisarle.
Documentación viva
La documentación obsoleta es peor que no tener documentación. Póngale fecha. Revísela cada trimestre. Elimine la documentación que nadie actualice. Mejor aún: genere documentación a partir del código (Storybook para componentes, TypeDoc para APIs, OpenAPI para endpoints).
Charlas técnicas y sesiones brown-bag
Dé charlas de 20 a 30 minutos a su equipo sobre lo que ha aprendido: una biblioteca nueva, una historia de depuración o un patrón que le haya resultado útil. Esto le obliga a organizar sus ideas y enseña a los demás.
Crear seguridad psicológica
Las personas junior que temen hacer preguntas no crecen. Normalice decir «no lo sé». Haga que sea seguro cometer errores: celebre el análisis post mortem, no busque culpables. Como persona senior, sus reacciones marcan el tono del equipo.
La trampa de la programación heroica
No sea la persona que resuelve sola todos los incidentes de producción. Documente la solución, trabaje en pareja con un compañero la próxima vez y automatice el diagnóstico. Un equipo que necesita sus hazañas es frágil.
Comprobación rápida
¿Cuál es el objetivo principal de un registro de decisiones arquitectónicas (ADR)?
Recapitulación: mentoría y documentación
Ser senior = potenciar a los demás, no escribir más código. Programe en pareja; enseñe mediante revisiones de código; asigne retos adecuados. Los ADR en docs/adr/ registran por qué se tomaron las decisiones. README para cada paquete. Los comentarios explican por qué, no qué. Runbooks para tareas operativas. La documentación viva (Storybook, TypeDoc, OpenAPI) supera al markdown estático. Cree seguridad psicológica. Evite la programación heroica.
Preguntas frecuentes
¿La lección «Mentoría y documentación técnica» es gratis?
Sí — el texto completo de «Mentoría y documentación técnica» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Frontend Academy, actualiza a CoddyKit PRO. El curso de Frontend Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Mentoría y documentación técnica»?
Ayude a crecer a sus compañeros júnior mediante programación en pareja y comentarios oportunos, escriba ADR para decisiones arquitectónicas y mantenga documentación viva en la que los demás confíen. Practicas Frontend Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Frontend Academy?
No se requiere experiencia previa. Frontend Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Mentoría y documentación técnica»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Frontend Academy?
Sí. Cada lección de Frontend Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Entrevistas de diseño de sistemas frontend
- Cultura de revisión de código y buenas prácticas para PR
- Mentoría y documentación técnica
- Mantenerse al día: lectura de especificaciones y propuestas