DEV Community: Ladislav Szép

You can't teach a variable with a maths problem

Ladislav Szép — Mon, 26 Oct 2026 12:47:31 +0000

I can write Python. I have shipped a web application in it, with a test suite and a deployment pipeline and arguments about coverage.

I have also never finished a beginner programming course. Not one.

Not because they were too hard. Because somewhere in the first week, every single one of them asked me to solve a maths problem before it had told me what a variable was.

The genre
You know the exercises. Every course has them, in roughly this order:

print the numbers 1 to 100, but Fizz, but Buzz
is this number prime
the first n Fibonacci numbers
a pyramid of hashes, n rows tall
convert Celsius to Fahrenheit
sum every even number below one thousand
Look at what's actually being asked. The programming content of "is this number prime" is a loop and a conditional. The rest of it — why you only need to check up to the square root, why 1 isn't prime, what a factor is — is arithmetic that has nothing to do with Python and everything to do with whether you liked maths at school.

Two difficulties, stacked, with no way to tell them apart
When a learner fails that exercise, something has gone wrong. But which thing?

They might not understand for. They might not understand modulo. They might understand both perfectly and have no idea what a prime number is for. From the outside these look identical: an empty editor and somebody who has stopped.

And here is the part that actually costs the industry people. The learner diagnoses it themselves, immediately and wrongly:

I was never any good at maths. I'm probably not cut out for this.

That conclusion is false. Most professional Python is strings, dictionaries, HTTP and file handling. I have written far more dict.get than modulo in my life. But the learner has no way to know that yet, because the only programming they've been shown is maths, and they've just failed at it.

They don't bounce off programming. They bounce off arithmetic wearing programming's coat, and they never find out the difference.

So why does every course do it?
This is the part I didn't expect, and it's the reason I'm writing this rather than just complaining.

It isn't pedagogy. It's marking.

A maths exercise has exactly one right answer. is_prime(7) returns True, and there is no argument about it. You can check that with one line of test code, and it will be correct for every learner, forever.

Now try to auto-mark this instead:

Print a shopping list with a total at the bottom.

How many valid programs are there? Hundreds. Do you accept a trailing newline? Two spaces instead of one? "Total: 12" or "Total: 12.00"? A dictionary or two parallel lists? A function or straight-line code?

Every one of those is a correct answer from a beginner, and a naive string comparison fails most of them. The learner then gets marked wrong for being right, which is worse than being bored.

Maths exercises aren't in your first week because they teach well. They're in your first week because they're cheap to grade. It is a testing constraint that leaked into the curriculum, and it has been there so long that everyone mistook it for teaching.

What the alternative actually costs
I've been building a course on the other side of that trade, and the engineering is where all the cost lives.

Three rules fell out of it, and the third surprised me.

Checks are authored, not generated. Every check carries a sentence a human wrote about what was expected, in the lesson's own vocabulary. No "AssertionError: expected 'Total: 12' but got 'Total: 12.0'".

A check may show what it saw, never what it is. This is the one I had to write down in the code, because it is very tempting to break:

class CheckResult(BaseModel):
"""One check's verdict, in the only terms the learner ever sees.

`label` is authored by hand per check and `detail` carries observed
values. Check source never appears in either.
"""

label: str
passed: bool
detail: str | None = None

Show a learner the test that failed them and you have not taught them to solve the problem. You have taught them to satisfy the test, which is a different and much worse skill, and one that survives into their professional life.

Several right answers must pass. This is the expensive half. It is not a feature you add; it is a constraint on every single task you write. Some tasks get a hidden pytest case that imports what the learner wrote and calls it. Some normalise whitespace before comparing. Some can't be auto-marked at all and have to be rewritten until they can.

That is slow. 135 lessons in, I can tell you the authoring is three or four times the work of writing the maths version. That cost is the real reason the maths version won.

What goes in the first week instead
Here's a whole lesson, near the very start:

score = 10
print("score: " + score)
TypeError: can only concatenate str (not "int") to str
That's it. That's the lesson.

It teaches types, and it teaches them in the only way that sticks: the learner has already been bitten, so there is a reason to care about the answer. No arithmetic. No domain knowledge. Nothing to be bad at except the thing actually being taught.

The rule I ended up with is that where a concept exists because something doesn't work, show the failure first. A sentence about types teaches almost nothing. A TypeError with your own name on it teaches it permanently.

Where I'll concede
Maths exercises are not useless. If your goal is a computer science degree, discrete maths is load-bearing and you should meet it early. Those courses are not wrong — they are university courses doing a university course's job. The mistake is recommending them as the universal first step to somebody who wants to build a thing.

"But programming is maths." Logic, yes. Arithmetic, mostly no. I want a beginner to meet boolean logic in week one. I do not want them to meet modular arithmetic in week one, and those two have been bundled together for forty years.

I have no retention data. None. I have a design argument, one learner, and 135 lessons. Anyone telling you their pedagogy is proven after a year is selling something. If this is wrong, it'll be wrong in a way that shows up in a year, not in this post.

And the cost is real. If you are building a course and you take this advice, you are signing up for roughly four times the authoring work per lesson and a check design you will revisit repeatedly. I think it's worth it. I also understand completely why the industry decided otherwise.

This is part of LexipawsPY, a free Python course I'm building. Every lesson is free and stays free — the whole course, the drills, the hints and the solutions. It's at py.lexipaws.eu if you want a look, though fair warning: it's still being written. 135 lessons today, through loops, lists and tuples, stopping just before dictionaries.

If you learned to code fine through FizzBuzz and think I'm overthinking this, I'd genuinely like to hear it — I'm aware I might be generalising from one person who doesn't like maths.

You can't quiz someone into writing tests

Ladislav Szép — Sun, 25 Oct 2026 20:08:40 +0000

Every course I've taken has a lesson about testing. It explains what a unit test is, has you write one into a box, marks it green, and moves on. I passed several of those lessons. I did not start writing tests.

The same is true of git. There's a lesson on commit messages, usually with a multiple-choice question about the imperative mood. Nobody's commit history changes because of it.

That's not the courses being lazy. It's that these aren't facts, they're habits, and a habit is visible in a year of work rather than in one answer. You can quiz somebody on what a conventional commit is. You can't quiz them into writing one on a Tuesday when they're tired.

So when I built my own Python course, I left that lesson out and wrote something else instead: the course reads your repositories and grades what's already there.

What it actually does
There are seven probes and eleven awards between them. Each probe opens a repository you point it at, runs the tools that repository already uses, and reads the output. Awards pay experience, which is what the XP column below is.

Probe What it looks for XP
git commit subjects that follow a convention 40
git branches named for their work 25
lint a tree your linter has nothing to say about 40
lint formatting nobody has to argue about 25
tests a test suite that exists at all 50
tests a suite that is actually green 75
types signatures that say what they mean 40
docs a README someone else could walk through 25
docs decisions written down where you can ask about them later 40
ci something other than you checking the work 30
ci a pipeline that stays green 45
Totals put you on a ladder: Starting out, then Finding the habits at 100, Habits that hold at 250, Dependable at 500, Seasoned at 1000.

Every award carries evidence — the actual number it saw — because an award you can't check is a sticker.

The three problems that were actually interesting
Writing the probes was the easy half. The hard half was deciding what a probe's answer means.

"I found nothing" and "I couldn't look" are different answers
The CI probe wants to know whether your last few pipeline runs were green. That needs the GitHub CLI installed, signed in, and a network.

If gh isn't there, the probe could reasonably say "no green pipeline". That's a disaster: the first time you scan on a laptop without gh, the course quietly takes away an award you earned, for a pipeline that is still green.

So a probe returns one of two things, and the difference is load-bearing:

def evaluate(self, repo: Path) -> list[Award] | None:
"""What this probe finds now, or None if it could not look.

The difference matters. An empty list means the repository
does not earn this, and the scan takes the award away. None
means the probe could not run at all, and the scan leaves
what was already held alone - losing an award because ruff
was not installed today would be a lie about the work.
"""

A list — possibly empty — means I looked, and this is what's there. None means I couldn't answer, and the scan leaves whatever was already held alone.

It ended up as two probes rather than one, because "does a workflow file exist" can always be answered and "were the last runs green" often can't:

Two probes rather than one, because they fail differently. [...] One probe for both would revoke a green pipeline every time gh was missing, which is the lie the None return exists to prevent.

Awards have to be revocable, and that's uncomfortable
The obvious design is that experience only goes up. It feels better, it's what games do, and it avoids an awkward conversation.

It's also a lie with a delayed fuse. If you earn "a suite that is actually green" and then break your tests and leave them broken, a number that still says otherwise is wrong — and you're the one person guaranteed to find out.

So a scan can take an award back:

An award that survives the work that earned it being undone is a lie the learner will eventually notice.

A probe can't do this, because a probe only sees now. Only the scan knows what was held before, so only the scan can remove it.

Re-earning is not re-paying
If running a scan twice paid twice, the meter would measure how often you run scans.

So an award's id identifies the achievement, not the occasion. Scan again and the evidence is refreshed, so it describes your repository as it stands today — but the date you first earned it is left alone, and nothing is paid twice.

The threshold is 80%, on purpose
The git probe looks at your last 100 commit subjects and wants 80% of them to follow the convention. Not all of them.

I went back and forth on this and settled it with a comment that is still in the file:

An occasional "wip" is a human being, not a failure of craft.

A tool that demands perfection to acknowledge a habit teaches you to perform for the tool. The same reasoning sets the floor at ten commits: below that there's no habit to judge, just a handful of commits.

Why it runs on your machine and not on a server
Here's the part I'd have got wrong if I'd built it the obvious way.

Running these probes means running your test suite. On a hosted service, that is executing a stranger's code on my server on their say-so — the exact thing the project's sandboxing decisions exist to prevent. So the hosted version refuses:

403 — The craft meter runs real test suites, so it is for a local install
So it runs where your code already is: you run the application on your own machine and point it at your own repositories. Your code is never uploaded, because there is nowhere to upload it to. No token, no OAuth scope, no third party with read access to your private repos.

One honest caveat, since this is the part people ask about: the local install isn't something you can go and get yet. The hosted course is live, but the craft meter is the half that needs the application on your own machine, and packaging that up is still ahead of me. If this is the bit you want, say so and I'll know it's worth doing sooner.

I'd like to claim that as a privacy feature. Honestly, it's a consequence — I couldn't safely build it the other way, and the constraint produced the better design. That happens more often than I expect it to.

What it doesn't do
It doesn't read your code and tell you it's good. It reads what your own tools say about it. If your linter is configured to permit everything, a clean tree means very little, and the probe can't tell.

It won't make you employable on its own. It measures habits an interviewer can also see in thirty seconds of scrolling your GitHub — which is rather the point. Those are the habits worth having, so they are the ones worth counting.

And it is genuinely slow. It runs pytest over every repository you give it. That's not a bug to optimise away; it's what makes the number mean something.

This is part of LexipawsPY, a free Python course I'm building. Every lesson is free and stays free — the whole course, the drills, the hints and the solutions. It's at py.lexipaws.eu if you want a look, though fair warning: the beginner path is still being written. It runs to sixty-eight lessons today, through loops, lists and tuples, and stops just before dictionaries.

If you've built something similar, or you think grading habits is a terrible idea, I'd like to hear it.