Most advice tells you to "just learn Python" — but that's wrong if you're targeting a business analyst or reporting role. This lesson shows you exactly which tool to learn first based on the actual job you want, with a real decision framework backed by job market research.
You've decided you want to work with data. Maybe you've been scrolling through job listings and noticed that some require Python, others list SQL as a must-have, and almost all of them mention Excel somewhere. You open three browser tabs — one for a Python tutorial, one for a SQL course, one for Excel tips — and immediately feel overwhelmed. Which one do you actually start with?
This is one of the most common questions from people entering the data field, and it's also one of the most poorly answered. Most advice you'll find online falls into two camps: either "just learn Python, it's the future" or a vague "it depends on your goals." Neither of those helps you make a real decision on a Tuesday night when you're trying to figure out where to put your next 100 hours of learning.
By the end of this lesson, you'll have a clear, defensible answer to that question — one based on the actual job role you're targeting, the real tasks each tool is built for, and an honest assessment of what you'll encounter in those first six months on the job. We're going to treat this like a strategic decision, not a preference poll.
What you'll learn:
None. This lesson assumes you have zero experience with any of these tools. All you need is a general interest in working with data and some sense of the kind of role you're drawn to — even if that's fuzzy right now, we'll sharpen it as we go.
Before we compare anything, let's dismantle an idea that will waste your time if you hold onto it: the idea that one of these tools is objectively superior and that smart people learn that one.
Python, SQL, and Excel are not competitors in the way that, say, two different smartphone brands compete. They're more like a surgeon's scalpel, a hospital's records system, and a clipboard. Each one exists for a specific set of problems. A surgeon doesn't debate whether to replace the scalpel with a clipboard — they use different tools for different jobs.
Here's the honest picture at a glance:
The reason this matters before anything else: the "right" tool is determined by what problem you need to solve, not by some ranking of prestige or technical sophistication. With that cleared up, let's go deeper into what each one actually does.
SQL (pronounced either "sequel" or "S-Q-L" — both are acceptable) stands for Structured Query Language. A query is simply a question you ask a database. The database answers by returning rows of data that match your criteria.
Here's a concrete example. Imagine you work at an e-commerce company. The company's customer data, order history, and product catalog all live in a relational database — think of this as a collection of organized spreadsheets that are linked together by shared identifiers, like a customer ID number. You can't just open this database in Excel. You need SQL to talk to it.
A simple SQL query looks like this:
SELECT
customer_id,
order_date,
total_amount
FROM orders
WHERE order_date >= '2024-01-01'
AND total_amount > 100
ORDER BY order_date DESC;
Even if you've never written SQL before, you can probably read this. It's asking the database: "Give me the customer ID, order date, and total amount from the orders table, but only show me orders from 2024 onward where the customer spent more than $100, and sort them newest first."
That readability is not an accident. SQL was designed in the 1970s explicitly so that non-programmers could interact with data. It has remained dominant for decades because almost every organization in the world stores structured data in relational databases, and SQL is the universal language to access it.
Where SQL shows up professionally: Whenever an analyst needs to pull a dataset before analyzing it, a data engineer needs to transform records between systems, or a business intelligence developer needs to feed a dashboard, SQL is involved. It's the plumbing of the data world.
Python is a programming language — a general-purpose one, meaning you can use it to build websites, automate files on your computer, train machine learning models, and yes, analyze data. The data-specific capabilities come mainly from libraries: pre-built collections of code that other people wrote and packaged for you to use.
The two most important libraries for data work are pandas (for manipulating tabular data, like spreadsheets) and NumPy (for numerical computation). For visualization, you'd reach for matplotlib or seaborn. For machine learning, scikit-learn.
Here's a small Python example using pandas to read a CSV file (a common plain-text data format) and calculate average order value by customer:
import pandas as pd
# Load a CSV file into a DataFrame (think: a smart, programmable spreadsheet)
orders = pd.read_csv('orders.csv')
# Filter to only orders from 2024
orders_2024 = orders[orders['order_date'] >= '2024-01-01']
# Calculate average order value per customer
avg_order_by_customer = (
orders_2024
.groupby('customer_id')['total_amount']
.mean()
.reset_index()
.rename(columns={'total_amount': 'avg_order_value'})
)
print(avg_order_by_customer.head(10))
Notice that this code is doing something similar to the SQL query above — filtering and aggregating data — but it's doing it on a file you've already downloaded, not a live database. That distinction matters. Python operates on data in memory (on your computer), while SQL operates on data at the source (the database server).
Python also lets you do things SQL simply cannot: build a machine learning model that predicts which customers are likely to churn, write a script that automatically pulls data every morning and emails a summary report, or scrape data from a website and clean it up. It's a much larger tool with a steeper learning curve.
Where Python shows up professionally: Data science, machine learning engineering, advanced analytics, data pipeline automation, and anywhere someone needs to go beyond querying and into building.
Excel is a spreadsheet application made by Microsoft. You open it and see a grid of cells. You type data, write formulas, and create charts. This sounds simple because the core interface is simple — but the depth beneath that surface is enormous.
Modern Excel (especially Microsoft 365) supports:
Here's what an Excel formula for looking up a customer's region based on their ID might look like:
=XLOOKUP(A2, CustomerTable[CustomerID], CustomerTable[Region], "Not Found")
This searches the CustomerID column in a table named CustomerTable for the value in cell A2, and returns the matching Region. If no match is found, it shows "Not Found." No programming knowledge required — you just need to understand what the formula arguments mean.
Excel is often dismissed by technical people as "not a real data tool." This is a mistake. The majority of business decisions in the world are made by people looking at Excel spreadsheets. A VP of Finance isn't running Python scripts. A regional sales manager isn't writing SQL. They're opening Excel files that someone built for them — and that someone needed to know Excel deeply to do it well.
Where Excel shows up professionally: Business analysis, financial modeling, operations, reporting, any role that sits close to business stakeholders rather than engineering systems.
Now that you understand what each tool does, let's map tools to roles. Read through these descriptions and notice which one sounds like the work you want to do day-to-day.
A data analyst's core job is to answer business questions with data. You get a question like "Which product categories are underperforming in the Northeast region?" and you need to pull the data, analyze it, build a clear visualization, and present findings to a non-technical stakeholder.
Start with SQL. Almost every data analyst role — from startups to enterprises — will require you to write SQL to pull your own data. You will not have an engineer handing you clean datasets. You need to go get them yourself.
Layer in Excel next. Once you can pull data, you need to communicate it. Excel is the universal language of business presentations. Learning pivot tables and building clean, readable charts will make you immediately useful.
Add Python later as your analysis grows more complex — when you need to automate a recurring report, run a statistical model, or handle datasets too large for Excel to process without crashing.
Target tools in order: SQL → Excel → Python
A business analyst is often closer to the business than to engineering. Your job involves defining requirements, tracking KPIs (Key Performance Indicators — the numbers a business monitors to gauge health), and building reports and dashboards that non-technical leadership can use.
Start with Excel. Business analysts spend enormous amounts of time in Excel — building models, creating scenario analyses, tracking budgets, and building the kind of formatted, polished reports that get presented in board meetings.
Add SQL second. The better business analysts pull their own data rather than waiting for someone else to get it for them. Even basic SQL skills will make you dramatically more capable and faster.
Python is optional in most business analyst roles — useful if your organization uses Python for automation, but not a hard requirement for most BA positions.
Target tools in order: Excel → SQL → Python (optional)
A data engineer builds the pipelines that move data from source systems to the places analysts and data scientists use it. Think of them as the people who build and maintain the plumbing so other people can turn on the tap.
Start with SQL. Data engineers write complex SQL constantly — building transformation logic, writing queries that aggregate and reshape data inside database systems, and creating the tables and views that analysts query.
Move to Python quickly. Data engineering involves writing scripts that automate data movement, scheduling jobs, handling errors, and working with APIs (Application Programming Interfaces — the way software systems talk to each other). Python is the dominant language for this work.
Excel is peripheral in most data engineering roles. You should know it exists and be able to open files, but you won't be building spreadsheet models.
Target tools in order: SQL → Python → (Excel awareness only)
A data scientist builds predictive models, runs experiments, and uses statistical methods to extract insights beyond what standard reporting can show.
Start with Python. Data science is Python-first. The entire ecosystem of machine learning libraries — scikit-learn, TensorFlow, PyTorch, XGBoost — is Python-based. You'll spend the majority of your time writing Python.
Add SQL early. Even data scientists need to pull their own data from databases. SQL is a prerequisite skill that you'll use constantly even if it's not your primary tool.
Excel is minimal — data scientists occasionally use it for quick-and-dirty checks or to share results with non-technical colleagues, but it's not where the real work happens.
Target tools in order: Python → SQL → (Excel awareness only)
Here's something the "which tool should I learn" debate almost always misses: in practice, these tools appear in the same workflow. They're not substitutes — they're collaborators.
Consider a realistic analyst workflow at a retail company:
None of these steps replaces the others. The SQL step can't be done in Excel (you can't query a database from a spreadsheet without setup). The charting step doesn't need Python. Each tool is doing what it's best at.
Tip
When you're learning, don't worry about learning all three simultaneously. Pick one, go deep enough to actually use it at work, then layer in the next. Spreading yourself thin across all three at once means you'll be mediocre at all of them instead of functional in one.
Let's make this concrete. Answer these three questions honestly:
Question 1: What job titles am I actually applying for in the next 6-12 months? Go to LinkedIn, Indeed, or a job board of your choice. Search for the role you want. Open 10 job listings. Write down every tool or technology mentioned in the "Required" section. Don't look at "Preferred" yet — just Required. Tally them up.
If SQL appears in 8 out of 10: start with SQL. If Python appears in 7 out of 10 and SQL in 5: start with Python, begin SQL within 3 months. If Excel appears constantly and Python rarely: start with Excel.
Question 2: What kind of work do I want to do every day?
Question 3: How much time do I have per week to learn? This matters more than people admit. Python has a steeper learning curve. If you have 5 hours a week to learn, starting with Python means you might spend 6 months before you can do anything useful at work. SQL can get you to "useful at work" in 6-8 weeks. Excel can get there even faster.
Warning
Don't choose a tool because it sounds impressive. "I'm learning machine learning" sounds better at a party than "I'm learning SQL," but if your target role doesn't require machine learning, you're collecting prestige points, not job skills.
This exercise doesn't require installing anything. It's a research and planning exercise that will leave you with a concrete answer before you close this tab.
Step 1: Open LinkedIn Jobs (or any job board). Search for one of these titles based on your interest:
Step 2: Open exactly 10 job listings for that title in your geographic area (or "Remote" if that's your preference). For each listing, note every technical tool listed under Required or Minimum Qualifications.
Step 3: Create a simple tally. You can do this on paper or in a notes app:
Tool | Appearances in 10 listings
----------- | --------------------------
SQL | ___
Python | ___
Excel | ___
R | ___
Tableau | ___
Other: ___ | ___
Step 4: Based on your tally and the role frameworks above, write one sentence:
"I am targeting [role title]. Based on real job listings, I will start with [tool] because it appears in [X] out of 10 listings I reviewed and aligns with [specific type of work] I want to do."
That sentence is your learning plan. Pin it somewhere visible.
Mistake 1: Choosing Python because it's prestigious, not because it's necessary. This is extremely common. Python has a culture of hype around it in the tech world. But if you're targeting a business analyst or entry-level analyst role at a company that runs on Excel and reports in Tableau, spending six months learning NumPy and pandas before you know how to write a pivot table is backwards. Check the job listings. Let the market tell you what's needed.
Mistake 2: Treating learning as sequential instead of additive. Some people think: "I'll master Python completely, then start SQL." This isn't how it works in practice. You learn enough Python (or SQL, or Excel) to do something useful, then you start layering in the next tool as real need arises. "Mastery" is a moving target — the goal is functional competence that gets you hired.
Mistake 3: Ignoring Excel because it doesn't feel technical enough. Excel literacy is genuinely underrated. The ability to receive a messy spreadsheet from a client, clean it with Power Query, build a pivot table that answers their question, and format it as a clear chart is a skill that will make you immediately valuable in most business environments. Don't skip it because it doesn't sound like "data science."
Mistake 4: Trying to learn all three at once. Splitting your study time three ways when you're a beginner means you spend months without being able to do anything useful in any tool. Pick one. Get functional. Then expand.
Mistake 5: Confusing "learning a tool" with "watching videos about a tool." You learn data tools by using them on real (or realistic) data problems — not by watching someone else use them. If you haven't written a query, typed a formula, or run a script yourself, you haven't learned anything yet. Active practice is non-negotiable.
Let's bring it together. Here's what you now understand that you didn't an hour ago:
The role-based starting points:
Your immediate next steps:
The best tool to learn first is the one that gets you hired. Let the role guide the choice, let the job listings validate it, and then go learn it with intention.