Why So Many People Quit Coding (Even When They Love It)

Let’s be honest.

Nobody starts learning how to code and thinks,
“Yay! I can’t wait to be frustrated and overwhelmed!” 😩

But somewhere between writing your first hello world and facing your 10th error in one hour…

People start to tap out.

Here’s why people give up on their coding journey:

1. They want it fast, not deep.
They want to “learn fast and get a tech job in 3 weeks.”
But coding is a process. Not magic.
You have to understand the logic, not just memorize tutorials.

2. Tutorial Hell is real.
They hop from one YouTube video to the next without building anything.
It feels productive, but it's just digital procrastination.

3. Impostor syndrome creeps in.
They compare themselves to someone on LinkedIn who built an app in 1 month.
They forget that they’re on chapter 2, comparing it to someone else’s chapter 20.

4. No accountability.
When nobody is checking in on you, it’s easy to “rest” for one day...
Then that day becomes a month.
Then the dream dies a quiet death.

5. They don’t know why they’re learning.
If your only reason is “tech pays well,”
the first moment it gets hard, you’ll start asking yourself:
“Is this even worth it?”
But when you have a clear WHY you push through the discomfort.

Coding will stretch you. It will test your patience.
But it will also grow you. It will open doors.

Not everyone who starts finishes.
But everyone who finishes will tell you it was 1000% worth it.

So, before you quit, ask yourself:

Did I really give it my all… or did I give up when it got uncomfortable?

You’re not behind.
You’re not too late.
You just need to start again with clarity and consistency.

💻 Keep going. The future still needs your code.

🔥🔥 Project 7 — Job Listing Platform

👋 Hey Campers! Welcome to Project 7 🚀
I hope you’re doing well, staying consistent, and coding even when it feels hard 💪
You’ve come a LONG way — from basic JavaScript to Express and APIs.
Now it’s time to combine everything into a real-world style project.

This time, We’re building a simple job listing website, similar to platforms where people post jobs and others browse or apply-- Using HTML, CSS, JavaScript, Node.js, Express
➔Focus on logic, structure, and clarity, not perfection

🎯 Project Goal
To practice:
➞Backend logic with Express
➞CRUD operations (Create, Read, Update, Delete)
➞Handling users and jobs
➞Frontend ↔ Backend communication
➞Clean UI using plain HTML & CSS
➞Project organization and debugging

🧩 Core Features (Must Have)

👤 1️⃣ User Accounts (Simple Version)
Users should be able to:
➤Create an account (username + email is enough)
➤Log in (no advanced auth yet — keep it simple)
➤Stay logged in during the session (basic logic)
💡 Think: “Who is using my app right now?”

🧑‍💻 2️⃣ Job Posting
Logged-in users can:
➤Post a new job
Each job should include:
➞Job title, Company name, Job description, Location (optional),Date posted
➤Each job should belong to one user.

📋 3️⃣ Job Listings Page
All users (even not logged in) can:
➤See a list of all jobs
➤View job details clearly
➤Understand who posted the job


✏️ 4️⃣ Update & Delete Jobs
Only the job owner can:
➡Edit their job
➡Delete their job
💡 Think carefully about:
“Who is allowed to do what?”

🔍 5️⃣ Backend API
Your backend should support:
➜Creating users
➜Creating jobs
➜Fetching all jobs
➜Fetching single job
➜Updating job
➜Deleting job
Use:
➙File-based storage (JSON) for now
➞Clean error messages

🌈 UI Expectations (Frontend)
your UI should:
➙Be easy to understand
➞Have clear buttons and forms
➞Show success & error messages
➞Not look cluttered

Examples of pages:
➣Home / Job List
➣Login / Register
➣Post Job
➣My Jobs
💡 Simple ≠ ugly


🌱 Optional Features (Bonus — If You Can)
➔Search jobs by title or company
➔Filter jobs by location
➔Show “My Jobs” page
➔Show number of jobs posted
➔Confirmation before deleting a job

🧠 Hints 😃
➣Think about data structure before coding
➣Decide:
  ➞How users are stored
➞ How jobs reference users
  ➞Build backend routes first
  ➞Then connect frontend
  ➞Test each feature step by step

Small steps → big progress.👌👌

🐞 Debugging Checklist (VERY IMPORTANT)
Before asking for help, check:
✅Server starts without crashing
✅ Routes respond correctly
✅ JSON files are valid
✅ Data saves after refresh
✅ Only owners can edit/delete jobs
✅ Errors are handled cleanly
✅UI updates after actions
✅ No duplicate IDs
✅Console logs make sense

If something breaks: 👉 slow down
👉 log values
👉 isolate the problem
This is how real developers work.

When you’re done building your project:
💥 Push to GitHub ✅
💥 Deploy with GitHub Pages / Netlify 🌍
💥  Share  your repo + live demo with us 🎉
💥invite a friend,
      and as always —

💥stay well, stay curious, and stay coding ✌️

Things Feel Hard Until You Actually Start

In tech, many things sound difficult long before we ever try them.

Before learning Docker, I already believed it would be complicated
not because I had worked with it, but because of how people talked about it.

Just hearing terms like image, container, and DevOps workflows made it feel heavy.

But once I started learning Docker and using it in a project, it was far more understandable than I expected.

Most of the confusion faded once I stopped listening and started doing.

This isn’t only about Docker.

The same thing happens for other terms.

From the outside, things look overwhelming.
Once you’re inside them, they turn into clear steps you can work through.

The real issue is that many juniors never reach that point.
They stop at the idea of difficulty.

We often hear experienced engineers talk in advanced terms,
and we forget that they also started by not understanding much.

Fear usually comes from: not starting, overthinking, and comparing yourself to people who are further along

So the solution is to start even if things are not clear yet.

If you’re a junior:

don’t let technical language scare you

don’t wait until everything feels clear

start small and learn as you go

You don’t need full clarity to begin.
You gain clarity by starting.

Most projects look difficult
until you sit down and actually work on them.

That’s where learning really happens.

@edemy251

Real experience doesn’t come from watching more tutorials. It comes from building, thinking, and solving real problems. Tutorials are useful at the beginning, but staying there too long gives a false sense of progress. You may understand concepts, but you don’t truly learn until you apply them on your own.

The best way to gain experience is to start with a problem you actually see or face. It can be something small, a task you repeat every day, a manual process, or a tool you wish existed. Start there. Google similar ideas, read how others solved it, and then try to build your own version. It doesn’t need to be perfect. What matters is that the decisions are yours.

When you work on your own project, learning becomes real. You think about structure, logic, edge cases, and how things behave in real situations. You get stuck, search for answers, read documentation, try again, and improve. This is exactly how professional developers work.

Spending too much time watching tutorials without writing code keeps your hands clean, but experience comes when your hands get dirty. Writing imperfect code, fixing it, and improving it over time teaches you far more than any video can.

Experience is built by doing real work, not by waiting to feel ready. Start small, build something real, and learn along the way.

@edemy251

🎄✨ Happy Christmas, Campers! ✨🎄
May your code compile on the first try, your bugs take a holiday, and your merges be conflict-free.😅
Wishing you a holiday with no errors and infinite joy! 🎁💻🎅

If you’re a student struggling with self-discipline, time management, or staying consistent, The Art of Laziness is a book worth reading. It doesn’t teach you to avoid work—instead, it helps you stop wasting time and energy. For students, the message is simple: focus on the right subjects, study with intention, remove distractions, and build disciplined routines. When your effort is structured, results follow without burnout.

You can download PDF here

Things You Should Do as a Beginner Developer

1. Focus on fundamentals, not memorizing syntax

As a beginner, you don’t need to memorize every keyword or function.

Start by understanding the basics: how things work, why they work, and how different pieces connect.

Even senior developers don’t remember everything, they regularly check documentation and references.

2. Build a project

Projects are where real learning happens.

When you build something, you face real problems, real errors, and real decisions.

That experience teaches you more than watching tutorials or copying code.

3. Get comfortable using documentation

Reading documentation is a core developer skill.

You’re not expected to know everything by memory.

What matters is knowing where to look and how to understand what you find.

4. First start with one technology practice enough to gain confidence

Jumping between tools can slow your progress.

Spending enough time with one language or framework helps you build problem-solving skills and confidence.

Those skills often carry over when you explore other technologies later.

5. Searching is part of the job

Every developer searches for answers errors, examples, and best practices.

The skill isn’t knowing everything.
It’s knowing how to find and apply information.

6. Accept bugs, confusion and stay consistent

Feeling confused or stuck is normal, especially at the beginning.

Progress doesn’t come from being perfect it comes from showing up regularly, even when things don’t make sense yet.

@edemy251

Wishing you a blessed Timket.❤

Apologies for the pause this month; finals and projects have been overwhelming. We'll get started soon!

🚀 Week 8 Day 8 — MongoDB Foundations & Environment Setup

Alright campers 🔥💙
Today we step into the database world — where your app stops being forgetful and starts having memory.


🌳 BIG IDEA — What Is MongoDB Really?
Think of your backend like a company:
➞Express = receptionist handling requests
➞Routes = departments
➞Controllers = workers doing tasks
➞MongoDB = warehouse where all records are stored
➤Without a database:
Your app lives only in RAM — like writing on water.
➤With MongoDB:
Your app writes on stone.

MongoDB is a NoSQL document database — which means it stores data as flexible documents instead of rigid tables.

🧱 1️⃣ MongoDB Ecosystem — The Tool Family
MongoDB is not just “one thing”. It’s like a kitchen with multiple tools.

🗄 MongoDB Server
The actual database engine running and storing data.
Like:
The warehouse building itself

🌍 MongoDB Atlas
Cloud-hosted MongoDB.
Like:
Renting a secure warehouse in the cloud instead of building one at home.
Good for:
➢deployment
➢teamwork
➢production apps

🧭 MongoDB Compass
Visual GUI for MongoDB.
Like:
Google Maps for your database — browse, search, edit visually.

💻 mongosh (MongoDB Shell)
Terminal interface.
Like:
Command center — type commands directly to DB.
Best for:
➥power users
➥scripting
➥debugging


🏠 2️⃣ Local MongoDB Installation — Why Local First?
Running MongoDB locally is like:
Learning to cook in your own kitchen
before cooking in a restaurant.
Why it matters:
➡faster
➡no internet dependency
➡safe experiments
➡no billing worries

Install Steps (Local)
Go to MongoDB Community Server download page → install → start service.
After install, MongoDB runs as a background service.
Test it:
Bash

mongosh

If shell opens → MongoDB is running ✅

☁️ 3️⃣ MongoDB Atlas — Cloud Setup
Atlas = MongoDB hosted online.
Use Atlas when:
➛deploying apps
➛working in teams
➛need remote DB
➛need backups & scaling

Atlas Setup Flow
Think of Atlas like opening a bank account:
Step 1 — Create account
Step 2 — Create cluster
Cluster = database machine group
Step 3 — Create DB user
Username + password for access
Step 4 — Network access
Allow your IP address
Step 5 — Get connection string
Looks like:

mongodb+srv://username:password@cluster.mongodb.net/

This is your database address — like a phone number.

🧭 4️⃣ MongoDB Compass — Visual Explorer
Compass is beginner heaven.
Instead of typing commands, you:
click
browse
edit
search
insert documents

Like:-File Explorer for your data warehouse.

Connect with Compass
Paste connection string → connect → explore DB.
You can:
➤create database
➢create collection
➢insert document
➢edit document
➢filter data

💻 5️⃣ MongoDB Shell — mongosh Basics
mongosh = talking directly to MongoDB.
Like chatting with the warehouse manager.
Start:
Bash

mongosh

Create / switch database

Js

use schoolDB

MongoDB creates it only when first data is inserted.
Why?
Because MongoDB is lazy by design — it doesn’t create empty containers.
Create collection & insert document
Js

db.students.insertOne({
  name: "Sara",
  age: 22
})

Now DB + collection exist.
➢View documents
Js

db.students.find()

🗂 6️⃣ Data Structure — DB → Collection → Document
MongoDB structure is like:

Database
   ↓
Collection
   ↓
Document

Analogy:
Library
   ↓
Bookshelf
   ↓
Book

➤Database
Big container for related data.
Examples:
ecommerceDB,blogDB,chatAppDB

➤Collection
Group of similar documents.
Examples:users,posts,messages

➤Document
Actual data record — stored as JSON-like object.
Example:
Json

{
  "name": "Abel",
  "email": "abel@mail.com",
  "age": 21
}


🧾 7️⃣ BSON vs JSON — Why MongoDB Doesn’t Store Pure JSON

Students often ask: “If MongoDB uses JSON — why mention BSON?”
Because MongoDB actually stores:
BSON = Binary JSON
Think of it like:
➡JSON = readable recipe
➡BSON = compressed packaged food

Why BSON exists
Because databases need:
➥faster reading
➥indexing
➥binary data
➥dates
➥object IDs
➥better performance

JSON cannot store:
➞dates properly
➞binary data
➞special types

You write JSON — Mongo stores BSON behind the scenes.

🆔 8️⃣ ObjectId — MongoDB’s Built-in ID System
Every document automatically gets:

_id: ObjectId(...)

Like:
Every passport has a unique number.
Example:
Json

_id: ObjectId("65f8c1a2e8...")

Why ObjectId matters
It encodes:
➡timestamp
➡machine id
➡process id
➡counter
Meaning: IDs are globally unique without central authority.
Like generating unique serial numbers without a server asking permission.

🧠 If MongoDB Didn’t Use ObjectId…
You would need:
➥custom ID logic
➥collision checks
➥UUID packages
➥more overhead
MongoDB removes that burden.

💥 Week 8 Day 8 — MongoDB Foundations Challenges


🧩 Challenge — MongoDB Environment Setup
✅ Task 1 — Install Local Tools
Install on your machine:
➥MongoDB Community Server
➥MongoDB Compass
Then run:
Bash
mongosh
If it connects → local MongoDB is working ✅
✅ Task 2 — Create Local Databases
Using Compass or mongosh, create:
➥At least 2 databases
➥Each database must have 2 collections
➥Each collection must have at least 2 documents
Example themes: schoolDB, shopDB, blogDB — your choice.

✅ Task 3 — MongoDB Atlas (Cloud)
➞Create a MongoDB Atlas account and:
➞Create a free cluster
➞Create a DB user + password
➞Allow your IP address
➞Connect using Compass

✅ Task 4 — Create Cloud Databases Too
Inside Atlas connection:
➞Create 2 databases
➞2 collections each
➞Add documents inside

When you are done,
💥invite a friend,
      and as always —

💥stay well, stay curious, and stay coding ✌️

Hey everyone ✌️✌️✌️✌️
I have this Hackaton and I need you to vote me 🤗🙏🤗🙏🥹

Go here

https://v0-v0prompttoproduction2026.vercel.app/browse

and search @messibre  under Marketing category -you will get a golden colorized "campaign kit studio" - click vote using your vercel account.
Thanks a lot for your help 🙏🙏🙏🙏🙏

Before your final year ends, or at least before you graduate, challenge yourself.

Don’t just aim for the degree.
Aim for proof of work.

Have at least:

1. 2–3 solid, real-world projects (not just tutorial copies)

2. Real-world experience

3. At least one deployed project people can actually use

4. A GitHub that shows consistency, not just empty repos

5. Real problems you struggled with and solved

6. Experience working with APIs, databases, authentication, deployment ....

University gives you theory.
The market asks for experience.

@edemy251