Algorithms for Life: How to Communicate

Welcome to Udemy Research from our Alguralings for Life series by Valorangles. It's great to be here. Today we are tackling something that it really defines every single relationship you have. Oh, starting small then. Huh, yeah, just a light topic. But really, it defines your job pretty much every moment you're awake and interacting with another person. It's communication, it's the whole game. Exactly. And I want to start with a scenario. It's a universal experience, the phone rings. You pick it up, you say hello. The caller on the other end says, hi, this is name. You go speaking. And they say, hi, this is caller name. How are you? And you do the whole, I'm good, thanks. How are you? Dance. And only after all of that, after that whole ritual, does the real conversation even start? Right. We do it dozens of times a week. We don't even think about it. It's just automatic. It is. But here's the reveal. Here's what this deep dive is all about. That little dance. That isn't just being polite. That is a TCP handshake. It absolutely is. And for anyone listening who, you know, maybe isn't a network engineer, TCP stands for Transmission Control Protocol. Which I have to say sounds incredibly dry. It does. It sounds like something from an IT manual. But it's basically the set of rules that lets computers establish a reliable connection. It's the plumbing of the internet. That's a good way to put it. It's what makes everything else possible. So let's unpack this a bit. Because when I first saw the research for this, I thought, okay, this is a cute metaphor. You know, humans are like computers. Right. A clever and elitious. But it's so much deeper than that, isn't it? It's another way like computers in this case. We are solving the exact same problem. It's much deeper. This isn't a metaphor we just stuck on top of human behavior. It's a case of convergent evolution. Convergent evolution. Okay. So like how bats and birds both evolved wings, but they're not related. Exactly. They both face the same engineering problem, how to fly. So they arrived at a similar solution. And in our case, humans and computers both had to solve the engineering problem of connection. How do you establish a stable connection between two points? Let's break down that phone call again. Okay. Step one. The phone rings, and I say hello. In networking, that's the summons and the answer. In TCP, we call that the SYM packet. SYM. SYN4. Synchronize. Exactly. Synchronize. One computer or one person is reaching out and saying, hey, I want to talk. Are you there? Are you listening? So my hello is me sending a SYM packet out into the void. It is. Then what's step two? Hi. Is this name? That's authentication. The computer needs to know it reached the right server. You need to know you're talking to the right person. Right. Verification. And then they say, hi, this is caller name. And that is the SYN ACK. The synchronized acknowledge. It says, I hear you. I confirm I'm the one you're looking for and I am ready to receive. OK. OK. This is all tracking. But then there's the part I always thought was just filler. How are you? Oh, yes. That's not just small talk. That is parameter negotiation. Parameter negotiation. That has to be the least romantic, most clinical description for asking about someone's day I have ever heard. It sounds cold, I know. But think about what you're actually doing. You're not asking for their full medical history. No, of course not. You're checking the status of the other node before you start sending any heavy data. So if I say, how are you? And you sound rushed or upset or you're in the middle of a screaming match with your kids. You adjust your transmission rate. You don't just dump the big important news on me right then. You check the line quality first. That makes perfect sense. And what's wild to me is that computer scientists didn't sit down and study linguists to come up with this. Oh, and linguists weren't reading early network engineering papers they couldn't have. This human structure is ancient. They both just have the same problem to solve. How do I make a reliable connection when I can't be sure the other end is ready or if the line is even clear? And they both independently arrived at this three step hinge. Whether you're a server in a data center or just someone answering the phone, the solution is structurally identical. And we have actual scientific backing for the human side of this, right? It's not just an observation. Oh, absolutely. There's a landmark study by stivers and colleagues from 2009. This was a massive project. What did they do? They analyzed conversation structures across 17 different languages, English, Japanese, even indigenous languages with completely separate linguistic roots. So totally different cultures, different ways of speaking. Totally different. And they found this turn taking structure is, well, it's damn near universal. The words change, of course. The length of the how are you part might vary, but the sequence, summons, answer, identification, handshake. It's incredibly consistent. So we're all just running these ancient protocols without even knowing it. We are walking, talking network notes. Okay. So that's the hook that's fascinating. But it raises a huge question. Why? Why do we even need these protocols? Why can't I just, you know, walk up to you and start shouting information? Because our hardware is terrible. I mean, not terrible, but it's severely limited. And this brings us to the stat that I have been obsessing over all week. I read this paper. It's by Jean and Meister from 2025. Oh, I know that one. The unbearable slowness of being. Such a great title. But the numbers inside, I honestly had to read it twice. I thought it was a typo. What's the number? They state that conscious human thought, the part of you that is aware you are thinking, processes information at approximately 10 bits per second. That's right. 10, we have just sit with that for a second. 10 bits. It's shockingly low. My home internet is a gigabit per second. It's a billion bits. My sensory input, my eyes and my ears are taking in what? Something like a billion bits of information every second? Roughly. Yes. Your retina alone is like a high-deaf camera streaming constantly. Your skin is processing temperature, pressure. Your ears are hearing everything in this room. A fire hose of reality is hitting my brain every second. And the part of me that's actually me, the conscious part, talking to you, can only handle 10 bits of that. Think of it as a funnel, a massive, continent-sized funnel that narrows down to a point the size of a pin. That's a compression ratio of 100 million to one. It is, as they say, like trying to sip from a fire hose through a cocktail straw. But is it really that low? I mean, when I'm driving, for example, I'm checking my speed, watching traffic, listening to this, thinking about what to make for dinner, that feels like more than 10 bits. That's the illusion of consciousness. Most of that driving is your subconscious. That's the billion-bit process running in the background. Your basil ganglia. The autopilot. Exactly. But the conscious part, the part that makes a decision like, I need to change lanes now, or wait, what did he just say? That part is single-threaded. And it's incredibly slow. We are severely bottlenecked. That's the fundamental constraint of being human. And it explains almost everything about why communication is so hard. Is why we get overwhelmed in meetings. It's why we misread the tone of an email. And it is precisely why we need protocols. If we had infinite bandwidth, we wouldn't need to take turns or say, I could just dump the raw data of my brain into yours. A brain to brain data transfer. But we don't have that. We have this tiny little straw. So we have to be incredibly strategic about how we get the message across without losing it. And that is the mission for this entire deep dive. This is the fourth episode in our algorithms for life series. We've done optimization selection delegation. But none of that matters if you can't get the information from your brain to someone else's through that tiny 10-bit bottleneck. This is all about preventing packet loss. So for you listening, here's the plan. First, we're going to explore these hardware constraints in more detail. Your brain has measurable bandwidth, latency, and buffer limits. And you shouldn't feel bad about them. They're engineering limits, not personal failings. Then we'll uncover all the hidden networking protocols you're already using in your daily conversations. And then we'll go through flow control to congestion avoidance. And finally, and this work, it's really surprising. We'll discover that in human communication, lossy compression, throwing away data can actually be better than being perfectly accurate. Yeah, that's where we're going to have a bit of a debate, I think. I'm looking forward to it. So let's start with part one, the foundation, the hardware constraints. Okay. We've got the 10-bit processing limit. But what about the transmission speed? I mean, some languages just sound faster. They do. It feels that way. But there was a fascinating study by Kupai and colleagues in 2019 that looked at exactly this. The one with the 17 languages. That's the one. They looked at everything from Japanese, which is spoken very quickly with lots of syllables per second, to something like Vietnamese, which is much slower and more tonal. And what did they find? They found that the actual information transmission rate, it converges. It all levels out to about 39 bits per second. Like 39 bits, we just said conscious processing is 10. Correct. 39 is the raw speed of the audio streamer sending. Think of it as the bandwidth of your voice channel. The 10 bits is how fast the other person can consciously make sense of it. Ah, okay. But how does it all level out at 39? Well, take Japanese. It's spoken quickly with lots of syllables. But each syllable carries less unique information. It has what we call low information density. So more packets, but each packet is smaller. Exactly. So, there's a universal speed limit for human speech. Hardwired into us. There is. We've evolved to transmit information at the exact maximum speed the human ear and brain can reliably decode it. You literally can't talk faster than someone can listen. Okay. So, what do you do? I do. I do. I do. I do. I do. I do. I do. I do. I do. I do. I do. Okay. So that's the bandwidth limit. What about our memory, our buffer? Yeah. We all grew up with this 7 plus or minus 2 rule. Millerslaw, yeah. The idea that you can hold about seven things in your working memory. A phone number, a shortlist. But that's not right. It's a bit optimistic. More recent research, especially from Nelson Cowan in 2001, suggests that the real limit is closer to four. Four chunks of information. Four. That's what you can hold in your head right now without actively rehearsing. So let me get this straight. I am a single threaded processor. Yes. Running it 10 bits per second. Uh-huh. With a four chunk buffer. And you're very easily distracted. Oh, don't I know it. Let's talk about that distraction. Yeah. Because we all call it multitasking, and we wear it like a badge of honor. We do. I'm doing it right now. I have my script, my notes, a browser window open. I feel productive. You feel busy, but you are not productive. Ouch! See, a computer scientist wouldn't call what you're doing multitasking. They'd call it context switching. What's the difference? When a computer's CPU switches tasks, it's not instant. It has to save the entire state of task A, put it into memory, then load the entire state of task B. It's like wiping a whiteboard clean and drawing a whole new diagram. Perfect analogy. In that process takes time and resources. For humans, it's even worse. There's this great research by Sophie LaRoy on what she calls attention residue. Attention residue, it sounds sticky. It is. She found that when you switch from, say, writing a report to answering a quick email, your brain doesn't make a clean switch. A part of your cognitive RAM is still thinking about the report. So even when I'm looking at the email, a piece of my brain is stuck on the last thing I was doing. Correct. And that residue drags down your performance on the new task. The more you switch, the more residue builds up, and the slower and dumber you get. It's like having too many tabs open in a browser. Yeah. Actually, the whole system just grinds to a halt. Exactly. But wait, I have to push back a little here. Go for it. This idea of single tasking sounds lovely, but it's not the reality of my job, or most people's jobs. If I don't answer that quick question on Slack, my colleague is blocked. I get that it doesn't feel realistic, but the numbers are brutal. Constantly switching tasks can reduce your overall productivity by up to 40%. 40%? Up to 40%. You are essentially throwing away four hours of a 10-hour workday, just on the mental cost of switching back and forth. That's insane. And our environment is designed to make it worse. Gloria Mark's research shows that on a screen, our attention span on any single task has dropped to an average of just 47 seconds. 47 seconds before we click another window or check a notification. That's the average. This explains why those quick questions are so destructive. You're deep in thought and you get a ping. Yeah, got a sec. My response is always. There is no such thing as a quick question. I preach. In networking terms, that ping forces a full context switch. The question might take 10 seconds to answer, but the time it takes for your brain to unload your deep work state and then load it back up. Could be 15, 20 minutes? Easily. So that quick question just costs the company 20 minutes of your most valuable time. Three of those in an hour. And your entire hour is shot. You never achieve a flow state. You're just thrashing. Exactly. It reminds me of that big meta analysis, the one that looked at 79 studies on team performance. Right. From 95 to 2016, they looked at communication frequency versus communication quality. And the finding was so clear, sending more messages, higher frequency, had almost no effect on team performance. Sometimes it was even negative. But the quality of the communication was a huge predictor of success. Because if the network is already congested, which your brain always is, adding more packets just makes things worse. It causes a crash. You don't solve a traffic jam by shoving more cars onto the highway. You have to optimize the flow. Precisely. Okay. So we've established the hardware is a slot where slow. We have tiny buffers and context switching kills us. A glowing review of the human brain. It's inspiring stuff. But this is why the protocols exist. They evolved specifically because the hardware is limited. There are workarounds. So let's get to part two. The evidence. The hidden protocols we all use every day. We talked about the handshake. What happens once the line is open? We use flow control. In TCP, when a computer gets a packet of data, it sends back a little message called an ACK, and acknowledge men, which just says, got it. Send the next one. And we do this constantly. The uh-huh, the okayes, the nodding. Those are all ACKs. Think about it. If I'm talking to you and you just stare at me, completely silent, stone-faced. Oh. What do I do? I stop talking. Hmm. I assume you're not listening. Or the call dropped. You stop transmitting. Hmm. You need those ACKs to know the channel is still open. Research shows that 51% of conversational turns start with an explicit ACK like, yeah, or right. More than half. But here's the really mind blowing part. The timing. The typical gap between one person's stopping speaking and the next person's starting is less than 200 milliseconds. 200. That's faster than a blink. Yes. That's basically instantaneous. It feels that way. But wait a minute. that up. We just said our brains are slow. It has to take longer than 200 milliseconds just to process a word, right? Oh, much longer. It takes about 600 milliseconds just to plan and encode a single spoken word to find it in your brain and tell your mouth to say it. So if it takes 600 milliseconds to prepare a response, but I start speaking 200 milliseconds after you stop. It means you're not waiting for me to finish. So I am interrupting. Not exactly. You're predicting your brain is running a constant predictive algorithm, guessing how my sentence is going to end. And you're queuing up your response before I've even finished my thought. Yes. It's why we can finish each other's sentences. And it's why interruptions happen so easily. If your prediction is just slightly off, you get a packet collision, you get a packet collision, we both talk at once and the data gets corrupted. That's an amazing engineering feat. But what happens when people are running different protocols, the timing might be universal, but the style can't be right. And this is where you get into expectancy violations theory. And the classic cautionary tale here is Walmart trying to expand into Germany in the late 90s. Well, I read about this. It was a complete disaster. It was a protocol tragedy. So Walmart, you know, they're the king of American retail. And part of their brand protocol is the friendly greeter at the door. Right. Super enthusiastic. Hello. Welcome to Walmart. How can I help you today? Big smile. In the US, we understand this protocol. It's just friendly customer service. You might smile back. You might ignore them, but you know what it means. It's a low cost handshake. But in Germany, at that time, the retail protocol was very different, more reserved, more focused on privacy and efficiency. So when these German shoppers walked in and had a smiling stranger asking them personal questions, total protocol mismatch, they didn't receive the message as friendliness. What do they think it was? Many interpreted it as suspicion. Why is this employee talking to me? Are they watching me? Do they think I'm going to shoplift others, particularly women, interpreted it as inappropriate flirting? Because in their cultural protocol, a stranger doesn't engage with that level of intimacy unless they have an ulterior motive. So Walmart was transmitting welcome. And the customers were receiving your creepy and I don't trust you. Exactly. The data was fine. The smile was perfect, but the protocol was incompatible. And it was a major factor in why they eventually had to pull out of the German market entirely. That's a billion dollar protocol error. It is. And it happens in our personal lives all the time. One person might have a high involvement style where they interrupt and finish your sentences to show they're engaged. A lot of New Yorkers talk like that. And another person might have a high-considerateness style where they stay silent to show respect. We put those two people together and the first one thinks the second is bored and disengaged. And the second one thinks the first is rude and arrogant. They're not bad people. They're just running incompatible software. So the lesson is diagnose the protocol, not just the person. That's the key insight. Okay, let's talk about another one. Congestion control. What happens when the network gets flooded and packets start getting lost? So back in the 70s at the University of Hawaii, they had a system called Ailo in it. It was one of the very first wireless networks connecting the islands with radio waves. Right. And radio is a shared medium. If two computers tried to transmit data at the exact same moment, the signals would collide in the air and both would be lost. So they needed a rule for what to do after a collision? Exactly. If you both just retry immediately, you'll probably collide again. So they came up with a really elegant algorithm called exponential backoff. And how does that work? It's simple. If your transmission fails, you wait a random short amount of time and try again. If it fails a second time, you double the potential waiting time. And if it fails again, you double it again. You back off exponentially, you give the network more and more time to clear the congestion. And in the book algorithms to live by, they apply this to a very human problem, the flaky friend. Yes, they call it the algorithm of forgiveness. I love this. So you invite your friend out. They cancel last minute. The network is congested. They're busy or overwhelmed. Right. What's your first instinct to fix it? Oh, no problem. How about tomorrow next week? I'll try to send another packet right away. And you just cause another collision. You're adding to their congestion. Exponential backoff says, no, wait one week. Then send another invite. And if they flake again, wait two weeks, then four, then eight. It sounds a little bit like the algorithm of drifting apart from your friend. But that's the forgiveness part. You never stop trying entirely. You never send a fin packet to terminate the connection for good. You just adjust your transmission frequency to match what they can handle. Exactly. It balances your need to stay connected with the need to protect yourself from the frustration of constant failure. It's the surprisingly humane algorithm. Okay. So that's congestion. Let's move to maybe the biggest debate in every modern workplace. We have to choose our transmission mode protocol selection, specifically the great battle async versus sync or in networking terms packet switching versus circuit switching. Let's define those packet switching is async. It's email, Slack, text messages, I send a message, it gets chopped up, sent over and you read it whenever you want. Right. We don't have to be online at the same time. And circuit switching is sync. That's the old telephone network model. We open a dedicated real-time channel, a phone call, a Zoom meeting. We're both blocked from doing anything else for the duration. So the question is which one is better. And this is where I want to plant a flag because I've been looking at the research and the case for async seems overwhelming. Oh, that's so. There was a study in a healthcare setting. They switched a bunch of communication to an async platform and it reduced task completion time by almost 60%. 58.8%. Yeah, that's a huge game. It's massive. And then there's that MIT Sloan study. They gave employees three meeting free days a week, forcing them into async work. Port activity went up by 73%. So looking at those numbers, why are we still having meetings at all? Why isn't everything async? It's faster. It's more efficient. It respects our tiny little 10-bit brains. Let's just kill the meeting. I'm going to have to push back hard on that. I knew you would. But look at the data. The data is measuring efficiency. It's measuring task completion. But that is not the only or even the most important metric for human network. Packet switching is terrible at one critical thing, which is, for us. But the healthcare study said 70% of the staff felt interpersonal communication improved. For transactional work, sure. Did you give the patient their meds? That's a great use case for async. But look at that meta analysis of 79 studies again. The teams that performed best had strong communication quality, which was almost always linked to face-to-face circuit switched interaction. But maybe that's just because we're not used to building trust asynchronously yet. I think it's biological. You can't replicate the high bandwidth data stream of a face-to-face conversation over text. You lose tone, body language, micro expressions. You lose all the subtle cues that build real human connection. Okay, but subtle cues don't ship a product on time. No, but they build the cohesive team that ships the product and go back to that MIT study. You're right. Performance peaked at three meeting free days. But what happened when they tried four or five? It declined. It fell off a cliff. Yeah. Because the network partitioned. The social fabric of the team disintegrated. Without any of that real-time high bandwidth connection, people became isolated nodes. They stopped trusting each other. They stopped helping each other. So too much async and the whole network just falls apart. Good phrase. You need the circuit switching to maintain the integrity of the social graph. Okay, fine. We need both. But the default in most places is to have a meeting for everything. And that's clearly wrong too. How do you choose? I'm a big fan of the two exchange rule. It's a simple heuristic. If you're in an async conversation, email, Slack, whatever, and you go back and forth twice and there's still confusion or misunderstanding, stop. Just stop typing. Do not write a third novel-length paragraph explaining what you meant. Switch protocols. Pick up the phone. Start a call. Because the latency and the low bandwidth of text are making the problem worse. Exactly. You have an error in the transmission. You need to switch to a high bandwidth low latency channel to debug it quickly. I like that. The two exchange rule. I'm going to use that. It saves so much time and frustration. So speaking of networks partitioning, let's talk about the actual shape of the network itself. The topolids. All the nodes are connected. And there's a story here that is just Silicon Valley legend, the Amazon API mandate. The Bezos memo from 2002. It's foundational. So Bezos sends out this company-wide email. And he says basically from this day forward, all teams will communicate with all other teams only through formal service interfaces or APIs. No more backdoors. No more direct database calls. No more just walking over to Bob's desk to get some data. And he ends it with something like, anyone who doesn't do this will be fired. Thank you. Have a nice day. Yeah, that classic Bezos charm. But why did he do it? It seems so rigid. He was trying to solve a deep architectural problem by using something called Conway's law. Okay. What is Conway's law? Conway's law states that any organization will design a system that is the copy of its own communications structure. So if your teams are messy and disorganized and talking weird ad hoc ways, you will inevitably build messy, disorganized ad hoc software spaghetti code. And Bezos saw this happening at Amazon. So he did what's called the reverse Conway maneuver. Exactly. Instead of letting the communication structure dictate the software, he dictated the communication structure. He forced it to be clean, modular, and contract based. And he hoped that the software architecture would follow suit. Which it did? It allowed Amazon to scale massively. But it had an unintended world changing side effect. What was that? By forcing every internal service to have a clean public facing API, they had accidentally built all the component parts of a cloud computing platform. They could just bundle them up and sell them to the public. Yeah. And that became Amazon Web Services. AWS, which is now an $80 billion a year business. It's probably the most stunning example in history of how changing network topology can create value. It's incredible. But it also sounds, I don't know, a little dehumanizing, treating your teams like API endpoints. Oh, it's extremely dehumanizing. But it was effective. And this idea connects to Ronald Bert's work on structural holes, right? Yes. Bert's idea is that in any social network, you have these dense clusters of people who all know each other. The marketing department, the engineering team. But between those clusters, there are gaps. Those are the structural holes. And the people who bridge those holes, the ones who know people in both marketing and engineering are immensely valuable. They're the information brokers. They're the routers. They control the flow of information between otherwise disconnected parts of the network. And Bert found that managers who fill these roles get better performance reviews, they get paid more, they get promoted faster. Because they can translate between the different protocols of each group. Exactly. But there's a big risk. If you are the only bridge between two groups, you're also a single point of failure. And information degrades with every hop. I saw a stat that you lose something like 25 to 30% of a message's fidelity every time it crosses a hierarchical level in a company. That's terrifying. It's a corporate game of telephone. By the time a message from the CEO gets down five levels to the front line, it has less than 20% of its original meaning left, which is how you get catastrophic strategic drift. And this feels like the perfect transition. We spent all this time talking about how the networking metaphor works so well. Yeah. But now we need to talk about where it gets weird, where it breaks. Part three, application and limits, the inversion. All right. So in computer networking, losing data is bad. Lossy compression is something you use for a video stream, not for a bank transfer. You want perfect lossless data integrates. Perfect. But in human communication, I'm going to argue against this. I think we should aim for lossless. If I'm a doctor explaining a diagnosis or an engineer talking about specs, I need precision. I need the details. Lossy compression just sounds like dumbing things down. Shouldn't maximum clarity always do the goal? It feels like it should be. It appeals to our desire for control and accuracy. But the cognitive science says that's just wrong. How so? This is where fuzzy trace theory comes in. He was developed by Rayna and Brainerd and it's one of the most counterintuitive ideas in this whole space. Fuzzy trace theory. They argue that our brains encode information in two parallel tracks. There is the verbatim trace, the exact words, the precise numbers, and then there's the gist trace, the bottom line meaning. Okay. And here's the really shocking part. Experts, the doctors and engineers he mentioned rely more on the gist than novices do. Wait, what? Experts use less detail. That feels completely backwards. They process the meaning not the raw data. And expert doctors and just memorize a list of symptoms, they see the pattern and think heart failure. They jump straight to the gist. And you're saying this is actually better. The research shows people make better decisions when they're given the gist. There was a study on safety data. When they gave people precise lossless numbers, this product has a PUTU-005% risk factor versus 0.007%. People got bogged down. The cognitive load was too high. Their 10-bit processor got overloaded. Exactly. And they made worse choices. But when they presented the same data in a lossy, just format, product A is safer than product B. People consistently made the better choice. So the precision was actually acting as noise. For a human brain, precision is very often noise. It distracts from the actual meaning. You told me a story about the CDC that illustrates the crisis protocol. Imagine a worst-case scenario. A dirty bomb goes off in a major city releasing radioactive particles. The CDC has minutes to get a message to the public. The scientist's instinct would be to be precise. An aerosolized plume of CZM-137 is moving northwest at 12 miles per hour. That is accurate. It is lossless. And it will get people killed. Why? Because when people are in a state of panic, their cognitive bandwidth drops even lower than 10-bit per second. They can't process north-northwest. They can't process CZM-137. And I'll just noise. So what's the correct message? Get inside. Stay inside. Stay tuned. Six words. That's it. It's extreme lossy compression. It strips away every single detail except the core behavioral instruction needed for survival. It optimizes for the receiver's compromised hardware. Get inside. Stay inside. Stay tuned. It's basically the military concept of commander's intent. It's exactly that. You communicate the what and the why, but you leave the how flexible because you know the plan will hit the chaos of reality. I have to be the skeptic again. Please. If I just give my team the just, hey, just make the client happy. They could do that by giving away all our products for free. There's a danger in being too lossy. You're absolutely right. And the data backs that up. A study on commander's intent found that subordinates correctly interpreted their commander's true intent only about 34% of the time. That's a failing grade. It is. If you strip out too much detail, people will fill in the gaps with their own often incorrect assumptions. So what's the solution? You need both. You need to deliver the gist, but then you need to verify receipt. You need to use those ACKs we talked about. The goal is to make the client happy. My intent is that we do this by solving their core problem, not by giving discounts. Do you understand? So compress the initial message, but then use a lossless check-in to make sure the right gist was received. Exactly. Default to gist, but verify with specifics. Okay, another practical application, buffer management. Let's talk about our email inboxes. Ah, yes. The infinite overflowing buffer. In networking, when a device's buffer gets too full, you get a condition called buffer bloat. Everything slows down to a crawl because packets are just sitting there waiting in a massive queue. And an email inbox is a perfect example of a buffer. And for most of us, the arrival rate of new packets far exceeds our processing rate. I feel this in my soul. My unread count is in the thousands. It's a source of constant low-grade anxiety. That anxiety is the feeling of buffer bloat. Your system is clogged. And the solution from an engineering perspective is ruthless. It's the tactical dropping of balls. It sounds so irresponsible, but it's the only logical move. If you are receiving more messages than you can possibly process, you cannot answer everything. It's mathematically impossible. So trying to answer every single email is actually making the problem worse for everyone. Yes, because you're increasing the latency on every single response, you become the bottleneck. So what's the alternative? Just delete things without reading them. Or send a very fast no. A fast rejection clears the packet from your buffer. A non-committal maybe that sits in your inbox for three weeks is just blocking the whole system. A fast no is better than a slow maybe. It's a much kinder way to manage the network. Nielsen's research on response times shows this. A reply within 24 hours is good. After 48 hours, the sender just assumes packet loss. They think you've ignored them or you're dead. So clear the buffer, even if it means saying no more often. It's the most efficient and paradoxically the most considerate thing to do. Okay, we're coming up on the end here. Yeah. And we have to be really honest with ourselves and with everyone listening, we spend almost an hour comparing human beings to routers. We have. And it's a powerful model. But we're not routers. No, we are not. There has to be a hard limit to this metaphor, which brings us to this idea of the conduit metaphor. This is from Michael Reddy back in 1979. A linguist who noticed that something like 70% of the phrases we use in English to talk about communication assume that ideas are objects. We put ideas into words. We get a message across. I said we would unpack a topic at the start of this. Exactly. It's as if I have a thought, I package it into a box called language and I ship it over to you. And if you don't understand, it's because I pack the box wrong. But that's not what's happening at all. It's not. Meaning isn't transferred. It is reconstructed. What's the difference? I'm not sending you a thought. I'm just making vibrations in the air with my mouth. That's it. Your brain has to take those vibrations and build its own meaning based on your life experience, your emotional state, your understanding of the words. So I'm not sending you a house. I'm sending you a blueprint. You had to build the house yourself. And you might build a completely different house than the one I had in mind. Claude Shannon, the father of information theory, the inventor of the bit. He was explicit about this. His entire theory deliberately excludes meaning. He only cared about the fidelity of the signal, not at semantics. But let me push back on this one last time. Go on. Even if the metaphor is flawed, it's still useful. Right. The parallels are real. We discovered the TCP handshake in conversation before we even knew what TCP was. The brain is a processor with limits. This vocabulary gives us tools to fix our meetings and our relationships. Are you saying we should just throw it out? No, I'm not saying throw it out. I'm saying we need to know its limits. It is an incredibly useful map. But we must never ever mistake the map for the territory. What happens when we do? When a network packet arrives, it doesn't create reality. But when a human speaks, they can. When a judge says, I pronounce you married. That's not data transfer. That's a speech act that changes the world. A network can't do that. And a network hates ambiguity. Ambiguity is just noise, an error to be corrected. But in human affairs and diplomacy or even in a family argument, strategic ambiguity is a feature, not a bug. Sometimes being vague is the most intelligent thing you can do. To save face or to keep a peace treaty alive. Exactly. If we treat people only as nodes to be optimized for efficiency, you get the worst parts of industrialization. You get tailorism. You get systems that are efficient but have no soul, no humanity. So the synthesis here is, use the networking metaphor to fix your efficiency problems. Use exponential back off on your flaky friend. Use the two exchange rule for your email. But don't expect those tools to solve your meaning problems. Use the engineering to clear the channel so that the real messy human connection can actually happen on top of it. That feels like the perfect place to land this. Yeah. Let's try to summarize the biggest takeaways for everyone. Let's take away number one. Take away one. Your conversations run on invisible protocols. When communication breaks down, stop blaming the person and start diagnosing the protocol. Is there a mismatch? Are you missing ACKs? Is the channel congested? Think like an engineer. I love that. Take away two. Respect the bottleneck. You are a 10-bit processor living in a billion-bit world. You cannot do it all. So protect your focus, drop balls strategically, and remember that lossy, just-based communication is usually better than lossless, overwhelming detail. And the final, most important one, take away three. The map is not the territory. This metaphor is a tool for efficiency, not a modern for humanity. The goal isn't to be a perfect router. The goal is to connect with another person, which brings us right back to the beginning. The phone rings, you pick it up, you say hello, you run the handshake. But when you get to that last step, when you ask your friend, how are you? You aren't just negotiating parameters. You're not a machine-checking line quality. You're acknowledging a person. Yeah. You're showing you care. And that is something no network, no matter how advanced, we'll ever be able to replicate. Beautifully put, thanks so much for this. My pleasure. This was a great conversation. I'm your host. My challenge to you this week is to try the two exchange rule. The next time you find yourself going back and forth more than twice in an email or a slack thread, just stop. Pick up the phone, see what happens. It really works. You can find all the research studies and a full transcript at research.yuda.me. That's yuda.me. Thanks for joining our deep dive. See you next time.