> For the complete documentation index, see [llms.txt](https://guide.ivanzakutnii.com/the-hard-way-to-swe-excellence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.ivanzakutnii.com/the-hard-way-to-swe-excellence/learning-path/12-finally-the-framework-and-the-rest-of-applied-stuff.md).

# Finally, a framework and the rest of the applied stack

Now, after building the foundation, choose a framework and start building a complete application.

Choose one technology stack and learn to build with it independently. Do not begin with a giant product. A bounded application with users, data, validation, tests, and deployment is enough to expose the real seams.

Scope the user interface according to your specialization. Even a backend engineer benefits from building a simple interface that exercises the full system, but visual polish does not need to become the project.

A technology stack is the set of tools that lets the whole application work: language, framework, database, operating environment, test tools, build system, and deployment target. For example, a Python web stack might use Django or another framework, PostgreSQL, and a Linux-based deployment environment.

Within your chosen stack, learn to install and update dependencies, configure the application, develop a medium-sized project, test it, package it, deploy it, observe it, and recover from a failed change.

I will not recommend one framework course here because every stack has its own documentation and learning ecosystem.

> Frameworks dominate tutorials and job descriptions, which is why many self-taught programmers start here. In this guide, the framework comes later so you can see what it is doing for you.

If you already started with a framework, you do not need to throw that work away. Use the earlier sections to fill the gaps you can now see: language fluency, debugging, data structures, databases, testing, and Git.

Whether a job description names algorithms and data structures does not determine their value. You studied them to reason about behaviour and trade-offs, not merely to match a keyword.

If you have followed the guide diligently and developed sustainable programming skills, a framework becomes another system to inspect rather than a collection of magic incantations. A new language should also be easier to learn because you can compare its model with one you already understand.

Use AI here as an engineering tool. Let it explain documentation, generate a first draft, or review a diff, but keep the project inside your own mental model. You should be able to trace a request through the system, explain the data model, inspect the tests, and debug a broken deployment without blindly asking the model to try again.

Before calling the project complete, demonstrate that you can:

* run it from a clean checkout using written instructions;
* explain the architecture and the main trade-offs;
* test the critical user flow end to end;
* inspect logs and diagnose an introduced failure;
* deploy a new version and roll back safely;
* show which parts were produced with AI and how you verified them.

The path to becoming a good engineer is hard but rewarding. Learn the fundamentals, apply them to a real system, and keep strengthening the judgment that connects the two.

The end, kind of. Read the appendix too.