DEV Community: Sohaib Hassan

How I Got 40,000 Facebook Followers in Just Two Months

Sohaib Hassan — Wed, 02 Sep 2026 07:01:08 +0000

Two months ago, my Facebook page had a small, quiet following. Today, more than 40,000 people follow it. I did not expect this to happen so fast, and I do not believe there is a secret trick behind it. But I do understand why it happened, and I want to explain it honestly, because the reason is actually more useful than a trick would be.

What I Actually Post

My page is called PlotLab. I use it to turn mathematics into animation, using a Python library called Manim, the same one that powers the diagrams in my other posts here. A definition that feels dry on a whiteboard becomes something a student can actually watch happen. A limit is not just a symbol anymore. You see a point moving closer and closer, step by step, until the idea makes sense on its own.

This is not a new idea. Channels like 3Blue1Brown made this style popular for a general audience. What I do is narrower and, I think, more practical: I build these animations for the exact topics that undergraduate and school-level students struggle with the most, the ones I see them struggle with in my own classroom, every single semester.

Why It Actually Worked

Here is the part I think matters most. I do not build an animation and then hope it is useful. I teach first, in a real classroom, with real students in front of me. When I notice the same confusion coming up again and again, on the same topic, I build the animation for that exact topic. Only after that does it go on Facebook or Instagram.

So the content was never designed for social media first. It was designed for my own students first, and social media is simply where it happens to travel well too. I believe this order matters. It means every animation already solved a real confusion for a real student before a single stranger on the internet ever saw it.

What People Actually Tell Me

The most encouraging part of the last two months has not been the follower count. It has been the messages. Almost every day, someone writes to me in the comments or in my inbox to say that a concept they had struggled with for a long time finally made sense after watching one of these animations. Some are students preparing for exams. Some are people revisiting mathematics years after leaving school, just out of curiosity. The message is almost always some version of the same thing: this is the first time this idea actually made sense.

That kind of feedback is why I keep making these, far more than the follower count itself.

Where to Find These Animations

The main page is on Facebook, where the 40,000+ follower community lives. The same animations are also on Instagram, which has grown to 15,000+ followers of its own.

Two Things I Built Because of This

Once people started asking for more than just short videos, I built two things to answer that.

The first is for people who want to learn to build animations like these themselves. I wrote everything I know about getting started with Manim into a single guide, from installing it correctly to the mistakes that waste the most time when you're new to it. It's called the Manim CE Beginner's Handbook, and it's written the same way I'd explain it to a student sitting next to me, not the way the official documentation explains it.

The second is for students specifically preparing for IGCSE, O-Level, and GCSE exams. I built a complete set of notes covering the full syllabus, where every topic that's genuinely hard to picture from text alone is paired with a scannable code linking straight to the matching Manim animation. Alongside the theory, each topic includes worked examples, exam tips, the mistakes students make most often, and practice problems with a formula sheet for quick revision before an exam. You can find the full set on my Gumroad page.

The Result I Did Not Expect

The most useful outcome of the last two months was not on Facebook at all. Researchers preparing for conference presentations started reaching out, asking if I could build an animation to explain a concept from their own research, the kind of concept that is genuinely hard to present clearly in a short talk using only slides and text. I said yes, and it turned into something I now offer properly: custom Manim-built explainers for research talks, thesis defenses, conference presentations, or coursework, built in the same style as PlotLab, with a fast turnaround.

If that sounds like something you need, whether it's a concept from your own research, a topic for your students, or anything else where an idea needs to be seen and not just read, you can see how this works and reach out on my Work With Me page.

What I Take From This

I did not grow this page by studying growth tactics. I grew it by solving a real problem for real students first, and only sharing the result afterward. If there is a lesson in that for anyone building an audience around their own work, I think it's this one: build for the person in front of you first. The audience online tends to follow, not the other way around.

I lead the Mathematics Department at my college, and PlotLab is where I turn what I teach into animation. If you'd like to see more of the work, follow along on Facebook (40,000+ followers) or Instagram (15,000+ followers). If you're a researcher, teacher, or student who needs something explained visually, reach out through my Work With Me page. I'd like to hear from you, drop a comment.

I Built My Students an AI Assistant That's Not Allowed to Make Things Up

Sohaib Hassan — Wed, 19 Aug 2026 18:40:41 +0000

How I built Classroom AI System, a free, RAG-grounded teaching assistant that only answers from my own course notes, plus the teacher dashboard it feeds, on a budget of exactly $0.

Ask a generic AI chatbot a question about your course, and it will answer confidently, using its own notation, its own conventions, and occasionally its own facts. It doesn't know that you define a term slightly differently than the textbook does, or that a particular proof technique hasn't been covered yet, or that the "obvious" shortcut it just suggested isn't one your students are allowed to use on the exam. It will still answer. That's the problem.

I teach undergraduate mathematics, and every semester the same pattern repeats: a handful of students ask sharp, specific questions in office hours, while dozens more ask ChatGPT the same questions late at night, when I'm not there to catch the moment an AI politely gets something wrong. So I built something that only answers from my own course notes, refuses to guess when it doesn't know, and, as a side effect, shows me exactly where an entire class is actually getting stuck. It's called Classroom AI System, and the code is public: github.com/Sohaib-Hasan/classroom_ai_system.

Grounded, Not Generic

The technical name for what makes this different is retrieval-augmented generation, RAG for short. Instead of asking a language model to answer from everything it was trained on, the system first retrieves the exact passage from my own LaTeX course notes most relevant to a student's question, then instructs the model to answer strictly from that passage and nothing else. Right now the knowledge base covers Calculus, Discrete Mathematics, and Number Theory, chunked chapter by chapter from the same notes I hand out in class.

The system is two separate apps sharing one brain:

A student assistant, PIN-gated, where students type a question and get an answer grounded in the actual notes.
A teacher dashboard, password-gated, where I see what's being asked across the whole class: which topics come up again and again, which questions the cache is already handling, and where the same confusion is repeating across different students.

How a Question Actually Gets Answered

Getting from ".tex notes" to "trustworthy answer" happens in two stages. The first, indexing, happens once, offline, whenever my notes change:

python3 chunk_notes.py      # .tex notes  ->  raw chunks (one per definition/example/theorem/proof)
python3 clean_chunks.py     # strips decorative LaTeX, keeps the real math
python3 embed_chunks.py     # embeds every cleaned chunk into knowledge_base.json

The second stage happens live, every time a student asks something: the question gets embedded and compared against the knowledge base by cosine similarity, the closest matching chunks get pulled out, and only those chunks, together with the question, get sent to Gemini for an answer.

The Step That Almost Broke Everything

The middle step, clean_chunks.py, sounds like the least interesting part of the pipeline. It's the one that mattered most.

chunk_notes.py extracts each definition, example, or theorem box straight out of the raw .tex source, decorative markup and all: color commands, tables, diagram code, spacing macros. That raw text becomes part of the prompt the model sees for every question. Skip the cleaning step, and the model will occasionally echo a fragment of that raw markup straight back to a student, so instead of a clean explanation they see broken LaTeX code on their screen. clean_chunks.py strips all of that decoration out while leaving the real $...$ math completely untouched, so the model only ever sees the content, never the formatting noise around it. It's a small, unglamorous script, and the whole system's credibility depends on it running before every embedding pass.

Making It Work on a Budget of Exactly $0

This runs entirely on Gemini's free tier, which means every question costs quota, and quota is the actual scaling limit. A few decisions keep that from becoming a wall:

Multi-key rotation. Gemini's rate limits apply per Google Cloud project, not per key, so keys from separate accounts draw from independent quota pools. The system supports up to three keys and falls through to the next one only if a call fails, invisibly to the student asking the question.
Caching. A SQLite-backed cache means a rephrased version of a question someone already asked skips the generation call entirely, which matters a lot in a class where dozens of students hit the same handful of confusing topics.
Local embeddings. Every question needs an embedding call, even on a cache hit, which makes it the single biggest quota consumer in the whole system. Swapping the embedding provider to a free local model removes that cost entirely, at the price of having to rebuild the knowledge base once, since Gemini and local embeddings aren't compatible with each other.
A per-session rate limit. Eight questions per rolling 60 seconds per browser session, mostly as a safety net against an accidental double-submit rather than a real constraint on normal use.

Two Apps, One Shared Brain

The student assistant and the teacher dashboard are deployed as two separate Streamlit Cloud apps, on two different URLs, each running in its own isolated container. That last part turned into the trickiest infrastructure problem in the whole project: a local SQLite file that one container writes to simply doesn't exist for the other one.

The fix is Turso, a free, hosted, SQLite-compatible database that both apps point to instead of their own local files. Two details in that setup cost real debugging time and are worth writing down: the connection string has to use https://, not libsql://, because the WebSocket handshake libsql:// relies on can fail inside Streamlit Cloud's sandboxed environment, and the secret key has to be named exactly TURSO_AUTH_TOKEN. Get either of those wrong and there's no crash, no error message, just a dashboard that stays quietly empty with nothing to explain why.

What the Teacher Actually Sees

This is the part that matters most to me as a teacher, and it's the part a generic AI chatbot can never give you. Office hours show me the questions the handful of students who show up are willing to ask out loud. The dashboard shows me every question the whole class actually had: which topic keeps coming back, which confusion is repeating across students who've never spoken to each other, what the cache is already absorbing versus what's genuinely new. It's the difference between a handful of anecdotes and an actual signal.

Built to Not Break Quietly

The business logic lives in core.py, which deliberately has no dependency on Streamlit at all, so it can be tested completely independently of the app itself. Right now it's backed by 91 automated tests, and every one of them exists because a specific bug was found and fixed, not because of abstract coverage targets. One example I'm particularly fond of: the system's verify_computation() check samples the negative, positive, and near-zero domains of a function, not just the positive ones, specifically because a positive-only check would miss domain-sensitive errors like treating sqrt(x**2) as equal to x, which only holds when x is non-negative. That's the kind of bug that looks fine in a quick demo and quietly produces wrong math for a student six weeks later.

Where It's Still Rough

A few honest limitations, because a system that grades student proofs owes its builder the same standard: nested LaTeX boxes of the same type (a definition box inside another definition box) aren't parsed cleanly yet, though a safety check flags this loudly the moment it happens rather than letting it reach a student silently. The automated cleaning handles the large majority of decorative LaTeX but not all of it: roughly 3% of chunks, mostly color commands sitting inside real math, still need a manual look. And there's an optional third-party fallback provider for when every Gemini key is exhausted that I've built but haven't yet stress-tested in production, so for now it's a safety net I wouldn't lean on.

What's Next

The next thing I'm building on top of this is a guided answering mode: instead of jumping straight to a full solution, the system will offer a hint first, then a guiding question, and only give the complete answer if the student actually wants it. The goal was never to hand out finished proofs faster. It's to get a student unstuck without doing their thinking for them.

That's really the whole premise behind this project, and behind the broader direction I want to take my teaching: AI that's useful specifically because it's constrained, not despite it.

I lead the Mathematics Department at my college and build tools like this one alongside my Manim animation work as PlotLab. If you teach and are curious whether something like this could work for your own courses, or if you'd like help building it, reach out. I write more like this at sohaib-hasan.github.io, and if you want to see the kind of animated explanations I build separately from this project, they're on Facebook (35K+ followers) and Instagram (15K+ followers). I'd like to hear what you think, drop a comment.`

AI Just Posted a Perfect Score at the Real Math Olympiad. I Spent Months Building One of These Systems. Here's What It Actually Takes

Sohaib Hassan — Sat, 08 Aug 2026 08:55:32 +0000

In July 2026, in Shanghai, something happened that mathematicians had been debating for two years: AI systems from Huawei and Xiaohongshu were each reported to have solved all six problems of the International Mathematical Olympiad, a perfect 42 out of 42. Several other labs reported matching results on their own. It followed a 2025 breakthrough where Google DeepMind's Gemini Deep Think, officially graded by IMO coordinators, and an OpenAI experimental model both reached the gold-medal threshold of 35/42.

Headlines called it AI "beating" the world's best teenage mathematicians. I want to tell you what's actually behind a headline like that, not as a journalist, but as someone who spent the past several months building a much smaller, much less glamorous version of exactly this kind of system.

My teammate Samuel Koh and I entered AIMO3, the third AI Mathematical Olympiad Progress Prize, hosted on Kaggle. We scored 42 out of 50, placing 495th out of 4,138 teams, the top 12% globally. Here's the honest, unglamorous story of how we got there, what we tried that failed, and what the finished system actually looks like under the hood.

What AIMO Actually Is (And Why It's Not the IMO)

First, an important distinction, because the acronyms get confusing fast: AIMO is not the IMO.

The AI Mathematical Olympiad is a $10 million prize fund, created in 2023, that exists specifically to close the gap between what the closed, proprietary models at OpenAI and Google can do and what the open community can build. Its grand prize, $5 million, goes to the first team that publicly shares a model capable of gold-medal-equivalent performance at the actual IMO. Along the way, Kaggle hosts periodic "Progress Prize" competitions to measure how far the open field has come.

AIMO1 was won by Project Numina in 2024. AIMO2 was won by NVIDIA's team, NemoSkills, who solved 34 of 50 problems. AIMO3, the one we entered, raised the difficulty again: 110 entirely original problems, ranging from national-olympiad level up to full IMO standard, spanning algebra, combinatorics, geometry, and number theory. "Entirely original" matters enormously here: it means no amount of memorization from training data helps you. Every problem has to be reasoned through, not recalled.

Competitors were also given access to H100 GPUs, roughly double the compute of AIMO2, which meant we could run larger open-weight models than previous years: models like GPT-OSS-120B and Qwen3-Next became viable for the first time.

So when you read that an AI "scored a perfect IMO," understand what's actually being claimed. In 2026, most of those results, including the ones from Huawei and Xiaohongshu, were the companies' own self-reported submissions, run after the human competition window closed, evaluated against the same problems and time limit but not scored live by IMO coordinators. Only a small number of 2025 and 2026 results have been independently, officially graded. That's not a reason to dismiss the progress. It's real, and it's fast. But it's worth knowing the difference between "officially certified" and "self-administered" when you see the next big claim.

Two Rules That Shaped Every Decision We Made

Before I describe what we built, you need to understand the two constraints that made this hard, because they killed almost every "obvious" idea we had.

Rule one: five hours of GPU compute, total, per problem set. Not per problem. Per set. That immediately rules out anything computationally greedy.

Rule two: binary scoring, no partial credit. A problem is either fully correct or fully wrong. This sounds simple, but it has a brutal implication: a system that produces a plausible, confident-sounding, but wrong answer is worse than a "generic" wrong answer, because it's confidently wrong. Under this rule, knowing when your system is unsure is almost as valuable as getting the right answer.

I handled the mathematical side: interpreting problems, checking whether a given line of reasoning was actually valid, and sourcing harder test cases beyond the standard dataset to stress-test our system. Samuel handled the engineering: building and running the inference pipeline under that fixed compute budget. Neither role alone was enough. The problems weren't purely mathematical, and they weren't purely a systems problem either.

Four Ideas We Killed Before Writing a Line of the Final System

Here's what we considered and rejected, and why each one matters as a lesson, not just a footnote:

Supervised fine-tuning. The obvious first instinct. Rejected immediately: it needs massive GPU clusters and months of runway, not a fixed five-hour, competition-scale budget.
Fully agentic search, a system that breaks a problem into steps, calls tools, verifies intermediate results, and loops back on itself. Conceptually, this is the closest thing to how a human mathematician actually thinks. We rejected it anyway, because Kaggle's environment has no outbound internet access, and an open-ended agentic loop risked silently burning our entire compute budget before ever producing a final answer.
Monte Carlo Tree Search. Not used.
Long, verbose chain-of-thought prompting. We tested it. Concise prompting consistently outperformed it.

The pattern across all four rejections is the same one that ended up defining our whole approach: under a fixed, non-negotiable compute budget, a simpler system you can actually trust beats a theoretically more powerful one you can't fully control.

The Architecture: A Parallel Self-Consistency Pipeline

What we actually built and submitted, we called a Parallel Self-Consistency Pipeline. Here's how a single problem moves through it, end to end:

The problem is written in LaTeX and gets converted into a structured prompt.
The base model, GPT-OSS-120B (OpenAI's open-weight mixture-of-experts model, around 120 billion total parameters but only about 5 billion active per token, which is exactly why it fits on a single H100 despite its size), generates a reasoning attempt at temperature 0.8.
The Parallel Sampler does this eight times, independently, all at once. This is the "self-consistency" idea, and it's built on a real insight from a 2022 paper by Wang et al.: a single reasoning chain can silently go wrong at any step with no way to catch it, but across eight independent attempts, correct reasoning tends to converge on the same answer while failure modes tend to scatter in different directions.
Tool-Integrated Reasoning. Each of those eight attempts is paired with a live Python interpreter. The moment a reasoning chain hits a calculation it can't reliably do purely in text, it hands that calculation off to Python instead of guessing, a small design choice that removes an entire category of careless arithmetic errors.
The Entropy-Weighted Aggregator. This is the part I'm proudest of. Instead of a simple majority vote across the eight candidate answers, each one is scored by:

score = \frac{1}{H} + 8.0 \cdot V

Here, H is the mean generation entropy of that attempt (how "confident" the model was, token by token, while producing it) and V is a verifier score. Because the formula uses 1/H, a low-entropy, confident attempt scores higher than a scattered, uncertain one, even if it wasn't the majority answer. There's also an early-stopping rule: if any single answer already has four or more votes, the aggregator stops and submits it immediately, saving compute for the next problem instead of waiting out the clock.

I actually animated this entire pipeline in Manim: every arrow, every fan-out, every step of the aggregation, so you can watch it play out visually instead of just reading a static diagram:

From 8/50 to 42/50: What the Climb Actually Looked Like

Our first working version of this pipeline scored 8 out of 50. The final version scored 42. That climb didn't come from one clever trick. It came from three unglamorous things, repeated over and over: systematically diagnosing bugs in the pipeline itself, upgrading the base model as better open-weight options became available, and steadily refining the few-shot prompts feeding into step one.

There's one more data point that told us we were on the right track, and it came after the competition closed. The eventual first-place team's public writeup also centered on GPT-OSS-120B, and their approach was also built around entropy-weighted self-consistency, refined further with things like adaptive runtime scheduling, but directionally the same idea we'd arrived at independently. When a team with more resources converges on the same core mechanism you did, without either of you seeing the other's work, that's a stronger signal than any single benchmark score.

The One Lesson I'd Give Anyone Building AI Under Real Constraints

Every rejected idea (fine-tuning, agentic search, tree search, verbose prompting) failed for a version of the same reason: it added complexity we couldn't fully control inside a budget we couldn't negotiate. The thing that actually worked was the opposite: precision and reliability over architectural cleverness.

That's not a lesson specific to Kaggle competitions. It's true anywhere you're building an AI system against a real constraint: a latency budget, a cost ceiling, a compliance requirement. The fanciest architecture on paper is worth nothing if you can't trust what it does when the clock is running.

As for the "AI beat the Olympiad" headlines, they're not wrong, exactly. The field genuinely moved from silver-medal level in 2024, to officially certified gold in 2025, to multiple perfect-score claims in 2026, in about two years. I watched a smaller version of that same curve happen inside my own project, going from 8/50 to 42/50 in a few months of iteration. The trend is real. Just read the fine print on "official" versus "self-reported" before you decide how impressed to be by any single claim.

I've taught undergraduate mathematics for 9+ years, and I build Manim-animated math content as PlotLab. If you want to learn the exact animation workflow shown in the diagram above, from your first Scene to a full multi-step pipeline animation, I wrote a complete, copy-paste-ready guide: Manim CE Beginner's Handbook. If you'd rather have someone build it for you, for an undergraduate or graduate thesis defense, a research paper, or any project where the math needs actually to look as good as it sounds, I take on that work directly; you can see the quality for yourself on Facebook (35K+ followers) and Instagram (15K+ followers), and reach out if you'd like to work together. I write more essays like this one on mathematics, AI reasoning, Manim Animations, and teaching at sohaib-hasan.github.io. I'd genuinely like to hear what you think of the pipeline above; drop a comment.

I Spent 5 Years Making Math Animations in Python. Here's Everything I Wish I Knew on Day One.

Sohaib Hassan — Wed, 29 Apr 2026 12:04:54 +0000

A complete, honest guide to building 3Blue1Brown-style math animations with Manim CE — from zero setup to your first polished scene. No fluff, just what actually works.

The first time I tried to make a math animation, I spent four hours staring at an error message I didn't understand.

No one warned me about LaTeX dependencies. No one explained the difference between Text and MathTex. No one told me why my equation was rendering in the wrong position — or why my animation was playing twice — or why the camera was cutting off half my scene.

I figured it out eventually. But it took months, not days.

If you're reading this, you probably want to create math animations. Maybe you've watched 3Blue1Brown explain calculus and thought "I want to make something like that." Maybe you teach mathematics and you're tired of static diagrams that put students to sleep. Maybe you're just curious whether Python can actually produce beautiful, publication-quality math visuals.

It can. And it's more accessible than you think.

But only if someone shows you where to actually start.

What Is Manim — And Why Does It Matter?

Manim is an open-source Python library built specifically for mathematical animations. Every equation you render is typeset through LaTeX. Every shape, every graph, every transformation is mathematically precise — not visually approximate.

This is what separates Manim from every other animation tool.

When you draw a circle in Manim, it's a perfect circle — defined mathematically, rendered with zero distortion. When you write a quadratic formula, it looks exactly like a published research paper. When you animate a transformation, every frame is calculated programmatically.

This is why educators, researchers, and content creators around the world have adopted it. Not because it's easy — but because nothing else produces results like this.

The Mistake Everyone Makes on Day One

Most beginners open Manim, look at the documentation, and immediately feel overwhelmed.

The documentation is comprehensive — but it's not written for beginners. It assumes you already know what you're looking for. If you don't, you'll spend hours reading without actually building anything.

Here's the truth: you learn Manim by writing scenes, not by reading documentation.

Every concept clicks the moment you run working code and see it render. Not before.

This is why the copy-paste-first approach works so much better than theory-first learning.

What You Actually Need to Get Started

Before writing your first scene, you need four things — and three of them are completely free.

1. Python 3.9 or later
If you already have Python installed, you're halfway there. If not, the official Python website has a one-click installer for every OS.

2. Manim CE v0.20.1

pip install manim==0.20.1

3. A LaTeX Distribution ← This is where most beginners get stuck

Manim uses LaTeX to render equations. You need either:

MiKTeX (Windows)
TeX Live (Mac/Linux)

Both are free. Both take about 15 minutes to set up. Do not skip this step — skipping it is why 80% of "Manim doesn't work" posts exist on forums.

4. VS Code
Any text editor works, but VS Code gives you syntax highlighting, terminal integration, and extensions that make Manim development significantly smoother.

That's the entire setup. No subscriptions. No expensive software. No complicated configuration beyond these four things.

Your First Scene — What It Looks Like

Here is the simplest possible Manim scene. Copy this exactly, save it as first_scene.py, and run it:

from manim import *

class HelloManim(Scene):
    def construct(self):
        equation = MathTex(r"x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}")
        self.play(Write(equation))
        self.wait(2)

Render it with:

manim -pql first_scene.py HelloManim

In under ten seconds, you'll have a video of the quadratic formula writing itself onto the screen — typeset perfectly, animated smoothly.

That's Manim. That's what three lines of actual code produce.

💡 Always use -pql (low quality) while developing. High-quality renders take minutes. Save -pqh for your final output only.

The Five Concepts That Unlock Everything

After years of building animations, I can tell you that 90% of what you'll ever need in Manim comes down to five core concepts.

1. `MathTex` and `Text`

MathTex renders LaTeX equations. Text renders plain words. Knowing when to use which — and how to color individual parts of an equation — is the foundation of every math explainer.

# Correct — renders LaTeX
equation = MathTex(r"E = mc^2")

# Wrong for equations — won't render LaTeX
label = Text("E = mc^2")

2. Shapes and Geometry

Circles, squares, triangles, lines, arcs — all mathematically defined, all fully customizable. Once you understand how positioning works in Manim, placing objects exactly where you want them takes seconds.

circle = Circle(radius=1, color=BLUE)
square = Square(side_length=2, color=GREEN)
square.next_to(circle, RIGHT, buff=0.5)

3. Animations and Transforms

Write, Create, FadeIn, Transform, ReplacementTransform — these are the verbs of Manim. Each one does something specific, and choosing the right one makes the difference between an animation that feels natural and one that feels jarring.

self.play(Write(equation))           # draws stroke by stroke
self.play(FadeIn(circle))            # fades in from transparent
self.play(Transform(square, circle)) # morphs one shape into another

4. `NumberPlane` and Graphs

Plotting functions in Manim is remarkably clean. Define your axes, pass a lambda function, and Manim draws it — with full control over color, range, and style.

axes = Axes(x_range=[-3, 3], y_range=[-1, 9])
graph = axes.plot(lambda x: x**2, color=YELLOW)
self.play(Create(axes), Create(graph))

5. Updaters and `ValueTracker`

This is where Manim becomes truly powerful. Updaters let objects respond dynamically to changing values — this is how you create animations where a tangent line moves along a curve, or a point traces a parametric path in real time.

tracker = ValueTracker(0)
dot = always_redraw(
    lambda: Dot(axes.c2p(tracker.get_value(), tracker.get_value()**2), color=RED)
)
self.play(tracker.animate.set_value(2), run_time=3)

The Common Mistakes That Cost Beginners Hours

I made every single one of these. You don't have to.

Mistake	What to do instead
Rendering high quality every time	Use `-pql` while building. Switch to `-pqh` only for the final render.
Not using `VGroup` for positioning	Group related objects with `VGroup` — positioning a group is infinitely cleaner than positioning each object individually.
Hardcoding coordinates	Use `.next_to()`, `.shift()`, `.move_to()`. Your layout will survive any change you make.
Using `Text` for equations	If your equation looks wrong — jagged, unstyled, broken — you're almost certainly using `Text` when you should be using `MathTex`.
One long `construct()` method	Break your scene into helper methods. A readable scene is a maintainable scene — especially when you return to it three weeks later.

A Complete Working Example — From Zero to Polished

Here's a scene that combines everything above. Copy it, run it, and modify it as your own starting template:

from manim import *

class QuadraticExplainer(Scene):
    def construct(self):
        # Title
        title = Text("Solving a Quadratic Equation", font_size=36)
        self.play(Write(title))
        self.wait(1)
        self.play(title.animate.to_edge(UP))

        # Standard form
        standard = MathTex(r"ax^2 + bx + c = 0", font_size=48)
        self.play(Write(standard))
        self.wait(1)

        # Transform to quadratic formula
        formula = MathTex(
            r"x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}",
            font_size=48
        )
        self.play(ReplacementTransform(standard, formula))
        self.wait(2)

        # Highlight the discriminant
        formula[0][9:19].set_color(YELLOW)
        discriminant_label = Text("discriminant", font_size=24, color=YELLOW)
        discriminant_label.next_to(formula, DOWN)
        self.play(Write(discriminant_label))
        self.wait(2)

Run with:

manim -pql scene.py QuadraticExplainer

Where to Go From Here

Manim has a learning curve — but it's not as steep as it looks from the outside. The moment your first animation renders, something shifts. You stop seeing it as code and start seeing it as a creative tool.

The path forward is simple: build scenes. Start with something small — an equation, a shape, a simple transform. Then add complexity one layer at a time.

I spent years on this path. I documented everything — every mistake, every shortcut, every pattern I kept returning to — into a structured beginner handbook:

📘 Manim CE v0.20.1 Beginner Handbook

Ten complete chapters. Copy-paste-ready code for every concept above. Common mistakes are prefixed before you hit them. 60 pages.

If you want to see what Manim looks like in practice before committing to anything, the animations are here:

📱 @plotlab01 on Instagram

Start building. The best math animation you'll ever make is the next one.

About the author: Sohaib Hasan is a Mathematics Lecturer with 9 years of experience and 1,500+ students taught. He creates 3Blue1Brown-style math animations using Python and Manim, and shares them at @plotlab01.