Yes for most of software engineering, which needs logical thinking far more than advanced math. For AI it depends on the role: building products on top of models needs little math, while research and model training need a lot. Most people who say they are bad at math were taught badly, and the math you need can be learned.
What people tell me
I have always been the person who fixes computers, installs things and figures out new apps quickly. I enjoy programming a little. But I struggled with math at school and I still find calculus and linear algebra in my degree hard. Everyone says AI is the future and that you need strong math for it. I am worried that my weakness in math will limit me, and I do not know whether to avoid AI completely or push through.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Most software engineering roles use logic, careful reasoning and basic arithmetic far more than advanced math.
- In AI, applied roles that build on existing models need little math; research and training roles need a lot.
- Decide which kind of role you want before deciding how much math to learn.
- Math taught through code and concrete examples is far easier than math taught as abstract proofs.
- Do not let one weak subject make a career decision for you before you have tested it.
Two different things called math
When students tell me they are bad at math, they usually mean one of two things. Either they struggled with calculation-heavy exams under time pressure, or they never connected with abstract notation. Neither is the same as being unable to think logically, and logical thinking is what programming mostly needs.
Writing software is about breaking a problem into steps, handling edge cases, keeping track of state and reasoning about what happens when inputs change. People who fix computers for fun are usually good at exactly that: forming a hypothesis, testing it and narrowing down the cause. That is debugging. It is a core engineering skill.
How much math each path needs
| Path | Math you actually use | Honest verdict |
|---|---|---|
| Web, mobile, backend development | Basic arithmetic, logic, occasional percentages and dates | Math is not a barrier |
| Cloud, DevOps, security operations | Logic, some networking arithmetic | Math is not a barrier |
| Data engineering, analytics | Basic statistics, aggregation, comfort with numbers | Learnable with steady effort |
| AI engineering (building products with models) | Intuition for probability, evaluation metrics, vectors at a conceptual level | Learnable, mostly through practice |
| Machine learning engineering (training models) | Linear algebra, probability, calculus basics, optimisation | Needs real investment |
| AI research | Deep math across several areas | Math is central |
The word AI covers the whole bottom half of this table. Most AI jobs being created right now are in the AI engineering row: connecting models to real data, building retrieval, writing evaluations, handling failures and cost. That work is software engineering with a new set of tools, and it rewards the same careful thinking.
Decide the role first, then the math
The mistake I see is trying to learn all of the math up front, just in case, then burning out on linear algebra before ever building anything. Flip the order:
- Pick a first target role from the table. If you are unsure, pick web or backend development, since it is the most common entry point and it teaches habits every other path uses.
- Build something real in that area for two or three months.
- Meet the math when it appears. If you move toward AI engineering, you will need to understand what an embedding is, why cosine similarity works and how to read precision and recall. Learn those when a project demands them, not before.
- Only go deep into calculus and linear algebra if you decide you want to train models or do research.
Relearning math is easier than you think
Most people who hated school math had it presented as symbols to memorise. The same ideas become much friendlier when you see them in code:
- Write a small function that computes an average, a median and a standard deviation, then run it on real data you care about.
- Represent two short sentences as lists of numbers and compute how similar they are. That is the heart of vector search.
- Plot a line, change its slope and watch what happens. That is the intuition behind a lot of optimisation.
Give yourself permission to go slowly. Thirty minutes a few times a week, with code alongside, compounds quickly.
Do not ignore your degree math either
If your degree has math courses, pass them properly. Grades matter for some opportunities, and failing courses creates stress and delays you do not need. But pass them as courses, not as a verdict on your future. The skills they test in an exam hall are not a prediction of how well you will build software.
What actually predicts success
In the engineers I have hired and mentored, the traits that predicted growth were not math scores. They were curiosity about how things work, the patience to stay with a problem, the habit of finishing things, and the ability to explain a decision to someone else. You describe yourself as the person who figures things out. Build on that.
A self-check before you decide math is the problem
Before you rule anything out, test whether it is math you struggle with or the way it was taught. Try these three small tasks, in code, with no time limit:
- Write a function that takes a list of exam scores and returns the average, the highest score and how many are above the average.
- Write a function that, given a price and a discount percentage, returns the final price rounded to two decimal places, and test it with ten different inputs including zero and one hundred percent.
- Given two short lists of numbers of the same length, multiply them position by position and add up the results. Then read one short explanation of the dot product and notice that you just wrote one.
If you could do these, even slowly, you have the kind of numerical reasoning most software roles need. If the third felt interesting rather than frightening, AI engineering is not closed to you either.
What to say when someone tells you AI is only for math people
You will hear this a lot. A calm, honest answer is: "Research needs a lot of math. The applied roles I am looking at mostly need solid engineering plus an intuition for probability and evaluation, and I am learning that as I build." That answer shows you understand the field better than the person warning you.
If you are still stuck
Read The AI engineering words you keep hearing, explained properly to see what AI work really involves, then An AI engineering roadmap that puts things in the right order and The fundamentals worth learning as a software engineer. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- An AI Engineering Roadmap That Puts Things in the Right OrderEvery AI engineering roadmap is the same twenty topics rearranged, and the arrangement is the only part that matters. Six stages from model basics through retrieval, measurement, tool calling and agents, each with something specific to build, what to skip entirely, and the two stages people skip and later regret.
- The AI Engineering Words You Keep Hearing, Explained ProperlyThe concepts underneath AI engineering are mostly not difficult, but every explanation assumes eight other terms you have not met yet. Tokens, embeddings, RAG, fine tuning, tool calling, MCP, agents, evals and the rest, each with what it is genuinely good for and where it will let you down, plus the order worth learning them in.
- The Fundamentals Worth Learning as a Software EngineerFrameworks are the fastest moving and least valuable part of what you know. This is the layer underneath: how a computer runs your code, data structures as trade offs, complexity at conversational depth, storage, networks, concurrency, version control, testing as a design tool, and the two skills engineers skip that decide how far they get.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.