When you walk into a modern software company today you will observe a buzz of activity: You can see constant Integration pipelines running automated tests, a dozen developers all throwing their Jeff Skillington code into the same repository, and people around the world doing instant peer reviews. It is a greased mechanism of disseminated thought.

However, to comprehend why such tools of Git, GitHub, and GitLab are viewed as obligatory oxygen of developers, we have to trace the period when it was still possible to imagine the reality without them. We have to consider the period of Sneakernet. ]
The server was not the Source of Truth before we had the cloud. It is a physical item like in most cases a USB pendrive or portable Hard Disk Drive (HDD) and handed over between hands. This was not only annoying, it was a base stranglehold on the human mind.

A Workflow that is Serialized is known as the Bottleneck. We live in the modern age and we assume the existence of Concurrency. When there are 20 developers of a startup, all of them can write code at 10: 00 AM on a Monday.
The concurrency limitation was precisely one in the Pendrive Edition.

This is the “Pendrive Workflow," and it is the largest inefficiency in software history. The pendrive was a physical write lock. Without the pendrive that had to be inserted by Developer A to add the feature of a login, Developer B (the one working on the database) and Developer C (the one working on the UI) would have been grounded. They were forced to sit and wait until Developer A walked to their side and gave them the drive to him.

figure 1 : Pendrive workflow vs git workflow

The Statistic of Wasted Time: In a serial (pendrive) workflow of 4 developers, It would take a single team of developers 2 hours to build one task; in total, it would take 8 hours to make the 4 tasks be integrated assembly (sequential). The code time in a modern Git setting, where the 4 work simultaneously and merge after each iteration, is 2 hours and maybe 30 more to merge. The Pendrive Era had a mathematical efficiency of throughput in a team that was 300 to 400% less.

The madness of simultaneous editing

Although physical drive is not present, the initial file-sharing techniques, such as email or a shared network folder would not allow addressing the issue of concurrency. In the event that more than one developer tried to work on the same file simultaneously, the changes would be conflicting.

There would be no system that could control such changes and the user who saved his file before others will overwrite all the work of others. The server did not understand how to combine text; the newest file was accepted as the truth, the result of which is instant loss of data along with corruption.

Silent Fix Paradox: Why We No longer Learn.

The inefficiency in learning the mistakes of others was probably the most pernicious harm that Pendrive Era inflicted. In an engineering society of the present day, mistakes make data. Whenever a bug comes we want everyone to notice, know why it has occurred and see how it was fixed completely so that they will not do it again. This is automatically accomplished with the way that Modern Version Control Systems (VCS) displays the diff- the literal difference between the broken code and the corrected code.By using the physical file transfer and overwrites, the Pendrive Era killed this loop of learning.

The Shared Term Paper Analogy

To appreciate this, take the case of two students in a university, Alice and Bob, and they are doing one term paper. They do not have Google Docs and their only laptops are one that they share back and forth (the "pendrive").

1. The error: on Tuesday, Alice has the laptop. She puts a paragraph on Australia and gives it the wrong answer, that the capital of Australia is Sydney. She copies the paper and gives the laptop to Bob.

2. The Discovery: Bob opens the paper on Wednesday. He reads the paragraph and goes to realize that Alice is not right.

3. The “Pendrive Repair: Bob emphasizes the name of the city Sydney, then he deletes it and then he types in Canberra and he then hits Save. The file is overwritten. The proof of the mistakes is lost.

4. The gap in education: Thursday Alice receives the laptop with a gap in her education. She reads out the paper; it is fine. Alice has not forgotten that Sydney is the capital of Australia. Since Bob fixed her error silently by erasing the file and replacing it, she was not given an opportunity to be corrected.

The manner this unfolded in software

This was the situation in the Pendrive Era, where software teams would replicate it on a daily basis. A less experienced developer would create a section of code that was inefficient, such as a loop that was too slow, save it to the pendrive, and give it to a more senior developer. The bad code would be identified by a senior developer who would be in possession of the drive later. They would not write an email and tell them what the problem is; they would have to take too long. They only would rewrite the function into the correct format, save across the file and proceed further.

By the time the junior developer returned the code, his bad loop was now good code in place of that. They had no idea:

That they had made a mistake.

What the mistake was ?

The way the senior developer has solved it.

Since no one was able to remember the history of the mistake, then the knowledge within the organization did not grow. The errors were re-enacted again and again since the mechanism of corrective action was invisible.

The Ornuten feebleness of the “Origin of Truth

The "Master Branch" during the Pendrive Age was not some safe database in the cloud, but a bit of cheap consumer product in the pocket of some person.
Even in case the developer with the pendrive spilled coffee on it or dropped it in a car park, or the file system (FAT32) was wiped out because the pendrive was ejected carelessly, the company did not lose a day of work. They lost the entire project.

This was a stressful high environment referred to as the Bus Factor of 1. In case the individual possessing the pendrive was struck by a bus (or simply went on holiday), the intellectual property of the company was basically lost until the time they reappeared.

Why Modern VCS is the Answer

We switched to systems such as Git not because it is a cool thing to do, but to address the following bottlenecks:

1. Distributed Truth (Solving the Bottleneck): All the developers have a complete copy of a repository on their computer. There is no need in the "pendrive" to be working. 100 people may work at the same time.

2. The Merge (Solving Overwrite): Git is a combination of mathematical algorithms to blend work. In case Alice alters line 10 and Bob alters line 20Git automatically combines them. No one is overwritten .

3. The History Log (Solving the Learning Gap): Today, when a senior developer fixes a bug, they push a Commit. The junior developer sees the notification, clicks the commit, and sees red lines (their old code) next to green lines (the new, better code). The learning is instantaneous and permanent.

In the end, every great product starts as a solution to a painful problem. Git didn't just appear; it evolved because someone refused to accept the bottleneck. That is the true cycle of innovation: feeling the pain, solving the problem, and turning a project into a product that helps us all