The Pendrive Problem
A Story of Lost Code and Why History Matters
Before Kartikey understood Git, repositories and commits, there was a time when developers shared code in much simpler ways.
This chapter goes back to that time to understand why version control wasn’t a luxury, but a necessity.
“This is the story of the Pendrive Problem.”
Before Git, Before Safety
Kartikey still remembers his college days.
No Git.
No GitHub.
No version control.
Just folders and a pendrive.
He had a project directory that looked like this:
to-do-app/
├── final/
├── final_v2/
├── final_v3/
├── final_latest_v1/
├── final_latest_v2/
Each folder meant only one thing:
“Please don’t touch or open the wrong one.”
The Pendrive Workflow
When Kartikey worked with friends, the workflow was simple.
Painfully simple.
One pendrive.
One person edits the code.
The pendrive passes to the next person.
Sometimes, email replaced the pendrive:
“Here’s the updated zip file.”
“No wait, use the newer one.”
“Ignore the last email.”
At that time, Kartikey didn’t think much of it, until things started breaking.
When Code Starts Disappearing?
One day, Kartikey updates a file.
Later, his friend copies an older version from the pendrive.
Kartikey opens the project again.
His changes are gone.
“No warning.”
“No history.”
“No explanation.”
Just… gone.
He asks:
“Who changed this file?”
No one knows.
The Real Problems Appear
Slowly, the real issues become impossible to ignore.
❌ Overwriting Code
Someone saves their version.
someone else’s work disappears.
❌ No History
There’s no way to know:
What changed?
Who changed it?
Why it changed?
❌ No Collaboration
Only one person can safely work at a time.
Everyone else waits.
❌ No Going Back
If something breaks:
“Hope someone still has the old file.”
Kartikey realizes something important:
The problem isn’t bad developers.
The problem is bad process.
The Folder Timeline Disaster
Kartikey looks at the folder names again.
Each folder is supposed to represent time.
But time is broken.
There’s no clear timeline.
No reliable past.
No safe present.
Just guesses disguised as backups.
Teams Make It Worse
As the team grows, the problem multiplies.
Two people edit the same file.
Three people send updates.
One person forgets to copy the latest version.
Now the project has multiple realities.
Kartikey notices something clearly:
the pendrive workflow doesn’t scale at all.
The Question That Changed Everything
Kartikey asks a simple question:
“Why doesn’t code remember its own history by default?”
Why can’t code:
Track changes?
Know who changed what?
Allow multiple people to work safely?
Why does collaboration feel so fragile?
That’s when Git quietly enters the conversation.
Why Version Control Was Born?
Git explains calmly:
“Pendrives move files.”
“Emails move files.”
“Folders copy files.”
“But none of them understand history.”
Version control was created to solve exactly this:
Preserve every version.
Track every change.
Allow safe collaboration.
Make mistakes reversible.
Git isn’t about commands.
It is about memory and trust.
Pendrive vs Version Control
Git shows Kartikey the difference.
Pendrive World
One person at a time.
No history.
Easy to lose work.
Hard to collaborate.
Version Control World
Everyone works together.
Full history.
No lost changes.
Clear ownership.
Why Git Became Mandatory?
Modern software is:
Large
Collaborative
Long-running
Pendrives and emails were never built for this.
Version control didn’t become popular because it was trendy.
It became mandatory because everything else failed.
Kartikey smiles because now he understands:
“Git didn’t replace pendrives.”
“It replaced uncertainty.”
If you’ve ever lost code, overwritten someone else’s work, or wondered:
“Where did my changes go?”
Version control exists so you never have to feel that again.