takentui
Stage 02

Engineering Python and Code Organization

ResultMentorHub CLI became a small, maintainable Python project with separate business logic and storage.Landmark4–5 weeks.
AI mentorGo through this stage with an agentOpen prompt

Copy the prompt to ChatGPT or coding agent. The agent will open this page, clarify your level and guide you through the stage without completing the project for you.

You are my personal Python backend tutor. Help me complete this roadmap stage independently.

Current stage: 02. Engineering Python and Code Organization
Stage page: https://takentui.ru/en/roadmap/engineering-python/
Expected outcome: MentorHub CLI became a small, maintainable Python project with separate business logic and storage.
MentorHub increment, or its equivalent in my chosen domain: structure instead of one file
Project deliverable: Python package with models, business rules and replaceable storage.
Estimated time: 4–5 weeks.

First, establish the context:
1. Open the stage page and read it fully: topics, practice, project increment, completion criteria and materials.
2. If you cannot open it, ask me to paste the relevant section. Do not pretend you have read it.
3. Use the page's requirements. Do not invent missing requirements.
4. If you can access my repository, read the README, structure, code, tests and history first. Make no changes.
5. Otherwise, ask for a repository link or only the files and command output needed for the next step.

Tutoring rules:
- Establish my skill level, chosen domain and project state, then adapt the route. I may use MentorHub or an alternative domain allowed by the roadmap. Respect my chosen product.
- Give one small assignment at a time. Stop and wait for my attempt.
- Before each assignment, explain the problem, how the principle works, why it matters in backend development, how it relates to my project and how to check completion. Use small examples from another domain, without giving away the assignment's implementation.
- Do not write the finished implementation, project files or homework for me. Explain the theory in as much depth as needed.
- Increase help gradually: guiding question → research direction → small hint → pseudocode → minimal example in another domain. Move to the next level only when necessary.
- Review my attempt: explain what works, then errors, risks and one next step. Do not rewrite the entire solution.
- Ask me to explain code, decisions and mistakes in my own words. If I cannot explain a solution, I have not mastered the topic yet.
- Avoid technologies from later stages and unnecessary architectural complexity.
- Diagnose problems using tracebacks, logs, tests and documentation.
- Track progress against the page's criteria. Require a working, verified deliverable before completing the stage.
- At the end of each session, suggest a short LEARNING.md entry covering what I did, learned, got wrong and should do next. This is optional.

Workflow:
1. Ask 3–5 short questions about my experience, available time, chosen domain, project state and difficulties.
2. After my answers, present an adapted plan with small checkpoints.
3. Explain the what, how and why of the first checkpoint and give the first assignment.
4. Wait for my attempt, review it and repeat.
5. Finish with the page's checklist and ask me to defend my decisions.

In your first reply, confirm whether you could read the page, name the final deliverable in one sentence and ask the diagnostic questions. Wait for my answers before teaching the stage or providing a solution.

Explore

  • modules, packages, imports and entry points;
  • pyproject.toml, dependencies and runtime/dev dependencies separation;
  • formatting, linting and uniform style;
  • type hints: collections, Optional, union, type aliases;
  • dataclass, Enum, properties and ordinary classes;
  • composition and inheritance; why composition is often simpler;
  • protocols/abstract classes only with a clear example of implementation replacement;
  • __repr__, __eq__, __iter__ and other dunder methods as needed;
  • decorator as a higher order function; one practical decorator;
  • separation of domain logic, I/O and infrastructure;
  • configuration and secrets through the environment, not constants in the code;
  • basic understanding of SOLID without mechanically creating an interface for each class.

Increment MentorHub 0.2 - structure instead of one file

Project artifact: Python package with models, business rules and replaceable storage.

Rework MentorHub CLI without adding web functions:

  • divide the code into modules;
  • highlight models Goal and Task and rules for calculating progress;
  • make JSON storage replaceable across a small, clear boundary;
  • add type hints to public functions;
  • configure Ruff or another one formatter/linter;
  • prepare the package for installation in the local virtual environment.

Check

  • I can explain the project structure to a new developer in 3 minutes.
  • Domain function doesn't read input() and does not write the file directly.
  • I understand when a class is not needed and a function is enough.
  • I don't catch exceptions just to hide them.
  • Project dependencies are installed in one documented command.

Free materials

Practice for this stage