The Two Types of People: A Data Scientist's Litmus Test

Level 1: Finish the Sentence

Imagine your friend starts telling a joke, “There are two kinds of people: 1) people who can guess what I’m about to say…” and then your friend just stops and says nothing else. 😄 You’re left hanging, right? The funny part is that if you can figure out how that sentence was supposed to end, it proves the joke’s point! It’s like a riddle. The joke is basically saying: some people can guess missing information, and some people can’t. When the meme only shows the first type of person and doesn’t show the second, it’s secretly testing you. If you immediately thought, “Oh, the second type must be those who can’t do that,” then you solved the riddle! You’re one of the people who can fill in missing pieces. If you didn’t know how it ended, well, you just showed that you’re the other kind 😅.

In simple terms, the meme is funny because it makes you do a bit of work in your head – you have to finish the thought yourself. It’s like if a teacher wrote a sentence on the board and left off the last word, and you had to guess what that last word should be. Most developers and data folks deal with situations like that all the time, so they find it extra funny. But even without tech knowledge, you can laugh at the idea that someone told you “there are two types of people” and then never told you the second type. It’s silly and unexpected. The humor comes from that “Oh, I see what they did there!” moment when you realize you just became part of the joke by guessing the ending.

Level 2: Filling in the Blanks

If you’re newer to development or data science, some of these terms may sound abstract, so let’s break it down. Extrapolating from incomplete data means figuring out the rest of something when you only have a part of it. Imagine you have a puzzle but not all the pieces – you try to see the whole picture anyway. In a work context, a spec (short for specification) is like a detailed plan or description of what you need to build or analyze. An incomplete spec is when that plan has holes in it – maybe steps or requirements that are missing or not clearly defined. This happens more often than you’d think! You might get a ticket that says “Add a user profile page” but doesn’t tell you what fields to include, or you receive a data file where some records have empty values. As a junior, your first reaction is often, “Uh, what goes here?”

Now, there’s a famous tongue-in-cheek saying in tech circles: “There are two types of people in this world: those who can extrapolate from incomplete data…” and then they don’t list the second type. If you felt a slight itch in your brain expecting a "2)" after the "1)", that’s exactly the joke. The meme literally leaves the second item blank, forcing you to infer it. The expected completion is something like: “2) Those who can’t.” In other words, the joke itself tests whether you can fill in missing information. If you instantly thought of the second type on your own, congratulations – you just extrapolated from incomplete info, proving you belong to the first group. If you were momentarily confused looking for the rest of the sentence, well, you experienced what it’s like when requirements are unclear!

In development teams, this translates to how people handle missing pieces. Experienced developers often try to fill in the blanks themselves. For example, if a mobile app spec doesn’t mention what to do if there’s no internet, a senior dev might say, “It’s not stated, but we should probably show an offline message or cache data. That’s usually needed.” They’re using knowledge from prior projects to guess what the spec intended or forgot. This is similar to how in data science, if you have a few data points missing, you might use the trend of the existing data to guess those missing values (like if you have measurements for days 1, 2, and 4 of the week, you might guess what day 3 could be by averaging day 2 and 4, for instance).

Less experienced developers or those who haven’t seen a particular scenario before might not feel comfortable guessing. They might go back to the project manager and ask, “Hey, the spec doesn’t say what to do if the password is forgotten. Should I add a reset feature, or is that out of scope?” This is actually a smart move when you’re unsure; it’s better to ask than assume incorrectly. Over time, as you work on more projects, you start seeing patterns and can make more educated guesses. The key is communication: when in doubt, clarify. But when clarification isn’t available (tight deadline, different time zones, or the person who wrote the spec is on vacation), the ability to “read between the lines” becomes very valuable.

The meme also taps into a common form of nerdy humor: the list that cuts off. It uses an enumerated list (noted by the "1)") to set up an expectation. In everyday language “There are two types of people: X and Y” is a formula for many jokes. Here, X is given (“those who can extrapolate from incomplete data”) and Y is implied (“those who cannot”). The humor comes from the fact that the meme itself is “incomplete” — just like the data or specs it’s joking about. It’s a playful way of making you part of the joke. If you get it, you likely chuckle and feel a bit proud of yourself for catching on. If you don’t get it immediately, once someone explains it, you usually face-palm because the answer was ironically right in front of you: the meme forced you to experience incomplete info first-hand.

In summary, extrapolation is just a ten-dollar word for “making an educated guess based on the pattern or information you have.” And this meme is one big extrapolation exercise. It resonates with developers and data scientists because our jobs often require making sense of incomplete information. Whether it’s figuring out what a user really wants from a half-baked feature request, or predicting a trend from partial data, being able to fill in blanks is a crucial skill. And as the meme jokingly points out, not everyone does it naturally – it might even feel like there really are two types of people: those who do, and those who wait for the blanks to be filled.

Level 3: Reading Between the Lines

For seasoned developers and data scientists, this meme elicits a knowing grin of “Yep, been there.” The incomplete list joke — “1) Those who can extrapolate from incomplete data” with the second item missing — mirrors everyday realities in tech. Product specs, requirements docs, even bug reports are often frustratingly incomplete or ambiguous. Senior engineers have learned to read between the lines. They’ll see a feature request that’s only half detailed and immediately start asking (or silently answering) the unstated questions: What about error handling? What are the edge cases? Did they consider mobile users? When details are sparse, someone has to fill them in, and it’s usually the experienced dev who’s been burned by “assume nothing” in the past.

The meme divides the world into two types of people, and in a dev context that often translates to:

1. Engineers who can work with incomplete specs – These are the folks who don’t freeze when requirements are missing; instead, they leverage prior experience and context clues to make educated guesses. If an API spec is missing a response format for an error case, they’ll infer one that’s consistent with the rest of the design. If a data schema is half-documented, they’ll draw on similar projects or domain knowledge to fill the gaps. They’ve probably developed a quasi sixth sense for spotting what’s not said in a meeting that will become important later. In meetings, they ask “Hey, what should happen if X?” but if no answer comes, they’ll still implement something reasonable rather than leaving it blank. This is essentially extrapolation in engineering praxis – using partial information to construct a whole solution.
2. Engineers who need complete data – This second group (implied, but humorously not written out in the meme) are those who struggle or refuse to move forward until every requirement is explicitly spelled out. These might be more junior devs or simply people who prefer clarity over assumption. It’s not that they’re less intelligent; often, they’re being cautious. They might have been burned by making a wrong assumption before, so they’d rather not guess. However, in fast-paced or agile development environments, waiting for perfect information can be a luxury. The joke playfully nudges these folks: if you didn’t instantly fill in the missing “2)” in your head, you just proved you’re in this category! It’s a tongue-in-cheek way of saying “the ability to infer the unstated is what separates the seniors from the juniors” – or at least, those comfortable with ambiguity from those who aren’t.

This humor lands because it’s a shared pain across the industry (RelatableHumor). How many times have we seen a Jira ticket or a user story that leaves critical details “TBD” (to be determined)? Or a data set where half the fields are NULL and you’re still expected to produce meaningful insights? It’s practically a rite of passage in data science to learn techniques for incomplete data – whether that’s cleaning datasets with missing values or coping with sources that update erratically. Similarly, developers quickly learn that specification documents might have entire sections left blank (often with the cheeky note “This section intentionally left blank,” which is paradoxical and infuriatingly common). Over time, teams develop unwritten rules and tribal knowledge to handle these gaps. Senior devs might joke that part of their job is mind reading: “The spec doesn’t say it, but trust me, the client will expect the system to handle login timeouts gracefully. Let’s just implement that.”

The meme’s structure itself – using the famous “There are two types of people in this world…” setup – is a nod to a long-standing format in geek humor. One classic version goes: “There are 10 types of people in the world: those who understand binary and those who don’t.” (Here 10 in binary represents 2 in decimal – if you get that joke, congratulations, you’re extrapolating meaning from numeric context!). In our meme, the format is subverted to be self-referential. The second type of person isn’t written, because if you’re the first type, you don’t need it written. It’s a clever way to make the reader participate in the joke. Developers appreciate this kind of intellectual gag because it mirrors their daily work: something’s broken or missing, and you have to mentally execute code or user stories to figure out what should be there. It’s essentially a test of one’s “engineer brain.”

And let’s be honest, in many workplaces the ability to extrapolate from incomplete requirements is practically a superpower. It’s what turns a good developer into a great problem-solver. Architects and tech leads often operate on scant details, drafting entire system designs from a half-page concept brief. They’ve internalized patterns (“We’ve built login flows 10 times; if the spec doesn’t mention password reset, we’ll include it anyway because it’s obviously needed”). They also know when not to extrapolate too far – a skill in itself – and instead go back to stakeholders for clarification on truly ambiguous points. The humor of the meme also lightly pokes at communication issues: ideally, we shouldn’t have to be telepaths to get our work done, but reality is such that ambiguous specs and incomplete data are everywhere. Thus, the ones who thrive have developed a mix of technical knowledge, domain insight, and a dash of intuition to fill in the blanks.

Level 4: Inferential Intuition

At the highest level, this meme hints at the algorithmic art of extrapolation – a concept well-known in both data science and software architecture. In data science, extrapolation means predicting or inferring unknown values outside the range of your existing data. It’s akin to extending a line beyond the plotted points on a graph. Formally, if you have an incomplete dataset or an underdetermined system (fewer equations than unknowns), there are infinitely many possible solutions unless you impose extra constraints or assumptions. In practice, seasoned data scientists use techniques like statistical inference and machine learning to fill in the blanks. They might perform missing data imputation (guessing a plausible value for a missing data point based on the trend of known data) or apply Bayesian inference – updating their beliefs about the missing piece given what information is available.

Think of a simple example: you have data points for a sequence 2, 4, 6... and you’re asked for the next number. There are many conceivable answers (is it arithmetic +2 each time, or maybe these are even numbers so next is 8?). To extrapolate, you assume a pattern – here likely a linear increase by 2 – and predict 8. But if the true pattern was something else (like doubling each time after an initial delay), your extrapolation could be wrong. Inference always relies on assumptions or prior knowledge. Experienced engineers act like Bayesian learners: they carry a prior understanding of how requirements usually work, and when a spec is incomplete, they update that mental model with the partial info (the likelihood) to guess the rest. This is essentially performing a mental predict() call on the missing requirement.

From a theoretical perspective, extrapolating from incomplete data touches on concepts of information theory and entropy. A complete specification or dataset fully determines an outcome, whereas an incomplete one has high entropy (uncertainty). The meme’s format — listing “1) Those who can extrapolate from incomplete data” and leaving out the second item — is like a miniature information puzzle. The system (here, the joke) is underdetermined: it’s missing the second half. To solve it, your brain must supply the missing information. If you succeed, you’ve effectively performed a one-shot inferential leap reminiscent of solving an equation with a missing variable by applying logical constraints (in this case, the well-known setup "There are two types of people" implies the second type is the foil of the first). In computer science terms, it’s like encountering a function with some inputs undefined and relying on context or patterns to deduce what those inputs likely are. This is also why building software from an ambiguous spec is risky: without clear parameters, the solution space is vast. Engineers end up using intuition honed by experience (a sort of heuristic algorithm) to narrow down what the missing requirements probably are. The humor here hides a deep truth: inferring the unwritten is both a mathematical challenge and a hallmark of expert intuition in tech.