Drake decides post-call ratings are for judging conversation, not packet loss
Why is this Communication meme funny?
Level 1: Bad Signal, Good Chat
Imagine you just finished a phone call with a friend. After you hang up, someone asks you, “Was the phone line good? Could you hear each other clearly?” That’s like asking if there was any static or problems with the connection. But instead of answering that, you smile and say, “Oh, we had such a fun talk!” You’re talking about how enjoyable the conversation was, not about the phone’s sound quality at all. That’s exactly what’s happening in the meme. It’s funny because the question was really about the connection (was it a bad signal or a good signal?), but the person answered about the conversation (if it was a good chat or not). In simple terms, the meme shows someone caring more about having a great time talking than about the technical part of the call. It makes us laugh because they totally answered the wrong question – but in a way we can all relate to, since a friendly chat can make us forget any small technical hiccups!
Level 2: Call vs Conversation
Let’s break down what’s happening in this meme in simpler terms. It uses the popular Drake meme format: two panels with Drake making a dislike gesture in the top image and an approving point in the bottom image. This format is often used to show a preference by rejecting one thing and choosing another. Here’s how it applies:
In the first panel, the meme text says “Evaluating the call from a technical point of view” next to Drake pushing something away. This means the person is saying “No” to judging the call based on technical quality. Technical quality of a call refers to things like whether the audio was clear, if the video lagged, or if any connection issues happened. In tech terms, that’s stuff like packet loss (did some of the audio data get lost causing gaps?), latency (was there a delay causing people to talk over each other?), or general call stability. Essentially, this is what the app’s post-call prompt is intended to ask. When the dialog says “How’d the call go? Tell us about your call experience.” with those emoji options, it’s designed to gather feedback on call quality issues. Imagine rating if your internet connection was good during the meeting – that’s the technical point of view. Drake is rejecting this approach in the meme, implying our user isn’t going to focus on those details.
In the second panel, Drake is smiling and pointing, with the caption “Rating the conversation instead of the call itself.” This is what the person chooses to do instead, and Drake’s happy expression means “Yes, this is the way I like.” So rather than giving feedback about the call’s technical performance, the user is giving a rating based on how the conversation went. In other words, they are judging the meeting by its content and vibes: Was it a friendly chat? Was it a productive meeting? Did they enjoy talking to the other person? This is a social evaluation rather than a technical one. It’s like after a meeting, thinking “That was a great conversation!” or “That was awkward…” and then clicking the happy or sad face accordingly. The meme is funny because the user has flipped the script on the purpose of the feedback. The app wanted information on things like dropped calls or poor audio (the nerdy stuff), but the user is evaluating something totally different (the human stuff).
This is a very relatable dev experience in the era of remote work and endless online meetings. If you’ve ever used Zoom, Microsoft Teams, or Google Meet, you might have seen a little survey at the end asking how the call was. Often it’s a few faces or stars you can click. They’re trying to improve the service by finding out if you had any trouble hearing or seeing each other. But many people, not just engineers, interpret “How was your call experience?” more generally. The word “experience” is broad – it could include your feelings about the meeting itself. So it’s easy to just think it means “Did you have a good meeting?” For instance, if you just had a one-on-one with your boss that went great and you got praise, you’re likely to hit the 😃 happy face because you feel good – even if maybe there was a tiny bit of lag on the video. Conversely, if you had a frustrating team call (maybe it should have been an email and wasted an hour), you might jab the 😓 sad face, basically saying “that was a bad call” – though the internet connection was actually fine. In doing so, you’ve given feedback about the meeting communication rather than the call connection quality.
Let’s clarify a couple of terms and context tags here:
- Call quality rating – This is the feedback you give about how good or bad the call was. The intention is to get a rating of the call’s technical quality. Good call quality means no audio issues, no disconnects, everything worked.
- Technical vs social evaluation – Technical evaluation is judging something by how well the technology worked (in a call, that’s sound, video, connection). Social evaluation is judging by human factors: was the conversation clear, friendly, useful? The meme contrasts these two: Drake says no to technical, yes to social.
- User feedback UI – The top part of the meme shows a user interface prompt with emoji faces. That’s a User Feedback UI element where the app asks you (the user) to give quick feedback. The faces 😓 😐 😃 likely correspond to bad, neutral, and good. There’s even a checkbox saying “Don’t show me this again.” which shows the user can opt out of these surveys (perhaps because they find them annoying or irrelevant).
- Drake meme format – This is the two-panel format with Drake, derived from a music video. It’s commonly used online to humorously show someone’s preferences. In our meme, Drake’s gestures perfectly depict the choice to ignore one type of rating and embrace another.
In summary, the meme humorously portrays an engineer (or any user really) who, after a meeting, cares more about how the meeting went socially than about the nitty-gritty of call quality. It’s emphasizing that in day-to-day Communication during Meetings, what we often remember is the conversation, not the wire speed or video resolution. For a junior developer new to remote work, it’s a good reminder that while we love stable internet and clear audio, the point of a meeting is the interaction itself – and sometimes we unconsciously rate our experience on that interaction rather than on the tech that enabled it.
Level 3: Packets vs People
This meme nails a classic RemoteWork irony: as engineers, we’re expected to focus on technical quality – the “packets” part of a call – but we’re also humans who care about the people part, the conversation itself. In the top panel, Drake is essentially saying “Nope” to evaluating the call purely on network stats like a devops monitoring tool. That’s funny because you’d think a developer on a video call would be ultra-attuned to glitches: Was there lag? Any audio distortion? How’s the video resolution? We have all this Monitoring and telemetry at our fingertips, yet here we see the opposite: the engineer chooses to judge the call by social metrics – were the jokes good, did we communicate well, was the meeting productive? Drake in the second panel is eagerly pointing to that approach, meaning he’d rather rate how the conversation felt than how the data packets flowed.
Why is this so relatable in a dev context? Think of all the daily stand-ups, sprint demos, or one-on-one meetings we attend. After a while, what stands out isn’t the minor blip in audio; it’s whether the meeting itself was worth it. Maybe the VideoConferencingTool worked flawlessly (zero buffering, crystal clear audio), but if the discussion was frustrating or pointless, it still feels like a “bad call.” Conversely, we’ve all had those chaotic Friday calls where someone’s screen froze mid-sentence or “you’re on mute” happened five times – yet everyone was laughing and the team bonded over the mishaps. In the end, you remember it as a good experience because the communication was effective (or at least entertaining), not because the network cooperated. So when that feedback dialog pops up asking “Tell us about your call experience”, what do we do? We rate the meeting quality instead of the line quality. It’s a bit of a running joke in remote work culture: the survey wants to know about echo cancellation and bandwidth, but we treat it like a conversation rating scale.
This speaks to a broader Communication truth in tech teams: soft skills and meeting dynamics often trump technical issues in our memory. The meme exaggerates it by showing Drake (a stand-in for any of us) blatantly prefering the subjective “How did I vibe with my coworker?” evaluation. It’s poking fun at how we engineers, who are usually logical and data-driven, will toss aside the intended data collection (packet_loss_percent, jitter_ms – who cares?) and give feedback more suited to a social media post: Great call, felt really productive! 😃. It’s an inversion of priorities that seasoned developers recognize. We’ve seen plenty of post-mortem meetings where despite serious technical glitches, the first comments are “Well, at least we had a great brainstorming!”. It’s funny because it’s true – in real-world team interactions, the human element often overshadows the pure tech.
From an organizational perspective, this meme also hints at a mismatch in incentives. The product designers of that call software included the rating dialog to gather metrics about call quality. They likely forward these stats to a dashboard to monitor service performance across all those remote meetings. But in practice, users repurpose it as a mini Yelp review for the meeting itself. An experienced engineer chuckles at this because it’s a classic case of metrics going sideways. We’ve all encountered KPIs or feedback forms that end up measuring the wrong thing. (Remember when developers were measured by lines of code and they just wrote more lines? Same energy here: ask for call feedback, get meeting satisfaction instead.) The presence of the “Don’t show me this again” checkbox in the UI is the cherry on top – it shows even the app creators know people might be annoyed by these constant prompts. Many of us have checked that box after our 5th video call of the day, effectively saying, “I’m done giving you data, leave me alone.” Drake’s attitude in the meme is a humorous reflection of that fatigue: he’s not interested in dissecting the WebRTC connection stats, he’s interested in whether the conversation was decent and then moving on. In a world of endless virtual meetings (so many Meetings...), rating the conversation instead of the connection is our small act of rebellion – or at least a moment of honest humor.
Level 4: The Packet Loss Paradox
On a technical level, video calls are all about network performance metrics. When we finish a Zoom or Teams meeting, the app might ask for feedback to gauge Quality of Service (QoS). That prompt with emoji faces is essentially measuring what telecom engineers call a Mean Opinion Score – a user-rated measure of perceived call quality. Under the hood, the system is already tracking hard data: latency (how long packets take to arrive, affecting delay), jitter (variations in packet timing that make audio choppy), and packet loss (when chunks of audio/video data get lost in transit). For example, if 5% of voice packets vanish due to network issues, you’ll hear gaps or robotic sounds. These stats are pure telemetry: numbers the app gathers to assess connection health.
However, Quality of Experience (QoE) isn’t purely captured by those numbers, so apps solicit the human perspective with a “How’d the call go?” survey. Ideally, your rating correlates with network performance: a happy face means low latency and no dropout; a sad sweaty face 🙃 might indicate your audio was cutting out or the screen was freezing from high jitter. This is where the paradox emerges: the meme shows an engineer ignoring that intended QoS feedback in favor of something else entirely. Instead of reporting on echo or packet loss, Drake’s response is based on the meeting’s social vibe. Technically, this skews the data – it’s as if a network monitoring tool suddenly started measuring conversation quality instead of bandwidth. From a systems perspective, it’s a misalignment: the metric (user rating) is no longer purely about connection reliability, but about interpersonal success. In networking terms, we’ve confused the signal (call clarity) with the higher-level noise (meeting content). Engineers find this hilarious because it breaks the model: the feedback loop meant for improving call reliability is being fed data about how charming or awkward the chat was. It’s a bit like calibrating a packet routing algorithm using movie reviews – the input doesn’t match what you’re actually trying to optimize. This highlights a known engineering challenge: if your feedback mechanism isn’t clearly defined, users might rate “overall call experience” based on subjective factors you never accounted for, leaving your poor algorithm scratching its head (figuratively speaking) about those phantom packet losses that never were!
Description
The meme is a two-panel Drake format over a dark grey post-call rating dialog. Top section shows a UI prompt reading “How’d the call go? Tell us about your call experience.” with three emoji-style faces (sweating sad, neutral, sparkling happy) and a checkbox label “Don’t show me this again.” Below, first yellow-tinted Drake frame has Drake turning away with palm up, and large caption to the right says “Evaluating the call from a technical point of view.” In the second frame Drake smiles and points approvingly at the camera; caption reads “Rating the conversation instead of the call itself.” The joke flips a quality-of-service survey - meant to capture jitter, latency and audio dropouts - into a subjective chat rating, highlighting how engineers often ignore intended telemetry and focus on soft-skill vibes instead
Comments
9Comment deleted
10% packet loss, jitter through the roof, Opus fell back to G.711… but the PM finally said “you were right.” That’s a five-star MOS right there
After 15 years of building distributed systems, I've learned that users will always rate their manager's rambling monologue as 'poor call quality' while a crystal-clear 4K video of a layoff announcement gets five stars for 'technical excellence.'
This is the engineering equivalent of asking 'How was your experience with our database?' when you really need to know if the query took 50ms or 5 seconds. When your telemetry conflates network jitter with whether Bob from accounting told a good joke, you end up optimizing for the wrong SLOs - and wondering why your perfectly stable WebRTC implementation still gets one-star reviews because someone discussed quarterly projections
We instrument jitter, packet loss, and MOS - yet one‑star ratings spike whenever the meeting’s about scope creep; apparently QoE measures PM entropy, not WebRTC
Optimizing for conversational throughput while ignoring actual commit velocity
When your survey asks “How’d the call go?”, you’re A/B testing Goodhart’s Law - MOS ends up measuring the sales pitch, not the WebRTC jitter buffer
Repost Comment deleted
someone really likes the joke huh Comment deleted
repost REEEEEEEE Comment deleted