Developer Experience (DX): El Código como Herramienta de Onboarding
Arquitectura y code reviews como aceleradores: un sistema bueno hace productivo al nuevo en días, no en meses — automatizando lo trivial y quitando abstracciones innecesarias.
La mejor arquitectura no es la más sofisticada: es la que permite que una persona nueva entienda el flujo, ejecute el proyecto y haga su primer PR útil sin mapas mentales de tres pizarras.
Code review: enseñar, no exhibir
Un review que solo apunta superioridad manda la señal equivocada. Lo útil combina estándares claros, sugerencias concretas y contexto de negocio. El objetivo es subir la mediana del equipo, no ganar debates.
// Comentario poco útil:
// "Esto está mal."
// Comentario con DX positiva:
// "Aquí duplicamos validación; ya existe useUserForm() en features/user.
// Te dejo link al test de ejemplo: __tests__/user-form.test.tsx"Automatizar lo trivial
- Formato y lint en pre-commit o CI — la discusión de comillas ya está resuelta.
- Plantillas de PR y checklist mínimo (qué probé, riesgos, screenshots).
- Scripts documentados:
make devopnpm devdeben bastar.
Señal de un DX sano
Un desarrollador nuevo puede seguir el hilo desde el ticket hasta el código, correr tests localmente y proponer un arreglo pequeño en poco tiempo. Si eso tarda semanas, el problema rara vez es “falta de talento”: suele ser complejidad accidental acumulada.
Artículos relacionados
Documentación de Arquitectura que Sí se Actualiza
Plantillas, ownership y rituales para que la documentación técnica no se vuelva obsoleta al mes.
DX para Plugins Internos y Herramientas de Equipo
Buenas prácticas para construir herramientas internas que realmente adopte el equipo.
Cultura de Postmortems sin Culpas y con Aprendizaje Real
Cómo convertir incidentes en mejoras sistémicas en vez de buscar culpables.