Tutorial hell - Transitioning from Following to Creating

What you’re describing is a common challenge faced by many learners transitioning from tutorials to building their own projects. It’s often referred to as “tutorial hell,” where you’ve followed step-by-step instructions enough times to understand the syntax and concepts, but when faced with a blank slate and no guidance, it’s hard to know how to start.

The Problem: Transitioning from Following to Creating

In tutorials, you’re often given a clear set of instructions and a predefined problem to solve. You don’t have to worry about how to structure your code or what the overall design should be; you just follow the steps. But when you try to build something from scratch, you suddenly have to think about the big picture:

• What problem am I solving?
• How do I break this problem into smaller, manageable pieces?
• What will the structure of my program look like?
• How do I decide which classes, functions, and modules to create?

This can be overwhelming because you’re now responsible for both thinking and doing, whereas in tutorials, you only had to focus on the doing part.

Why This Happens

This issue arises because learning to code is a bit like learning to play music. In a tutorial, it’s like playing a song by following the sheet music—you know which notes to hit, but you’re not necessarily learning how to compose a new song yourself. When it’s time to write your own song (i.e., build a project), it’s not enough to know how to play the notes; you need to understand why those notes work together to create music.

The Key Skills You Need to Develop

To move from just following along in tutorials to creating your own projects, you need to develop a few key skills:

1. Problem Decomposition: Learning how to break down a large problem into smaller, more manageable pieces. This is like taking a big, complex task and dividing it into smaller, doable steps.

2. Program Design: Understanding how to design a program from the ground up, including how to structure your code, how to think about objects and classes in OOP, and how to plan out your functions.

3. Incremental Development: Learning to build your program in small pieces, testing each part as you go. This ensures you’re always making progress and not getting stuck or overwhelmed by the whole project.

4. Debugging and Problem Solving: Getting better at figuring out what’s going wrong when your code doesn’t work, and developing strategies to fix it.

How to Overcome This Challenge

Let’s dive into how you can overcome this challenge using these key skills. I’ll guide you through them using a step-by-step process that you can apply to your next project:

1. Problem Decomposition

Imagine you want to build a simple “To-Do List” application. The idea itself is straightforward, but how do you break this down?

• Step 1: Identify the Core Features

  • What should this application do?
  • Example features:
    • Add a task.
    • View all tasks.
    • Mark a task as completed.
    • Remove a task.

• Step 2: Break Down Features into Smaller Tasks

  • Let’s take “Add a task.” What do you need to do to make this happen?
    • Create a way to store tasks (a list, a file, or a database).
    • Write a function to add a new task to this storage.
    • Design a user interface (console, GUI) for input.

This process of breaking down features continues until each part is small enough that you feel confident tackling it individually.

2. Program Design

In OOP, design is critical because you’re thinking about how to model real-world entities as objects and classes. Let’s use the To-Do List example again:

• Step 1: Identify the Objects

  • What are the main entities in your application?
    • Task: Represents a to-do item.
    • ToDoList: Manages a collection of tasks.

• Step 2: Define the Responsibilities of Each Class

  • Task Class:
    • Properties: description, is_completed.
    • Methods: mark_completed(), __str__().
  • ToDoList Class:
    • Properties: tasks (a list of Task objects).
    • Methods: add_task(), remove_task(), get_all_tasks().

• Step 3: Sketch the Relationships

  • How do these classes interact? The ToDoList class might hold and manage multiple Task objects. You could start by designing these interactions on paper or in a simple diagram.

3. Incremental Development

Start small. Maybe begin by implementing the Task class:

• Step 1: Write and test the Task class with basic functionality.
• Step 2: Move on to the ToDoList class, making sure to test it with a few tasks.
• Step 3: Build the user interface or console input to interact with these classes.

Each step adds a bit more to the project, but you’re always working with something that (mostly) works.

4. Debugging and Problem Solving

This skill improves with practice, but you can start by learning how to:

• Read error messages carefully: They often tell you exactly where the problem is.
• Use print statements or a debugger: To track down what’s happening inside your code.
• Google effectively: Chances are, someone else has had a similar problem.

Practice Approach

1. Start with Small Projects: Pick projects that are challenging but not overwhelming. This might be something like a calculator, a basic text-based game, or a simple CRUD (Create, Read, Update, Delete) app.

2. Work on Real-World Projects: Try to build projects that solve real problems, even if they’re small. This makes the process more engaging and meaningful.

3. Learn by Doing: Tutorials are helpful for learning syntax and concepts, but building your projects forces you to think critically and apply what you’ve learned.

4. Reflect on Your Process: After each project, take time to review what worked and what didn’t. What was hard? What did you learn? This reflection will help you improve.

Gauging Your Understanding

Let me check in on a few things before we proceed further:

1. How comfortable are you with the idea of breaking down a project into smaller tasks?
2. Have you worked with classes and objects in Python? Do you understand how to design a class and think about its responsibilities?
3. When you code, do you tend to build everything at once, or do you try to build and test in small steps?

Your responses to these questions will help me tailor the next part of our discussion.