Tutorial Hell
Like many that have come before me, I have landed in Tutorial Hell. When learning to program, Tutorial Hell is when you're stuck feeling unprepared, feeling that you need just one more video or article or tutorial. It is an insidious cycle. For me, I feel confident during a lecture or tutorial. I'm following the instructions, and I feel like I understand why we are doing each step. Then I feel like the rug is pulled out from under me when I go to start building on my own. So, I turn back to the tutorial, and the cycle continues.
Why is this happening? And How do I get out?
To use the training wheels metaphor: I ride my bike with the training wheels from point A to point B, and I feel great, so I take the training wheels off. When I start to ride I immediately fall over. This happens because the training wheels can help you practice the motions of riding a bike, but they remove the resistance, the need to balance. However, the skill of riding a bike is balancing. In other words, training wheels will allow you to practice the motions you need in order to practice and develop the skill of balancing on your bike, but they will prevent you from practicing the skill of balancing on your bike. This is contradiction of learning. You need something to practice the motions, but then you have to use the motions to struggle against a problem.
On leaving Tutorial Hell and where learning happens
I didn't think that I would end up in Tutorial Hell, because I am a teacher. I know how learning happens, and I know I've been doing everything wrong since graduating from The General Assembly Software Engineering Bootcamp. But just like riding a bike with training wheels, tutorials make you feel like you're coding when you're actually just practicing the motions of coding. In order to actually develop and learn, you need to struggle against a real problem. You need to go through the process not just the motions.
Real learning happens in the process not the motions.
But, what does that mean? The process is applying the motions to solve a problem. Going through the motions without the risk of failure does not result in learning because the problem is already solved for you. Think about driving before we all had GPS. You used to know how to get to tons of places with directions because you went through the process of getting there and the motions became automatic. Now, how many times have you pulled up the GPS to get to the supermarket or a friend's house? I believe this is because many of us have offloaded the process to the GPS, and driving is just the motions.
This is the same with a tutorial. The information has already been processed. The author of the tutorial is not teaching you the process, they are showing you the motions. The instructor has chosen the framework, the language, the architecture, etc. This is why we panic at the blank page. It's why we all fall when the training wheel comes off, but falling is a part of the process, failing is where learning happens. Maybe failing is the wrong word, so lets say struggling is the first step to learning.
So what do I do now?
Now, I'm going to struggle. I'm going to go through the process, not just motions. I'm going to plan and build projects without tutorials. I'm going to build until I get stuck, then I will search the documentation for the answer to get unstuck. If we keep with the riding a bike metaphor, I will ride until I fall, then I get back on the bike and keep riding. I'm strengthening muscles here, so I need to accept that this is going to be uncomfortable, I'm going to feel like I don't know what I'm doing, but that's how learning happens.
Now to be concrete because it is all well and good to tell someone it is like riding a bike, or driving a car, or whatever metaphor you want to use, but programming and writing and all other abstract tasks are different because they do not have a predefined goal. When you are physically going from point A to point B, it should be obvious when you get to your destination.
So here is the process that I am going to implement and the rules. I'm giving myself permission to not be creative.
Stage 1: Plan
- What is the problem this app will solve?
- Who is this app or project for?
- Why do you need this app or project?
- When do I expect to complete this project?
- How will I know this is done?
Rules:
- You must be able to answer these questions concretely.
Deliverables for this stage:
- A clearly defined MVP
- User Stories of features
- Wireframes
- A timetable
Stage 2: Build
- Work on one user story at a time.
- Test each feature as you go
- Commit each feature individually
- Get it working, no optimizing before it works.
Rules:
- No tutorials.
- No AI
- Go to the official docs first
Deliverables:
- Public Github Repo
- Deployed Live Demo
Stage 3: Get feedback
- Ask people to use your app, hopefully the who from stage 1. Ask for what they like and what they think could be improved.
- Ask programmers for code reviews. What did you do well? What could be improved?
Deliverables:
- Write a reflection based on the feedback (you also need to process the feedback)
Top comments (0)