DEV Community: Destiny Franks

The Real Problem With Tutorial Hell Is What Tutorials Remove

Destiny Franks — Sat, 04 Jul 2026 17:46:32 +0000

I'd say tutorials are not the villain. The comfort is.

Most people describe tutorial hell like the tutorial is the problem.

I don’t think that is right.

A good tutorial can save you days. It can show you the shape of a tool before you waste time guessing. It can explain a concept better than documentation. It can help you see how an experienced developer thinks through a feature.

The problem starts when tutorials become the whole learning system.

Because tutorials teach by removing friction.

They remove the blank file.
They remove the vague requirement.
They remove the decision of where to start.
They remove the boring debugging.
They remove the messy part where you try one approach, realise it was wrong, and have to rethink it. They remove the exact parts that make someone a developer.

The student feels like they are learning because the screen keeps moving. The instructor writes code. The app works. The lesson ends. Progress is visible.

Then the student closes the video, opens a new project, and suddenly the brain goes empty.

That blank feeling is not proof that the student is dumb.

It is proof that the tutorial did most of the thinking.

Following is not the same as building

Think about a simple todo app tutorial.

On the surface, the student built a todo app.

But what did they actually decide?

Usually, the instructor chose the stack. The instructor named the folders. The instructor designed the data model. The instructor decided what the first feature should be. The instructor handled the bug. The instructor explained which error mattered and which one could be ignored.

The student typed the code.

That is not useless. Typing code still gives exposure. You see syntax. You see patterns. You get familiar with tools.

But exposure is not ownership.

A developer is not only someone who can recognise good code when another person writes it. A developer is someone who can make decisions when nobody is telling them the next line.

That is the part tutorials rarely train.

They train recognition.

They train repetition.

They rarely train judgment.

And judgment is the job.

Tutorials hide the real work

Real development is full of small unclear moments.

You are given a feature like:

“Let users save their favorite products.”

That sounds simple. But now you have to decide things.

Should favorites be a separate table?

Can one user favorite the same product twice?

What should the API return if the product does not exist?

Should the button update instantly or wait for the server?

How do you test it?

What happens when the request fails?

A tutorial can answer all of these for you.

A real project does not.

This is why some people can finish five courses and still panic when asked to build something small. They have seen many answers, but they have not practiced producing answers.

They have watched someone else carry the uncertainty.

Then they wonder why they feel weak when the uncertainty is finally theirs.

AI makes this more serious

This matters even more now because AI can generate code faster than any beginner can type.

That sounds like it should solve tutorial hell.

It does not.

If you cannot reason about the feature, AI gives you more code than you can understand. If you cannot judge the output, AI gives you confidence without control. If you cannot debug, AI turns one error into five more files you now have to read.

The useful skill is not memorising every syntax detail.

The useful skill is knowing what should happen, why it should happen, and whether the generated code actually matches the goal.

This is why trust matters. Stack Overflow’s 2025 Developer Survey found that more developers distrust AI tool accuracy than trust it. The point is not that AI is bad. The point is that AI still needs a developer who can verify, question, and steer it.

GitHub’s Octoverse 2025 also framed AI and agents as one of the biggest shifts in software development. That shift does not remove the need to learn. It changes what learning should focus on.

Less copying.

More thinking.

Less “watch me build this.”

More “you build this, and I’ll help you when you get stuck.”

The opposite of tutorial hell is not no tutorials

Some people overcorrect.

They say, “Stop watching tutorials completely.”

I don’t agree with that either.

Tutorials are useful when they have a clear job.

Use a tutorial to understand a new tool.

Use one to see how a feature can be structured.

Use one when documentation is too dry and you need a human explanation.

Use one when you are blocked and need a quick path forward.

The mistake is using tutorials as proof that you can build.

A tutorial should be a support tool, not the main event.

The main event is opening the editor and building something where the next step is not already written for you.

That is where the skill grows.

Not because struggle is magical.

Because decisions are practice.

Debugging is practice.

Getting stuck is practice.

Reading an error and figuring out what it means is practice.

Submitting your own code and hearing “this part is wrong” is practice.

These are not annoying interruptions to learning.

They are the learning.

This is why I built Staqed the way I did

Staqed exists because I got tired of seeing the same pattern.

People watch. They understand. They feel good. Then they freeze when it is time to build.

So the goal with Staqed is simple: put the building part first.

You start with a real project. You work inside VS Code, or the browser IDE if you prefer. You get a task, a brief, guides, resources, and support. But the work is still yours.

When you submit your code, Staqed validates what you actually built and gives you feedback. Not just “good job” or “wrong answer.” Real feedback on what needs to change.

The AI assistant is there too, but the point is not to dump code and make you passive again. It can help you plan, think, pair, and get unstuck. The coach mode is especially important because sometimes the best help is a question that pushes you to think, not an answer that lets you skip the thinking.

And if you are really stuck, there are human mentors.

That is the missing piece in most learning platforms.

Not more content.

More supported practice.

The real test is the blank file

Tutorial hell is not caused by watching tutorials.

It is caused by never leaving the tutorial environment long enough to become comfortable making decisions.

So a better way to learn is not complicated.

Watch when you need context.

Build before you feel fully ready.

Let yourself get stuck.

Use AI, but don’t let it remove your judgment.

Ask for help, but don’t outsource the thinking.

And judge your progress by what you can build without the video playing beside you.

That is the real test.

Not how many courses you finished.

Not how many certificates you collected.

Not how many hours you watched.

The real question is simple:

When the file is blank and the next step is yours, can you move?

AI Can Make You Faster and Still Make You Weaker

Destiny Franks — Sat, 27 Jun 2026 18:37:20 +0000

Your app can run.
Your tests can pass.
Your pull request can look clean.

And you can still have no idea what you just built.

That is the strange danger of AI coding tools. They can help you move faster, but they can also make progress feel real before understanding has caught up.

This is not an anti-AI argument. I use AI. Most serious developers now use AI in some part of their workflow. The problem is passive usage.

There is a big difference between asking AI to help you think and asking AI to think for you.

Working code is a weak signal

A beginner asks an AI assistant to build authentication.

The AI gives them routes, middleware, models, token handling, password reset logic, and frontend forms. The app works. The protected route blocks guests. The dashboard loads.

That feels like learning.

But ask one level deeper.

Why does the access token expire before the refresh token?
What happens if the verification link is reused?
Why is this middleware running before that controller?
What breaks if the database write succeeds but the email send fails?

Suddenly the “finished” project becomes foggy.

That is the gap AI can hide. It can produce the shape of competence before the learner has built the judgment behind it.

Working code proves that something ran. It does not prove that you understand the design, trade-offs, failure modes, or maintenance cost.

The loop is too smooth. You ask. It answers. You paste. It works. You move on.

But the struggle you skipped was often the part that built judgment.

The lost value of friction

A lot of programming skill comes from friction.

You read an error message.
You misunderstand it.
You search the docs.
You add a print statement.
You break something else.
You trace the data.
You finally see what is actually happening.

That process is annoying, but it teaches you how software behaves when it stops behaving nicely.

AI removes a lot of that pain. That can be good. Nobody becomes a better engineer because they forgot the exact syntax for a library call.

But when AI removes every bump, beginners can lose contact with the code. They stop building a mental model. They stop noticing patterns. They stop asking why the fix worked.

They become dependent on a loop where the only move is “ask again.”

Real engineering is reading code, debugging code, reviewing trade-offs, understanding constraints, and knowing when a solution is hiding a future problem.

Those skills matter more in the AI era, not less.

The research signal is uncomfortable

A 2026 paper by Judy Hanwen Shen and Alex Tamkin studied how developers learned a new asynchronous Python library with and without AI help. The result was uncomfortable: people using AI assistance scored 17% lower on the follow-up evaluation, and the study did not find a statistically significant speedup in completion time.

The important part is not “AI made people worse.” That would be too simple.

The important part is that the outcome depended on how people used the tool.

The weaker patterns were delegation-heavy. The developer handed the task to AI and treated the output as the answer. The stronger patterns kept the developer mentally involved. They asked conceptual questions. They generated code, then worked through it. They asked for explanations and still tried to understand the logic themselves.

That distinction matters.

AI can make learning better. It can explain an error in plain English. It can compare two approaches. It can show why one design is cleaner than another.

But that only works when AI is used as a learning partner.

When AI becomes a replacement for effort, it creates fake progress.

The trust gap is already here

Stack Overflow’s 2025 Developer Survey showed a strange split: AI usage is high, but trust is low. Developers are using these tools, yet many do not fully trust the accuracy of the output.

That is the correct tension.

The future skill is not “trust AI” or “never trust AI.” Both are lazy positions.

The real skill is calibrated trust.

Calibrated trust means you know when to accept help, when to inspect closely, when to test, when to ask for another approach, and when to throw the output away.

A junior developer without judgment may trust AI because the answer looks professional.

A strong developer checks the assumptions. They run the tests. They read the diff. They think through the edge cases. They ask, “What would fail in production?”

That is the skill AI cannot remove from the job. It can make it more important.

Beginners need constraints

The worst way to learn with AI is to keep the assistant fully open all the time.

“Build this whole feature.”
“Fix all the bugs.”
“Write the tests.”
“Explain later.”
“Refactor everything.”

That workflow feels powerful, but it gives the learner too many exits. Every hard moment becomes something to escape instead of something to understand.

A better workflow adds constraints.

Before AI writes code, explain the problem in your own words. After AI writes code, explain the solution back line by line. Change one part manually. Break the code on purpose. Predict the error before running it. Ask AI why the error happened, then verify it yourself. Rewrite the part you understand least without copying.

That is slower than pure generation. It is also the point.

Learning is not the same as output. A generated solution is raw material. The learning happens when you inspect it, question it, change it, and rebuild part of it with your own hands.

Coding education has to change

Traditional tutorials already had a passive learning problem. A student could copy the instructor’s code, finish the app, and still struggle to build anything alone.

AI can make that problem worse.

Now the student does not even need to copy. They can ask for the finished code directly.

That is why the next version of coding education cannot just add an AI chatbot beside the video player and call it progress. The AI has to be part of a learning system that forces thinking.

This is the exact problem Staqed is trying to solve. Students build real projects inside VS Code, but the AI coach should not just dump code. It should ask questions, validate decisions, review real code, and help the student understand why the solution works. Human mentors and code validation matter because learning needs feedback, not just answers.

AI belongs in the learning environment.

It just should not replace the learner.

Use AI, but stay in the loop

The best AI workflow is not passive.

Ask it to explain the concept before it writes the code. Ask for two approaches and the trade-offs. Ask it what can go wrong. Ask it to review your solution before showing its own. Ask it to give hints first. Ask it to quiz you after.

When it generates code, do not treat the output as finished. Treat it as a draft from a very fast teammate who might be wrong, overconfident, or missing your context.

Read it.
Run it.
Break it.
Debug it.

Rebuild the part you do not understand.

That is how AI makes you faster without making you weaker.

The danger is not AI helping developers. The danger is AI letting developers skip the struggle that builds judgment.

Use AI to learn faster, not to avoid learning.

Build a Multivendor E-commerce Website using Django, React & Django Rest Framework

Destiny Franks — Thu, 25 Jan 2024 17:59:05 +0000

Hey, You can WATCH PROJECT DEMO VIDEO BELOW
https://youtu.be/aDHK2-d0_ls

Let's get started!

Hey there fellow developers and entrepreneurs! 🚀 In today's tech-driven world, e-commerce is where it's at! And if you're thinking about diving into the online shopping game, you're in the right place. We're gonna show you how to build an awesome multivendor e-commerce website using Django, React, and Django Rest Framework (DRF).

Let's Get Real: What You Need

Before we jump into the coding magic, make sure you've got Python and Node.js installed on your machine. Trust us, you don't wanna be stuck in dependency hell! Once you're all set, fire up your terminal and let's get started.

Setting Up Shop

First things first, let's create a Django project. Open your terminal and run:

django-admin startproject multivendor_ecommerce

Now that we've got our Django project, let's spice things up with some React goodness. In your terminal, run:

npx create-react-app frontend

Planning the Party: Designing Our Database Models

Every good party needs a plan, right? Same goes for our e-commerce site. We'll need some key models like User, Product, Order, and Vendor and many many more models to keep things organized. Think of them as the VIP guests of our platform (Wink)

Time to Get Fancy: Implementing Authentication and Authorization

We wanna keep our platform secure, so let's set up authentication and authorization. We'll use Django's built-in authentication system and DRF's token-based authentication for our API endpoints. No party crashers allowed!

Let's Get API-tastic: Building the RESTful API

With DRF, creating APIs is a breeze. We'll whip up some serializers and views to handle all the data flow. Our API will be the life of the party, serving up endpoints for users, products, orders, and vendors.

Frontend Fun with React

Now comes the fun part – building the frontend with React! We'll create some killer components for product listings, shopping carts, checkout pages, and more. React Router will keep the party going, handling all the page navigation like a pro.

Time to Get Paid: Integrating Payment Gateway

What's a party without some cash flow, right? We'll integrate a payment gateway like Stripe or PayPal to handle online payments. Customers can pay for their orders securely, and we'll handle all the payment processing behind the scenes.

Let's Go Live: Deploying the Application

The party ain't over till it's over! Once everything's ready to roll, we'll deploy our e-commerce site to the interwebs. We'll set up our server, configure the database, and deploy both the Django backend and React frontend. Time to let the world know about our awesome new platform!

Wrapping Up

And there you have it, folks! We've just built a kickass multivendor e-commerce site using Django, React, and DRF. Whether you're looking to start your own online marketplace or just wanna level up your web dev skills, this project's got it all. So go ahead, roll up your sleeves, and let's get coding!

Happy hacking Buddies! 🚀🛍️

WATCH PROJECT DEMO VIDEO BELOW
https://youtu.be/aDHK2-d0_ls

Send Email using Django & Mailgun - Easy and Free

Destiny Franks — Thu, 20 Apr 2023 15:32:09 +0000

In this short posts i would be showing how to quickly send email to email addresses using django, malgun and anymail packages.

Anymail lets you send and receive email in Django using your choice of transactional email service providers (ESPs). It extends the standard django.core.mail with many common ESP-added features, providing a consistent API that avoids locking your code to one specific ESP (and making it easier to change ESPs later if needed).

Anymail currently supports these ESPs:

Amazon SES
MailerSend
Mailgun
Mailjet
Mandrill (MailChimp transactional)
Postal (self-hosted ESP)
Postmark
SendGrid
SendinBlue
SparkPost

Mailgun is an email automation service built for developers. It offers a complete cloud-based email service for sending, receiving and tracking emails sent through your websites and applications. Mailgun's intelligent inbound routing and storage enables you to know exactly where your emails are ending up.

And finally Django is a free and open-source, Python-based web framework that follows the model–template–views architectural pattern and trust me it is really awesome i'd say.

Let's quit talking and get to work

Firsly, you need to install the anymail package

pip install "django-anymail[mailgun]"

Add anymail to django installed app

INSTALLED_APPS = [
    # ...
    "anymail",
    # ...
]

In your settings.py add your Mailgun api keys and sanbox domains for testing purposes

ANYMAIL = {
    "MAILGUN_API_KEY": "api_key_305834958304534",
    "MAILGUN_SENDER_DOMAIN": 'sandbox467c****.mailgun.org',  
}
EMAIL_BACKEND = "anymail.backends.mailgun.EmailBackend" 
DEFAULT_FROM_EMAIL = "your-sender-email@example.com" 
SERVER_EMAIL = "your-sender-email@example.com"

NOTE: you would need to create an account with mailgun, after successful account creation, follow these steps
i. Login to dashbaord
ii. Sendig
iii. Domain (suboption)
iv. CLick on the sandbox domain url
v. CLick on the api keys
vi. Copy your secret api key and paste above.

For testing purposes, you need to add the recipient email address in the box at the right side of the dashboard
Here is an image

If you have a paid account, you do not need to do this.

After all these are done, create a simple function based view to send the email in views.py

from django.core.mail import EmailMultiAlternatives, send_mail
def send_mail_func(request):
    ...
    send_mail("New Order!", "Hey buddy, you have a new order",
          "sender-email@gmail.com", ["reciever-email@gmail.com"])
    return HttpResponse("Email Sent")

COnfigure the url, and visit this page on your browser.
It should be working now, it did for me.

Here is the anymail api doc

🔴 Build Instagram Clone using Django, HTML & CSS - Tutorial

Destiny Franks — Thu, 06 Oct 2022 00:44:12 +0000

Hello guys, my name is Destiny and welcome to my first Post here. In today's post we'd be Learning how to build an Instagram Clone using Django, HTML & CSS. I Just Love to build these to practice my Django Skills and teach you guys too. I made a tutorial video to help beginners to improve there Django skills to build real world projects.

Watch Complete Tutorial Here
https://youtu.be/qw5ZEvylQBA

➜ Github: https://github.com/desphixs/Instagram-Clone

Note: Subscribe to My YouTube Channel, I also Build a Netfix Clone using Django, you should check it out.