Your project is finished, documented, defended and published: Project presentation closed off the last pending task. This lesson teaches no new syntax and adds nothing to the project; it is here for what comes next, which is a legitimate and fairly anxious question when a course ends: so what now? We are going to answer it in four movements. First, an honest stocktake of what you can do today and could not do nine modules ago. Second, the map of what exists out there that this course did not cover, so that you know what is there and what it is for. Third, the career paths that open up from where you are, with realistic expectations. And fourth, a concrete three-month plan, because the difference between the person still programming a year from now and the one who gave up is not talent: it is having the next thing to do.

1. The road travelled
2. EasyTask, from v0.1 to v1.0
3. What this course did not cover
4. Choosing a path
5. How to keep learning
6. Professional habits worth consolidating
7. Working with AI assistants
8. Common mistakes made by beginners
9. A plan for the next three months
10. Common mistakes and tips
11. Exercises
12. Conclusion

You started without knowing what a variable was. This is the inventory, module by module, of what you can do now; read it slowly, because the normal feeling at the end of a course is that you know nothing, and that is not what the table says:

That last row is the one that carries the most weight. Plenty of people know Python syntax; considerably fewer have taken a project of their own from an idea to a published v1.0. The first is learned in a few weeks; the second is what it takes to work.

If you need tangible proof of the road travelled, there it is in EasyTask. It started out as three print calls and a list, and ended up as an installable package with tests. Its story is the story of the course:

The distance shows best by comparing the same idea written at the beginning and at the end. This is how the tasks were listed in v0.1:

And this is how in v1.0:

Nine modules sit between those two snippets: functions with parameters and default values, type annotations, a docstring, a class encapsulating the collection, filtering and sorting by criterion, the empty-list case anticipated and __str__ doing the formatting. But the important difference is not the syntax, it is that the second one works with three tasks and with three hundred, and that it can be tested, changed and extended without rewriting it.

Marta, Luis and Nuria started with a notebook where they wrote down who was doing what for Solé Bakery and ended up with a tool that shares out the studio's work, flags what is urgent and loses nothing. That leap — from a real problem told in one sentence to a program that solves it — is exactly the one you have just made with your own project, this time without anybody telling you what to write at each step.

A fundamentals course covers the foundations, and the foundations are not the building. This is what is out there, what each thing is for and when it makes sense to get into it:

So that the recommendation about databases does not stay abstract, look at the same query — "August food expenses over 50 euros" — with what you know today and with SQL:

With 200 transactions the first version is perfect and simpler. With 200,000, the first loads the whole file into memory and walks every element, while the second uses indexes and returns the result without your program ever seeing the rest. That is the exact moment to learn SQL: when the problem shows up, not before.

Two pieces of advice about this table. First: do not turn it into a to-do list. Trying to learn all seven topics in a row is the fastest way to learn none of them. Second: learn each one when a project of yours needs it. When your expense program gets slow with 20,000 transactions, SQL will stop being a school subject and become the solution to your problem, and then you learn in a weekend what otherwise takes a month.

With what you know today you can already start any of these paths. None is better; they depend on the kind of problem you feel like solving. They all share the same trunk — the one you have just climbed — and separate afterwards:

The expectations in the last column are honest, not motivational:

And a note no course catalogue will give you: automation is the path with the best ratio of effort to immediate usefulness. If you work in something that is not programming, a script that saves you two hours a week of repetitive work gives you results in the first month, gives you something real to show and keeps you programming. Long roads are much easier to walk when there are rewards along the way.

The rule that sums up everything else: you learn by building. Reading about programming and programming resemble each other about as much as reading about swimming and swimming. A course, a book or a video is for finding out that something exists and how it is used; the knowledge sticks when you apply it to a problem that did not come with a solution.

Next projects, in increasing difficulty. Pick the next step, not the whole building:

Programming challenges. Platforms like Exercism, Codewars or Advent of Code give you closed problems with a verifiable solution. They are an excellent gym for algorithms and data structures, and a poor substitute for projects: they train you to solve twenty-line problems, not to build systems. Half an hour two or three times a week is fine; living there is not.

Reading other people's code. It is the most underrated skill and the one you will practise most in a real job, where 80 % of the time is spent reading code you did not write. Start with small projects, following this route and these questions:

Half an hour following that route over two or three projects gives you more structural judgement than several tutorials, because you see real decisions taken by people with more experience.

Contributing to open source projects. It sounds unreachable and it is not. The real way in is not fixing a complex bug, but this sequence:

1. Use a small open source tool that you already find useful.
2. Find something that does not work, or that the documentation does not explain well.
3. Search its repository for issues labelled good first issue, which exist precisely for newcomers.
4. Read its contribution guide (CONTRIBUTING.md) and respect its style, even if it is not yours.
5. Propose a small, well-explained change, and accept the review you are given.

The first accepted contribution teaches you more about teamwork — reviews, project style, technical discussion — than any course.

Studying the official documentation. It is a skill you train, not a punishment. Python's documentation has three parts worth telling apart: the Tutorial (for learning something new), the Library Reference (for looking up exactly what a function does) and the HOWTOs (excellent topic guides, like the one on regular expressions or the one on logging). Get into the habit of searching there first and in forums afterwards; forums give you a recipe, the documentation gives you the model.

You have already practised these five habits during the course. What decides your progress is not learning them again, it is not abandoning them when nobody is asking you to keep them:

• Version everything from minute one. git init is the first command of any project, even if it is a thirty-line script and even if you are not going to share it. The cost is zero and it saves you the final_version_2_good folder.
• Test what matters. You do not need to cover everything: test the calculations, the domain rules and the persistence. That is what lets you change code without fear, and without that confidence projects seize up.
• Write for whoever comes next, which is almost always you three months from now. Clear names, short functions, a README explaining the why. Code is written once and read many times.
• Measure before optimising. Intuition about performance is wrong almost every time. Measure, find the real slow point and optimise only that (06-04). The rest of the time, prioritise clarity.
• Finish what you start. It is the hardest habit and the one that will set you apart the most. A finished project, however modest, teaches and demonstrates; ten half-built ones do neither.

AI assistants are part of the job and there is no sense pretending otherwise. The useful question is not whether to use them, but how to use them so that they add without stopping you learning. The difference lies in whether the assistant does the work for you or with you:

The difference shows in how you phrase the request. Compare:

The second question starts from your code, describes the observed behaviour and asks for an explanation, not a replacement. It is the difference between walking away with a function and walking away understanding why sorted sorts by the second element of the tuple.

Three practical rules that work well:

1. Try the problem for twenty minutes before asking. The learning happens during the attempt, not in the answer. Asking after trying is research; asking before is dependency.
2. Never paste code you could not rewrite. Not out of purity, but for practical consequences: when it fails in production, or when you are asked about it in an interview, you will have to understand it anyway.
3. Always verify. Assistants get things wrong with apparent confidence: they invent functions that do not exist, use obsolete APIs and make subtle logic errors. Your automated tests and the official documentation are the filter.

The skill that really matters — and that assistants do not replace — is knowing what to build, how to structure it and how to check that it works. That is precisely what you have been practising in this module.

Four patterns that derail a lot of people in the year following a first course, with their concrete antidote:

A fifth, less discussed and very common: studying without applying anything for months while waiting to be "ready" to do something real. There is no such moment. You are ready as soon as you start; the rest is learned along the way, exactly as you have just done with your project.

A concrete plan is worth more than any list of resources. This one assumes between five and eight hours a week, which is what you can sustain alongside other things. Adapt it, but keep the structure: there is always a project under way, and the studying serves the project.

Four rules to keep the plan alive:

• Fixed slots in the calendar. "When I can" means never. Two evenings and a stretch at the weekend work better than five hours in a row on a Sunday.
• Short, frequent sessions beat spaced-out marathons: that is how memory works, and marathons leave the code half done.
• End every session with something committed and a note on where you were (09-03). Picking things back up is what eats the most time.
• Review the plan every month. If something does not fit your real life, change it; an abandoned plan teaches nothing.

• Confusing "finishing a course" with "having finished". This course is the foundations. Programming is learned over years and always under construction; that is not bad news, it is the interesting part of the trade.
• Choosing a path by what is fashionable. Fashions change every two years and your own interest does not. Choose by the kind of problem you feel like solving: if it does not interest you, you will not survive the curve.
• Waiting to be "ready". Nobody ever feels ready. Impostor syndrome keeps veterans company too; you live with it, you do not cure it by studying more.
• Learning theory without a project. A topic studied without applying it is forgotten in weeks. Every new thing has to go into something you are building.
• Measuring progress in hours of video. Progress is measured in problems solved and projects published, not in tutorials consumed.
• Tip: keep a learning log. A file where you note down, every week, what you did and what you found hard. In six months it will be the proof of your progress on the day it feels like you are not progressing.
• Tip: find people. A community, a local group, somebody to talk about what you are doing with. Programming alone for a long time becomes an uphill slog, and most of what you learn after a course is learned by talking to others.
• Tip: come back to this material when you need it. Nobody remembers the syntax of sorted with key or the order of open's arguments. Looking it up is not a failure: it is the normal work.

The last three exercises of the course are not about code: they are about direction. Do them in writing, in a file you can reread a few months from now.

Go through the table in section 1 and score your real command of each module from 1 to 3 (1: I recognise it but would not apply it on my own; 2: I apply it with a reference to hand; 3: I apply it fluently). For each module scoring a 1, write one concrete task that would take it up to a 2, in less than two hours of work. Add a list of the five things you can do today and could not do nine modules ago, with the example from the project that proves it.

Using the table in section 4, choose a path and write half a page justifying why: what kind of problems it solves, why they interest you, what time expectation you accept and what three concrete things you would have to learn first. Then define your next project with the definition document from 09-01 — problem, MoSCoW and five requirements — choosing whichever level from section 5 is yours.

Adapt the table in section 9 to your real availability: write down the weekly hours you genuinely have (not the ones you would like), the concrete slots in the calendar and the verifiable result of each two-week block. Add a "monthly review" row and note the exact date of the first one. Keep it somewhere you will see it.

Solution 1. There is no single solution, but there is a way of checking you have done it well: the five things in the second list must be pointable at in your project, with a file and a line. For example, "I know how to separate the logic from the interface" → ledger.py contains no print at all; "I know how to write tests" → tests/test_model.py with nine cases; "I know how to use version control" → git log with twenty commits and a tag. If any claim has no evidence, it is one you are still learning, and that is useful information too. Rubric: does each point have evidence? Do the tasks for the modules scoring a 1 fit into two hours and are they concrete ("write three parametrised tests", not "revise testing")?

Solution 2. A well-made justification talks about problems, not technologies: "I want the tools I use every day to stop wasting my time, so I am starting with automation, and from there probably the back-end" is a solid answer; "I choose data because it pays well" will not sustain the following six months. Rubric: does your justification mention the kind of problem and not just the name of the path? Do you accept the time expectation from the table? Is your next project one step up, not a leap? Does it have its Won't box written?

Solution 3. The plan in section 9 is the template. The two usual failings: planning with your ideal hours instead of your real ones — a fifteen-hour-a-week plan that is really five gets abandoned in week three — and not setting a verifiable result, which makes it impossible to know whether you are on track. Rubric: are the weekly hours realistic and placed in concrete calendar slots? Does each block end in something verifiable (a tag, a script in use, a published repository)? Is there always a project under way, with the studying at its service? Does the first review have a date?

Nine modules ago, the first lesson explained what programming was and the first exercise consisted of writing a print. Today you know how to turn a problem into an algorithm, handle types and validate input, decide and repeat with control structures, break a program down into functions, choose the right data structure and store it on disk, search, sort and reason about the cost of what you write, design classes and organise a package, and work the way work is really done: documenting, debugging, versioning, testing and refactoring. And above all that, you know how to take a project of your own from an idea to a published version, which is the skill nobody can teach you in a lesson because it is only acquired by doing it all the way through once. You have now done it.

What lies ahead is a map, not a homework list: databases, the web, graphical interfaces, concurrency, advanced structures, regular expressions and advanced OOP, each in its own time and always when a project of yours needs it. The paths — web, data, automation, mobile, systems — are chosen by the kind of problem you feel like solving, not by the fashion of the year, and they all start from where you are now. You move forward by building: the next step, always just one, with challenges and reading other people's code as the gym and the official documentation as the source. It is sustained with habits — version everything, test what matters, write for whoever comes next, measure before optimising and finish what you start — and it is protected from the four classic derailments: hopping from technology to technology, tutorial hell, comparing yourself with veterans and not finishing anything. AI assistants make good company if you use them to understand, review and explore alternatives, and bad company if you delegate to them the work that is your learning. And so that none of this stays as an intention, there is the three-month plan with fixed slots, short sessions and a verifiable result every fortnight.

At Alba Studio, Marta is still coordinating Luis and Nuria, Solé Bakery still asks for last-minute changes and the book fair comes round every year. EasyTask went from three print calls to a package with green tests because somebody decided, one day, to solve a small, specific problem and then did not abandon it. Your project now has the same story and it is entirely yours: the idea, the design, every decision and every bug you fixed at eleven at night. That — choosing a problem, understanding it, building the solution and finishing it — is programming, and you have now done it once. Everything that comes from here on is the same operation with more tools. Thank you for making it this far, and may the next project be better than this one.