Two minutes per change
The self-diagnosed reason Severo's backend has taken 'two days of it's almost done': every tiny change deploys to the cloud, two minutes plus cold start, and each wait invites a WhatsApp check; the fix is a local test loop, and the meta-lesson is measuring your cycle time.
// trace: where this idea came from
- ↳ video diary @ 18:09 (producción antes de probar localmente)
- ↳ video diary @ 18:28 (dos minutos por cambio)
- ↳ video diary @ 19:03 (la espera invita al WhatsApp)
Julia asks the question that only a cohabiting observer can: why has he spent three days asking the app to teach him fruit vocabulary? ▸ 14:46 The immediate bug was honest enough, a UI change silently broke audio upload, so the model received empty messages and answered generically ▸ 16:36. But the diagnosis he volunteers is about himself: “eso sí es un error mío, honestamente” ▸ 17:03.
The error is the loop. His backend lives in Google Cloud, so every change, however small, runs firebase deploy functions, one to two minutes, plus a cold-start wait before he can even try it ▸ 17:29. Stated as the anti-pattern it is: “el error que estoy cometiendo es enviar todo a producción antes de probarlo localmente” ▸ 18:09. Two minutes per change, times a debugging day’s hundred changes, is where the two days went ▸ 18:28.
mide el ciclo cambio-prueba; todo lo demás se multiplica por él →
And Julia lands the compounding factor with a callback to his own boredom experiment: each two-minute wait is an invitation, WhatsApp, LinkedIn, “5 minuticos”, so the dead time breeds more dead time ▸ 19:03. The emulator crash that pushed him to web was this same variable wearing a different mask: the single most leveraged number in a solo project is the seconds between making a change and seeing it run, because every other cost, bugs, boredom, morale, gets multiplied by it. Local emulation exists; he’s almost sure of it; tomorrow’s task writes itself…
// continued in
no entry has continued this idea yet: the arc is still open