Forem: Madiha Aijaz

If you think ‘Hello, World!’ is pointless, you missed the lesson.

Madiha Aijaz — Mon, 26 Jan 2026 14:03:36 +0000

Why Every Developer Starts With “Hello, World!"

Madiha Aijaz ・ Jan 26

Why Every Developer Starts With “Hello, World!"

Madiha Aijaz — Mon, 26 Jan 2026 14:01:40 +0000

Every developer has written “Hello, World!”.
Most of us don’t remember the syntax, but we remember the moment it worked.

I didn’t understand my first program. But when “Hello, World!” appeared on the screen, I knew one thing: the computer listened. That was enough.

Calling it pointless misses the point.

It’s Not About the Output

“Hello, World!” doesn’t teach you how to print text. It teaches you that you can:

Write instructions
Run them
Get predictable results

That feedback loop is the foundation of programming. Everything else builds on it.

Beginners Need Proof, Not Complexity

Throwing beginners into frameworks and tooling is a fast way to lose them. “Hello, World!” removes the noise and delivers a quick, undeniable win.

One line.
One result.
Confidence.

Where It Actually Came From

The tradition started in 1972, when Brian Kernighan used “hello, world” in an internal Bell Labs memo (A Tutorial Introduction to the Language B). It later appeared in a 1974 C tutorial, and finally reached mass adoption through The C Programming Language (1978), co-authored by Kernighan and Dennis Ritchie.

That book made it the first program for an entire generation of developers.

Why We Still Use It

Even experienced devs still start with “Hello, World!” when learning a new language or setting up an environment. It’s the fastest way to answer one question:

Does this work?

Final Thought

“Hello, World!” isn’t outdated—it’s foundational.

If you think it’s useless, you’re not more advanced. You’ve just forgotten what starting feels like.

When Sequelize Syncs, Your Database Listens

Madiha Aijaz — Sun, 25 Jan 2026 18:53:08 +0000

You leaned back in your chair as the terminal scrolled past.

Green logs.
No warnings.
The server restarted cleanly.

Confident, you opened the database.

Empty.

Tables were there — but the rows were gone.
Clean. Fresh. Like nothing had ever lived there.

“That makes no sense,” you said out loud.
“I didn’t delete anything.”

You stood up and walked to the whiteboard, uncapping a marker.

“This,” you said, drawing a large rectangle, “is my database.”

You paused.

“It’s not just code,” you realized.
“It’s where my code leaves permanent marks.”

The Database (A Real System)

It’s easy to forget what a database really is.

When you’re working in JavaScript, everything feels temporary.
Variables come and go.
Functions finish and disappear.

But a database isn’t like that.

Tables are real
Rows are real
And once they’re gone, they don’t come back just because you didn’t mean it

You wrote the line you trusted:

sequelize.sync()

“This is just setup,” you thought.
“Just making sure things exist.”

What `sequelize.sync()` Actually Does

You drew two columns on the board:

Left: Sequelize models
Right: Database tables

When your app starts, Sequelize compares these two worlds.

It asks simple questions:

Does this table exist?
Does this model exist?

If a table is missing, Sequelize creates it.
If a table already exists, it leaves it alone.

That’s sequelize.sync().

Helpful. Predictable. Mostly safe.

So why was your data gone?

You looked back at your code and noticed one small detail.

The Option That Changes Everything

You added another line beneath it:

sequelize.sync({ force: true })

One extra option.
One extra word.

It didn’t look dangerous.
It didn’t look dramatic.

But it meant something very specific.

force: true doesn’t ask questions.

It says:

“Whatever is there — remove it.”

What Happens Behind the Scenes

Sequelize doesn’t work in abstractions.

It translates your models into real SQL commands.

When force: true is present, the commands look like this:

DROP TABLE users;
DROP TABLE orders;
DROP TABLE products;

CREATE TABLE users (...);
CREATE TABLE orders (...);
CREATE TABLE products (...);

The tables come back.

Your data does not.

From Sequelize’s point of view, the job was done perfectly.

The Trap You Don’t Notice

You wrote the startup code:

sequelize.sync({ force: true });
app.listen(3000);

It runs every time the app starts.

Which means:

App restarts → tables dropped
App restarts → tables recreated
App restarts → data erased

No crash.
No error.
No warning.

Just quiet obedience.

Tracing the Damage

Step by step:

Server boots
Sequelize connects to the database
Existing tables are detected
force: true gives permission
Tables are dropped
Tables are rebuilt from models

The data didn’t disappear.
It was replaced with emptiness.

When Each One Is Safe

Use sequelize.sync() when you want alignment —
when you want Sequelize to help, not decide.

Use sequelize.sync({ force: true }) only when:

You are experimenting
You expect total data loss
You want a clean slate on purpose

And most importantly:

Never leave it where it can run again.

The Conclusion

ORMs feel gentle.
They feel protective.
They feel like they’re keeping you safe.

But every abstraction still sends real commands to real systems.

Databases don’t understand intention.
They only understand instructions.

It doesn’t guess what you mean.
It does exactly what you tell it to do.

Forem: Madiha Aijaz

If you think ‘Hello, World!’ is pointless, you missed the lesson.

Why Every Developer Starts With “Hello, World!"

Madiha Aijaz ・ Jan 26

Why Every Developer Starts With “Hello, World!"

It’s Not About the Output

Beginners Need Proof, Not Complexity

Where It Actually Came From

Why We Still Use It

Final Thought

When Sequelize Syncs, Your Database Listens

The Database (A Real System)

What sequelize.sync() Actually Does

The Option That Changes Everything

What Happens Behind the Scenes

The Trap You Don’t Notice

Tracing the Damage

When Each One Is Safe

The Conclusion

What `sequelize.sync()` Actually Does