Llevo más de 6 años trabajando en remoto, los últimos 4 con equipos distribuidos en múltiples husos horarios. Mi conclusión: las reuniones sincrónicas son el último recurso, no la primera opción.

El trabajo async-first no significa “no hablarse”. Significa priorizar la comunicación escrita y diferida para que cada persona pueda trabajar en su momento más productivo sin interrupciones constantes.

Los pilares del async-first

PRs como unidad de comunicación

El pull request no es solo código. Es el principal vehículo de comunicación técnica:

## Description
Implements recurring payment processing from CSV upload.

## Context
We've been processing payments manually each month. This automates 
the workflow: validate rows → enqueue jobs → notify on errors.

## Key decisions
- **Each row is a separate job**: so a single bad row doesn't block the rest.
- **CSV parsed in a job, not the controller**: keeps response under 200ms.
- **Notifications via Laravel Notifications**: can be email, Slack or both.

## How to test
1. Upload `tests/fixtures/valid_payments.csv` via the admin panel
2. Run `php artisan queue:work --once`
3. Check `database/notifications` for results

## Screenshots
[Link to screen recording of the flow]

Closes #452

Un PR así permite que el revisor entienda el contexto, las decisiones y cómo probarlo sin necesidad de una reunión.

ADRs: decisions que no se pierden

Cada decisión técnica relevante se documenta como un Architecture Decision Record:

# ADR-023: CSV Payment Processing

## Status
Accepted

## Context
We need to process recurring payments from CSV uploads.
Options: sync processing, batch job, or per-row jobs.

## Decision
Per-row jobs dispatched to a dedicated queue.

## Consequences
+ Partial failures don't block entire batch
+ Can retry individual failed rows
+ Easier to monitor per-payment
- More Redis/RAM usage for job metadata
- More complex error reporting (per-row status)

## Alternatives considered
1. Sync processing in controller: blocked for large CSVs, timeout risk
2. Single job for entire CSV: one bad row fails everything

Los ADRs viven en docs/adrs/ y se referencian desde los PRs. Cualquier persona del equipo puede entender por qué se tomó una decisión sin preguntar.

El ritmo diario async-first

Los bloques de 3 horas sin interrupciones son donde ocurre el trabajo de verdad. Una reunión de 30 minutos en medio de un bloque de código profundo puede costar 2 horas de productividad perdida (tiempo de recontextualización).

Reuniones que sí valen la pena

No soy anti-reunión. Soy anti-reunión-sin-agenda. Estas reuniones tienen un propósito claro:

Regla: si no hay agenda escrita 24h antes, la reunión se cancela.

Herramientas que uso

• PRs y código: GitHub + GitHub Actions
• Documentación: Markdown en el repo (ADRs, READMEs)
• Comunicación async: Slack (canales por tema, no mensajes directos urgentes)
• Grabaciones: Loom para explicaciones complejas
• Issues: Linear
• Decisiones: ADRs en docs/adrs/

Conclusión

El trabajo async-first no es una filosofía abstracta. Es un conjunto de prácticas concretas: escribir PRs con contexto, documentar decisiones, bloquear tiempo para código profundo y reducir reuniones al mínimo necesario.

Si buscas un perfil senior que ya funciona así y puede ayudar a tu equipo a adoptar estas prácticas, revisa mi disponibilidad.

Artículos relacionados

• Mi setup remoto 2026: hardware, software y rituales — Equipo, herramientas, entorno
• Async-first: cómo trabajo en remoto desde Barcelona — Filosofía de trabajo, rutina diaria
• Laravel + Vue para equipos distribuidos — Arquitectura Inertia, flujo async, onboarding