Learning Mathematics Through Programming

This page is primarily written for students who are learning to program and who have a complicated history with mathematics. It is also useful for teachers thinking about how to design courses that involve both.

The Problem with How Mathematics Gets Taught

Most students who arrive in a further education IT course with a fear of maths didn't arrive that way by accident. They had a sequence of experiences — usually starting somewhere in secondary school — where mathematics became increasingly abstract, increasingly high-stakes, and decreasingly connected to anything they cared about. The subject started to feel like a series of procedures to be memorised and performed under pressure, rather than a way of thinking about things.

This is not a personal failing. It is almost entirely a consequence of how the subject tends to be delivered.

The frustrating thing is that mathematics, in practice, is almost never experienced this way by people who use it regularly. Programmers, data analysts, engineers, and scientists encounter mathematical ideas in context — as tools that do useful things. The abstraction comes later, once the concrete application has made the need for it clear. In a classroom, this is usually reversed: abstraction first, application much later, if ever.

Programming creates an opportunity to fix this.

Why Programming Helps

When you write a program, you are working with mathematical objects all the time — even if nobody calls them that. Variables, functions, conditionals, loops, and data structures are all mathematical ideas. The difference is that in a programming context, you can immediately see what they do. You write the code, you run it, something happens. The feedback is fast and the consequence is concrete.

This changes the emotional relationship to the mathematics considerably. Instead of encountering a function as an abstract definition to be memorised, you encounter it as something you build and use. Instead of worrying about whether you've "got it right" in the way an exam demands, you're watching a program behave (or misbehave) and trying to understand why.

Some specific ways this plays out in practice:

Variables and algebra. Students who struggle with algebraic notation often have no difficulty understanding that a variable in a program holds a value that can change. That understanding is algebraic thinking. Making the connection explicit — naming it — can be surprisingly powerful.

Functions. The mathematical concept of a function (an input, a rule, an output) is abstract when presented symbolically. In a programming context, students write functions, call them with different inputs, and see different outputs. The concept becomes intuitive before it becomes formal.

Iteration and sequences. Loops are a natural place to introduce sequences and series. A student who has written a loop that sums a list of numbers has done something mathematically meaningful. With the right framing, they can see that.

Visualisation. Programming gives you tools to draw things — graphs, plots, diagrams. Mathematical relationships that are opaque as equations often become clear when plotted. This is not a shortcut around rigour; it is how mathematical intuition actually develops.

Probability and statistics. These are perhaps the clearest case. Running a simulation — even a simple one — to model a probabilistic event gives students a feel for what probability means that no amount of formula work tends to produce.

What This Looks Like in Practice

At Dublin College Dundrum, I've run courses where programming and mathematics are taught as integrated modules rather than separately. The approach involves designing tasks where the programming and the mathematics are genuinely inseparable — not just "here is a programming task, and by the way it uses some maths," but tasks where understanding one requires engaging with the other.

A few examples of what this can look like:

Writing a program to calculate and plot a sequence of numbers, then asking: what happens as the sequence gets longer? What value does it approach?
Using a loop to simulate rolling a die many times, then comparing the simulated results to the theoretical probability. Why don't they match exactly? What happens when you increase the number of rolls?
Building a simple function to convert between units (temperature, distance, currency), then asking: what is this function doing mathematically? Can you describe it without the code?

The tasks are chosen so that the programming provides the context and the mathematics provides the explanation. Students who would disengage from a worksheet of calculations often stay engaged when the same calculations are embedded in a program they've written themselves.

A Note on Confidence

The goal is not to disguise mathematics as something else. Students who go through this kind of course eventually do encounter the formal notation, the abstract definitions, and the exam-style problems. The difference is that by then they have some intuition to anchor those things to.

Confidence in mathematics is not really about knowing lots of facts or procedures. It is about having enough experience of mathematical ideas — in enough different forms — that the formal presentation doesn't feel entirely alien. Programming is one particularly good way to accumulate that experience, because the feedback is immediate, the stakes per individual attempt are low, and the problems are ones students are often genuinely interested in solving.

It also helps that programming is unambiguous about what you don't know. When a program doesn't work, you have to figure out why. This turns out to be good mathematical practice: identifying where your understanding breaks down, forming a hypothesis, testing it. Students who learn to debug code are learning to think mathematically, whether or not anyone frames it that way.

For Teachers

If you're a teacher thinking about how to introduce integration between programming and mathematics, a few observations from experience:

The most important thing is that the integration feels genuine to students. If the mathematics is clearly an add-on — something the teacher is required to mention because the syllabus says so — students will notice and respond accordingly. The tasks need to be designed so that the mathematical understanding is actually necessary for the programming task to make sense.

Assessment matters enormously here. If the programming and the mathematics are assessed entirely separately, students will treat them as entirely separate. If there are assessment moments that require demonstrating understanding of both together, the integration becomes real for students in a way it otherwise doesn't.

Finally, this kind of approach tends to require more upfront design work, and it sometimes feels slower in the early stages of a course because you're building intuition rather than covering procedures. In my experience, this pays off — but it is harder to demonstrate in the short term, which can be a challenge in institutional contexts where progress is measured in terms of content covered.

More on the consulting page if you're interested in discussing this for your institution, or have a look at the AI workshops to see how I approach professional development more broadly.