A software engineering roadmap that assumes you use AI
Most software engineering roadmaps are a list of technologies with arrows between them. They were written when the bottleneck was knowing how to write the code. That bottleneck is largely gone. You can get a working feature out of an AI tool today without understanding a line of it.
What got scarcer is the other half. Reading unfamiliar code and saying what it does. Knowing what breaks first under load. Spotting the security hole before it ships. Telling a good generated answer from a plausible one. Those are the skills a roadmap should be organised around now, and almost none of them are.
01 / What to optimise for instead of a technology list
Depth in the layer beneath whatever you are using. If you write JavaScript, understand the event loop. If you use a framework, understand the protocol it wraps. If you use an ORM, understand the query it emits. One layer down is where every hard bug lives, and it is the layer AI tools are least reliable about.
The ability to be wrong quickly. Engineers who improve fastest are the ones who form a specific prediction, test it, and find out. Vague understanding survives indefinitely because it is never falsified. This is why the days here end in exercises and recall rather than a video and a nod.
Retention rather than exposure. Having read about database indexes is not knowing them. The distinction only shows up months later, at the moment you need it, and by then the fix is expensive.
02 / The order that works
56 days of this path, in sequence
Data structures sit in the middle rather than at the start, and in small daily amounts rather than a separate two-month grind. Front-loading algorithms is the most reliable way to quit in week three, and they make far more sense once you have written enough code to have felt something be slow.
- 01How code actually runs
- 02Values, variables, and what a reference really is
- 03Conditions, loops, and the shape of logic
- 04Functions, arguments, returns, and scope
- 05Lists, dicts, sets, and choosing between them
- 06Errors, exceptions, and reading a stack trace
- 07How to debug anything without guessing
- 08The terminal, files, and paths
- 09Modules, packages, and virtual environments
- 10Git, and why version control exists
- 11Reading unfamiliar code
- 12Everything so far, and your first architecture question
- 13Big O, without the maths
- 14Arrays, strings, and the two-pointer idea
- 15Hash maps, sets, and how caches use them
- 16Objects, classes, and composition over inheritance
- 17Stacks, queues, and the call stack you already met
- 18Recursion, and how it eats the stack
- 19Sorting, binary search, and when you only need the top K
- 20Trees, and why every database index is one
- 21Graphs, BFS, DFS, and dependency order
- 22Your data structure decision table
- 23What actually happens when you type a URL
- 24HTTP methods, status codes, and headers
- 25JSON, REST, and the idea of an API contract
- 26JavaScript fundamentals for engineers
- 27The event loop, single-threaded and still fast
- 28Promises, async, await, and real concurrency
- 29TypeScript, and why static types exist
- 30Interfaces, unions, and generics in practice
- 31The browser, the DOM, and where state lives
- 32React's mental model
- 33Next.js routing, layouts, server and client
- 34Tracing one request through a whole app
- 35Anatomy of a backend
- 36Building an API with FastAPI
- 37Validation, serialization, and the trust boundary
- 38Authentication versus authorization
- 39Sessions, tokens, and what a JWT actually is
- 40Password hashing, CORS, and secrets
- 41Relational thinking: tables, keys, relationships
- 42SQL: SELECT, WHERE, JOIN, GROUP BY
- 43Indexes, and why a query goes from 4s to 4ms
- 44Transactions, and what ACID actually protects
- 45ORMs, the N+1 problem, and SQL injection
- 46Design a schema and defend it
- 47Testing: what's worth testing, and what isn't
- 48Integration and end-to-end tests
- 49Logging that helps you at 3am
- 50Docker, and why containers exist at all
- 51CI, CD, and deployment pipelines
- 52Environments, configuration, and secrets management
- 53Observability: logs, metrics, and traces
- 54Latency, throughput, and profiling intuition
- 55Timeouts, retries, backoff, and idempotency
- 56Write a production readiness checklist
Every one of those days is free to read in full. See all 90.
03 / Where people go wrong
- 01
Tutorial hell, which is a retention problem rather than a motivation one
Following along with a tutorial feels like learning because the code works at the end. Nothing was retrieved from memory, so nothing was retained. The fix is not more discipline. It is being asked a question before being given the answer, then being asked again a week later when you have started to forget.
- 02
Learning React before JavaScript
It works right up until something behaves unexpectedly, and then there is no floor to stand on. Closures, the event loop, and how this binds are not advanced React topics. They are the things React is built out of, and every confusing React bug is one of them in costume.
- 03
Collecting technologies instead of building depth
A CV listing twelve technologies and a project in each is weaker than one listing four with real depth, and it interviews far worse, because the follow-up question goes one layer down and there is nothing there. Breadth is worth having. It is worth having second.
- 04
Using AI to skip understanding rather than to accelerate it
The same tool does both, and which one you get depends entirely on whether you ask it to explain or to produce. Asking for the code and moving on is a permanent dependency. Asking it to quiz you, explain why it chose one approach, or find the bug in yours is the fastest tutor that has ever existed. Every day here ships a prompt built for the second use.
04 / How long it takes
Fifty-six days at two to three hours to get through the five spans above, which covers everything up to production engineering. The full ninety continues into system design and AI engineering.
That is roughly one hundred and thirty hours. It is a real commitment and it is far less than the year most roadmaps imply, mostly because the scope is fixed in advance and nothing has to be chosen along the way.
05 / Common questions
- Is it still worth learning to code if AI can write it?
- Yes, and the reason has changed. Not because you will type more of it, but because somebody has to be able to tell whether what came out is correct, secure, and going to hold under load. That person is worth more now, not less, and there are fewer of them being produced.
- How long does it take to become a software engineer?
- To be genuinely employable, longer than ninety days for most people, and it depends heavily on where you start. What ninety days of focused work can do is take you from scattered gaps to being able to read, reason about and defend a real system, which is the part most self-taught paths never close.
- Do I need a computer science degree?
- No, but you do need the parts of one that matter, and this is the honest gap in most self-taught routes. How code actually runs, why one data structure beats another, what the database is doing. Those are learnable directly. Skipping them is what produces an engineer who plateaus.
- What order should I learn software engineering topics in?
- Foundations, then data structures in small doses, then the web, then backend and data, then production. The order above. The most common mistake is starting with a framework, which puts you three layers above the ground with nothing to stand on when something breaks.
The whole path is free and public.
Read the roadmap, open any day, and decide for yourself. Signing in is only so ninety days of progress survives a cleared browser.