Summary
Tasks are the other half of computing — the part that takes inputs and produces outputs by following instructions. Every line of code you have ever written is part of some task. But not every task is the same shape, and the single most under-taught distinction in junior engineering is the one between tasks that happen *now* (while the user is waiting) and tasks that happen *later* (after the user has moved on).
This lesson installs that distinction. You will see why a synchronous task — the kind running inside a web request — is constrained by what a human is willing to wait for, and why an asynchronous task — running in the background after the user has clicked away — operates under completely different rules. The two shapes correspond to the two task-side building blocks introduced later: Service and Worker.
The reason this distinction matters: most system-design mistakes at the junior level come from cramming "later" work into a "now" task. The video walks through why that happens, what breaks when it does, and how thinking in the two task types prevents the failure mode entirely.
Key takeaways
- Every task is either synchronous (the user is waiting) or asynchronous (the user is gone). The two shapes have completely different constraints.
- Synchronous tasks live inside a request and must finish in human-acceptable time (milliseconds to a few seconds).
- Asynchronous tasks run on their own schedule and can take as long as they need, but they require additional infrastructure to coordinate.
- Most production bugs from junior engineers come from putting async work in a sync path. Naming the distinction prevents it.
Every task is either happening now while the user waits, or later after they have moved on. Those are two different worlds.