I'd like to describe a few types of communication breakdowns in terms of the three basic data hazards, because I feel like it.
Has someone ever assumed you know something just because they know it?
In non-tech-related situations, we might use the word "context" like this:
What I'm talking about is not the above definition exactly, but the technical word context which I would consider a synonym of shared understanding within a group. I wouldn't consider context limited to a single situation (e.g., a funeral is meant to be solemn in some cultures). Rather, it's a collection of in-group ideas which may or may not be written down anywhere, but are applicable across multiple kinds of situations.
When designing a data pipeline, we must be careful not to affect an operand at the wrong time, else we run into one of the classic data hazards: read after write, write after read, and write after write. In each of these scenarios, there's some missing state (context) not quite carried through.
RAW (Read After Write)
Even though instruction B gets prcoessed after instruction A, part of the pipeline is still working on instruction A. B tries to act on the registers A hasn't yet written. Oops.
People example: you're trying to explain something technical to someone but skip steps, or otherwise fail to justify your work. They don't get it and you don't know why since it's completely obvious to you. You feel like you've explained everything necessary to understand the situation - but some key piece of data is still missing for them. Maybe then they're upset and don't know what to ask to get you to explain whatever it is they're missing because they don't know what they're missing. It might be easier if you don't explain the whole thing up front but rather start with a high level overview and then fill in details based on what they ask questions about. Alternately: provide background, explain a few steps, give them time to ask questions, repeat.
WAW (Write After Write)
Instruction A (which writes to the operand op) is still being processed and is not commutative with instruction B, which uses the value of op in another follow on action. We want what results from A, then B; not B, then A.
People example: you go to the grocery store intending to get things you and your roommate want, but you didn't realise your roommate wanted additional stuff! You go ahead and get them things and they're mad because they don't have what they need for the week. Sometimes it's hard to do things based on what other people want. Setting expectations (I will go to the grocery store at 8 pm on Wednesdays) could be a way around this.
WAR (Write After Read)
Instruction B writes a value to op before Instruction A can read op's value. This means that A gets the wrong value from op.
People example: someone tells you half the story (and gets it wrong either purposefully or accidentally) before you can get the main details from the person who experienced the event. You have no idea what is going on. When the person who experienced the event tells you their story, you're sceptical since you already are incorrectly going off the first version you got, from the person who wasn't even there. Or worse, you tell someone the first version, and it's a serious matter, and there are unintended consequences. Eventually you learn the real facts. You feel embarrassed. You have to apologise to people, or you just look plain silly. It's sometimes hard to tell if you're being wound up or not, depending. The person telling you the story could be abusing your trust in them. Verify your info before you pass on hearsay.