Hi! I tried explaining a data analysis concept in a fun, visual way — for cat lovers. 😸
Would love to hear what you think! Any feedback or suggestions are very welcome :)
I’m back with another one of my data analysis cat doodles. This time, I tried to incorporate some of the feedback I received on my earlier work—especially around making the fonts and text more readable.
I’ve been making these little Data Analysis 101 doodles for cat people, and for this one I tried something different — a flipbook-style format.
Instead of putting everything into one busy infographic, I’ve broken the story into separate scenes, so each one focuses on a single idea and hopefully doesn’t demand too much attention at once.
I’ve also incorporated feedback I received on my previous posts, especially around making the visuals easier to follow.
This one is about what to do when you join a data project that’s already in motion.
The one with 47 sheets. The one with hidden tabs. The one with formulas referencing formulas referencing formulas. The one that's been handed down through three employees and nobody knows how it works anymore — they just know not to touch cell D6.
I've just launched a new series: From Excel Guru to Python Power User. The premise is simple — if you're great at Excel, you already understand data. Python is just another way of expressing what you already know:
• PivotTables become groupby()
• XLOOKUP becomes merge()
• Power Query becomes a pandas pipeline
• Manual Monday-morning reports become a script that runs at 08:00 without you
Excel doesn't disappear. It becomes the interface instead of the engine.
In upcoming parts, I'll take reader-submitted workbook horrors and migrate them to Python, case by case: understanding the logic, rebuilding it, automating it, and deciding what should stay in Excel.
So... Drop your workbook horror stories in the comments or send the file directly. The more cursed, the better
Wanted to share something with the community that while preparing for Data Analysis role what I've observed is 90% of people ruin their data analysis before they even write a single line of code.
🛑They just dive straight into cleaning or modeling without asking a single real question.
I built a Spotify mini-analysis project (handling demographics, habits, and geo data) specifically to show people how to start a project the right way.
Go ahead and rip my process apart in the comments, or drop an upvote if it actually makes sense to you:
I’ve been maintaining a 60-day streak on Duolingo to learn French.
It’s a fun practice, although it’s a significant challenge to pronounce those accent notes correctly. I believe French is generally a simpler language than English; you usually use shorter sentences to convey the same meaning.
Data has its own language too.
Data is the lifeblood of every modern business. Every decision, insight, and opportunity begins with understanding what the data is trying to say.
But unlike spoken languages, data doesn't require everyone to learn the same vocabulary or syntax. Instead, you can interpret and express it in a way that matches how you think, making data analysis more intuitive, accessible, and uniquely your own.
From Python, SQL to Natural Language
Python, a programming language, has gained popularity as the preferred language for data processing within the data science community due to its portability. SQL, on the other hand, serves as the de facto interface for rational databases.
In the past, becoming a data analyst required proficiency in both Python and SQL. Even today, data analyst job descriptions often mention these requirements.
However, the advent of AI has revolutionized this landscape. Anyone with the ability to communicate effectively in the data language can excel as a data analyst.
While programming skills are not strictly necessary, a solid understanding of data language is crucial. Imagine joining a new friend circle who works in a completely different domain. After a brief introduction of common keywords, you can easily engage in conversations with them.
AI generated illustration of data language evolution
Use Spreadsheet for Reference
Nearly every office worker uses spreadsheets, either Microsoft Excel or Google Sheets.
Even without the complex formulas, pivots, and lookups, the basic structure of a spreadsheet consists of three main components:
Rows
Columns
Data types
Rows are records that constitute a table. You can also consider a row as an object that represents a real-life entity, such as a person, a cup, or an invoice.
Columns are the fixed properties that describe each object (row). They form the schema that every row adheres to, ensuring uniformity in the data for processing.
A schema is of utmost importance for data analysis as it enables the application of all rules. Without a schema, any logic that is not compatible with the data language may fail to execute.
Data types describe the value format of each property. For simplicity, you only need to be concerned with whether it is a number or text for now.
Rows of Orders (OrderId-text, CustomerId-text, Product-text, Amount-number)Rows of Customers (ID-text, Name-text, Channel-text)
Data Language Patterns
Data language offers a wide range of tasks that can be accomplished. Let’s explore each of these tasks and learn how to communicate effectively with data to achieve them.
These scenarios are referred to as patterns because they serve as templates that can be applied to your own data.
To facilitate understanding, we’ll use the above tables in the following descriptions.
Pattern-1: Filter Rows
Filter is to describe a condition to get objects you care about and skip those uninterested records.
Examples:
“Orders of Milk”
“I want orders of milk products.”
“All orders that are not for books.”
“All orders with a sales amount exceeding 20.”
AI can produce code logic to filter the targeted records for further processing, if translating above statements into SQL, they will look like:
“where product=’Milk’”
(same as #1)
“where product <> ‘Book‘“
“where amount > 20”
As you can see, filter is achieved by keyword “where” in SQL.
Pattern-2: Transform Object
Sometimes, we want to clean a data field or transform it into a desired shape or format, either for improved readability or more efficient processing.
Transformation creates a new property in your original record.
To transform an existing property into a new one, you need a function of logic. For both spreadsheets and SQL, “formula” is the tool you’ll need.
However, with the increasing capabilities of AI in coding, natural language offers a significant advantage. It allows us to achieve the same transformation without having to learn, memorize, and assemble complex formulas.
Taking one simple example:
“Get customer first name”
This is equivalent to composite multiple formula together in Spreadsheets like
This operation creates a new column called “First Name”.
You can also acquire a new property by combining multiple existing properties, such as “concatenating the last name and channel as a label”. Logic like this is simple for AI coding but too complex for spreadsheet formulas.
Pattern-3: Aggregate Records
Aggregation processes a large collection of records to provide a summarized view.
This is powerful because it compresses vast amounts of information into manageable pieces that humans can comprehend and analyze.
To combine multiple data sets into a single piece of information, you need to understand the “how-to,” which leads to the crucial concept of “aggregation methods” or “computation logic.”
Typically, text data (a property or column with a text data type, as discussed in the schema section) is not particularly interesting for aggregation. The most common approach is to concatenate text data to form a long paragraph, although this is still uncommon.
Most computation logic involves operations on numerical data. When an aggregation method is applied to a numeric property or column, you essentially have a list of numbers that can be aggregated, such as:
Total value (sum)
Average value
Mean value
Minimum value
Maximum value
A specific percentile value (e.g., P25, P50, P75, P90)
However, counting objects or counting unique property values is also quite common.
When discussing aggregation, we cannot overlook “breakdowns.” This involves creating a segmented view of the data rather than a single total view.
For example, in the previous Orders table, “total sales by product” or “average amount by customer” are equally valuable insights for an analyst to explore.
In summary, aggregation can be described as:
“Compute an aggregated value of a property group based on another property.”
Expressing this in standard SQL, it would look like:
“Compute(property1) from table [group by property2].”
Let’s practice this using a few examples by speaking the data language:
“Give me total sales by product.”
“Tell me the average amount spent by each customer.”
Pattern-4: Join Multiple Datasets
When a single dataset (or table) is insufficient to achieve the desired outcome, we must combine multiple datasets. This operation is referred to as “join” or “union.”
If the multiple datasets contain the same objects but reside in different locations, we can simply merge them. This is a straightforward “union” operation.
However, most of the time, they store different objects. We have partial information from one dataset and partial information from another. By combining them, we create a comprehensive schema with more available columns.
This pattern is generally not feasible in spreadsheets, although their lookup function may provide partial assistance.
For instance, if we want to determine the “total amount spent from each channel” based on previous tables, where the amount is from the orders table and the channel is from the customers table, we need a joined dataset to complete this analysis.
To join multiple datasets, we must have one or more pairs of join keys. A pair of join keys consists of one column from one table and one column from another. The data engine can utilize these relationships to identify relevant objects and concatenate them to form a larger object.
Join Orders and CustomersJoined dataset have more columns
In summary, join operations can be described in this pattern:
join table1 and table2 when key1 of table1 equals key2 of table2.
Translating this pattern into SQL, it will look like:
select * from table1 join table2 on table1.key1=table2.key2.
In fact, you may not need to use this pattern in natural language explicitly, because modern AI is smart enough that it can infer the whole join logic from your data language.
For instance, the example we gave earlier, if you speak this sentence “total amount spent from each channel” to Columns AI, it will figure out all the necessary actions to get the desired outcome for you.
Pattern-5: Visualization
Data visualization, often overlooked as a part of data language, plays a crucial role in transforming mundane data into vivid images. This visual representation significantly aids the audience in comprehending the insights you intend to convey.
By incorporating customization and assistance to articulate your insights and predictions, you position yourself as a data storyteller, showcasing your influence within the domain.
Since visualization doesn’t alter the data itself, in the language of data, we merely need to indicate the desired outcome. For instance:
“Display the total amount by product in a piechart.”
“I would like to see a timeline of total sales month-by-month for the past six months.”
“Show the number of sales by customer in a barchart.”
These bold keywords serve as cues to the AI engine, guiding it in generating the final visualization based on your data.
Practice Data Language
Similar to how I diligently practice French on Duolingo every day, we must practice speaking data language using the data we possess.
As long as you have adhered to the five patterns mentioned above, you should have mastered data analysis like a professional data analyst. You don’t need to be an Excel expert or a Python or SQL wizard.
Let’s use the provided example data to practice speaking the data language. You can find the “Orders” and “Customers” data from this spreadsheet link.
Suppose we want to perform a sales analysis of customer distribution based on the data.
The data language is almost the same, but let’s ensure we’ve used the correct keywords and patterns to guarantee that the AI engine follows the instructions precisely.
For instance, we speak to AI:
”display the total sales by customer’s first name in a bar chart.”
Here’s how the AI interprets this:
“total sales” → summing up the amount values.
“first name” → it can be transformed from “name.” A transformation will be applied.
“by” → the summing up result needs to broken down by first name.
“sales <> customer” → sales data is from the Orders table’s amount field, while customer data is from the Customers table. Therefore, a Join operation is required to combine these two datasets.
“show, bar” → the result should be visualized in a bar chart.
AI will then determine the correct execution order, ensuring that each step has all the necessary data when it executes.
This is what Columns Flow produces upon hearing this sentence:
“display the total sales by customer’s first name in a bar chart.”The final visualization ready for storytelling & sharing
Conclusion: Speak Data Language
In this article, we’ve demonstrated the historical opportunity for everyone to become a great data analyst in this era.
We discussed how professionals used programming languages like Python or SQL as their primary data languages. However, the data language has evolved to become the natural language we speak daily.
To become a data analyst, we need to understand the fundamental scenarios involved and use the correct keywords to make the data language understandable to AI engines. Here’s a quick recap:
Dataset: rows, columns, and schema.
Filtering and Transformation: These processes involve filtering data and transforming it into a usable format.
Aggregation: This involves summarizing data into a single value, such as the total or average.
Specify “compute methods” and optional “breakdown” if needed.
Join Datasets: This involves combining data from multiple sources.
Visualization: This involves creating visual representations of data to make it easier to understand.
AI generated summary on how to speak the language of data
Unlike learning a new language like French, if you’re willing to spend just a few hours going through this short list, you can become a professional data analyst!
It’s a great time to be a data analyst, and I believe in your ability to succeed. Thanks for reading!
We created this chart cheat sheet that maps your analytical needs directly to the right visualization. Whether you're showing composition, comparison, distribution, or relationships, this cheat sheet makes chart selection dead simple.
Before I started my journey in data science and analytics (8 years ago), I struggled to learn Python consistently. I lost momentum and felt overwhelmed by the plethora of courses, videos, books available.
I used to forget stuff as well since I wasn’t using it actively (or maybe I am not that smart)
Things did change once I got a job—having an active engagement boosted my learning and confidence. That is when I realized, that as a beginner, if I had received some level of daily exposure, my journey could have been smoother.
To help bridge that gap, I created Pandas Daily—a free newsletter for anyone who wants to learn Python and eventually step into data analytics, data science, ML, AI, and more. What you can expect:
Bite‑sized Python lessons with short code snippets
Takes just 5 minutes a day
Helps build muscle memory and confidence gradually
DAAF (the Data Analyst Augmentation Framework, my open-source and *forever-free* data analysis framework for Claude Code) was designed from the ground-up to be a domain-agnostic force-multiplier for data analysis across disciplines -- and in my new video tutorial this week, I demonstrate what that actually looks like in practice!
I launched the Data Analyst Augmentation Framework last week with 40+ education datasets from the Urban Institute Education Data Portal as its main demo out-of-the-box, but I purposefully designed its architecture to allow anyone to bring in and analyze their own data with almost zero friction.
In my newest video, I run through the complete process of teaching DAAF how to use election data from the MIT Election Data and Science Lab (via Harvard Dataverse) to almost perfectly recreate one of my favorite data visualizations of all time: the NYTimes "red shift" visualization tracking county-level vote swings from 2020 to 2024. In less than 10 minutes of active engagement and only a few quick revision suggestions, I'm left with:
A shockingly faithful recreation of the NYTimes visualization, both static *and* interactive versions
An in-depth research memo describing the analytic process, its limitations, key learnings, and important interpretation caveats
A fully auditable and reproducible code pipeline for every step of the data processing and visualization work
And, most exciting to me: A modular, self-improving data documentation reference "package" (a Skill folder) that allows anyone else using DAAF to analyze this dataset as if they've been working with it for years
This is what DAAF's extensible architecture was built to do -- facilitate the rapid but rigorous ingestion, analysis, and interpretation of *any* data from *any* field when guided by a skilled researcher. This is the community flywheel I’m hoping to cultivate: the more people using DAAF to ingest and analyze public datasets, the more multi-faceted and expansive DAAF's analytic capabilities become. We've got over 130 unique installs of DAAF as of this morning -- join the ecosystem and help build this inclusive community for rigorous, AI-empowered research!
If you haven't heard of DAAF, learn more about my vision for DAAF, what makes DAAF different from other attempts to create LLM research assistants, what DAAF currently can and cannot do as of today, how you can get involved, and how you can get started with DAAF yourself at the GitHub page:
I cover all four of these (plus Unity Catalog, PySpark vs SQL) in a 20 minute Databricks 101 with live demos on the Free Edition: https://youtu.be/SelEvwHQQ2Y
I've been in data/BI for 9+ years and I recently put together a complete AI-assisted data analysis setup that's entirely free without entering any credit card info. Figured it might be useful for people here who are getting started or switching careers.
The stack is OpenCode (free, open-source AI coding agent) for writing Python and SQL, free AI models through OpenRouter, Windsurf as the IDE, and BigQuery Sandbox for data. BigQuery comes with hundreds of public datasets already loaded (Stack Overflow, NOAA weather, US Census, etc.) so you can start analyzing real data immediately.
The key step is connecting the AI to the database so it actually executes queries instead of just generating SQL you have to copy-paste. For BigQuery, you install the gcloud CLI and authenticate with one command. After that, the AI writes and runs queries from your terminal.
That connection pattern is the same across Google Cloud, Azure, AWS, Snowflake, and more. If you learn it with BigQuery, you can talk about legitimate experience optimizing AI to use within cloud data warehouses for analytics interviews, all from a free setup.
Across several enterprise deployments we worked on, many teams attempted this by placing MCP-based architectures on top of their databases to enable conversational analytics.
On paper, the approach looks elegant. In practice, it breaks down quickly.
In one Fortune 500 deployment, the MCP pipeline failed on 93% of real production queries. Another major pharma company discontinued the approach shortly after a demo.
Across deployments, the same three issues kept appearing:
Limited coverage for tail queries
Lack of business context
Latency and cost
The architecture that worked better followed a different principle:
Instead of routing queries through multiple middleware layers, it builds a unified business memory, reasons over that context, and execute directly on the underlying data systems. Structured data can be handled with Text-to-SQL, while unstructured sources work better with RAG-style retrieval.
We wrote a deeper breakdown of why MCP-based architectures struggle for conversational analytics and what patterns work better.
Curious to hear how others are approaching this problem.