It's probably more accurate to think of concurrent programming as what's going on in the brains of multiple people, instead of looking at it as how one person's

It's probably more accurate to think of concurrent programming as what's going on in the brains of multiple people, instead of looking at it as how one person's brain would handle parallel threads. Whenever you need access to information you don't have available, there's a barrier before you can continue that task: maybe you have to go look for somebody, or send a message and wait for a response, or buy a book. While these dependencies exist, you have some options. You could decide to work on something else; you could stop everything; or you could speculate on what the answer is likely to be, proceed as if that is the correct course, and expect to backtrack if you're wrong. To learn from the experience and not waste as much time in the future, you can remember key facts. Like any dependency graph, it can explode as more points are involved. If you have many people (or tasks), there's a greater risk that many of them will essentially be unproductive while waiting directly or indirectly for something else. The challenge is to keep everybody in tune and to give them enough to work on so that they're never really wasting time.