When to leave the spreadsheet
On this page
Some of you have spent years in Excel and are faster in it than you will be in anything this course teaches for several weeks. The usual framing puts a spreadsheet at the beginner end and code at the expert end, and that framing is wrong. A complicated acquisition model belongs in a spreadsheet. A five-line script that downloads one file every Monday morning does not. The kind of work decides it, and you can learn to tell the two kinds apart.
What you already know#
Almost everything you do to a table is one of a handful of operations, and they are the same operations in every tool. You have been doing them under Microsoft's names for them.
| In Excel | In SQL | In polars |
|---|---|---|
| Filter | WHERE |
.filter(), as in df.filter(pl.col("revenue") > 1000) |
| Sort | ORDER BY |
.sort() |
| XLOOKUP or VLOOKUP | LEFT JOIN |
.join(..., how="left") |
| PivotTable | GROUP BY |
.group_by() |
| Remove Duplicates | DISTINCT |
.unique() |
| SUMIFS and COUNTIFS | WHERE plus sum or count |
.filter() plus .sum() or pl.len() |
You already do these by clicking. Writing them down is what changes.
Full reference: Excel to SQL and Excel to Python, which give each of these a cell or a query you can run against the course warehouse. pandas, the other Python table library, maintains the same thing in the other direction, comparison with spreadsheets and comparison with SQL.
If you have built a query in Power Query, you have already assembled one of these. The Applied Steps list beside your query is a pipeline: load this, promote the headers, change these types, filter these rows, merge in that table, group by region. A SQL query and a polars chain are that same list written as text instead of clicked into a pane.
When to leave#
Any one of these on its own is usually not enough to move. Where several show up together, the work has outgrown the sheet.
You will run this again. A monthly report is the same analysis 12 times, and every repetition is another chance to paste into the wrong column. Code runs the same steps the same way each time, so the work you put in for January covers December as well.
The data is somewhere a sheet cannot reach. A worksheet stops at 1,048,576 rows, and plenty of real tables are larger. Beyond size, the data may live in a database that answers questions in SQL, or behind an API that answers in JSON. Getting it into a sheet at all becomes the hard part, and once it is there you have a copy that starts going stale.
Somebody has to see how the number was produced. A workbook keeps its formulas, and Excel's change history keeps only recent edits, with no reason attached. It will not tell anyone why you deleted a row or which of four sheets you copied from. When you are asked six weeks later how you got 37 percent, you answer by running the script again. Every deliverable in this course that states a number has to carry a section called "How I know these numbers are right", and that section is much easier to write when the process is a file.
The checking is past what a person can do by hand. With 200 rows, you can scroll and see that something is off. With 200,000, you cannot, and the errors that matter are the ones that look fine.
What a spreadsheet is better at#
Entering and correcting data by hand. There is no good replacement for a grid when a human being is the source of the values.
A model somebody else will open, change one assumption in, and read the new answer off immediately. If your reader needs to do that, the workbook is the product and rebuilding it in Python will make it worse.
A quick look at a small table. Opening a file and sorting a column takes seconds.
Using both#
A common shape is to do the loading, joining and aggregating in SQL or Python, then write the result out as an .xlsx file for the person who asked. polars has .write_excel() for exactly this, once you uv add xlsxwriter. Your reader gets the thing they know how to use, and you keep a script that can produce it again.
Where this course takes it#
The operations above are taught properly in the handbooks, one for Python and one for SQL. If you want to know which of these tools employers are actually naming, What employers ask for counts them across 24 Boston analyst postings.
Last updated: Sunday, 11/1/2026