Why I finally started using GitHub after 20 years of programming

It took me almost twenty years of programming to properly understand why I needed GitHub.

Not because I didn’t know what it was. I knew developers used it to maintain versions of their code, work with other developers and return to an earlier version when something went wrong.

I simply didn’t have enough reason to change the way I worked.

For a long time I was working almost entirely with one client. One main website. Usually one major piece of programming work at a time. Somewhere along the way I had developed my own crude version-control system.

I created folders with dates.

Whenever a piece of code had been tested and was working properly on the live website, I copied it into the latest dated folder. If something broke later, I went back to the previous working copy.

Sometimes I would have two folders created within a short period and would have to open the files to remind myself which one contained the latest changes. But with one client and a codebase I knew very well, this wasn’t much of a problem.

It was basic, but it worked.

GitHub could probably have improved my workflow even then. The point is, my existing system wasn’t causing enough pain for me to replace it.

That pain came later.

When more clients exposed the problem

Over the past three years I started working with more clients.

Now I could be making changes to a WordPress website for one client, working on a PHP program for another and fixing older code somewhere else. Sometimes two or three pieces of work would be moving at the same time.

The dated folders didn’t suddenly stop working. What changed was how much I had to remember.

Which copy was definitely safe? Had I made another change after creating the latest folder? Was the version on my computer exactly the same as the one running on the server?

Earlier I could answer these questions almost without thinking. Now I found myself checking files, comparing dates and depending increasingly on memory.

That was the weakness in my system.

The folders were storing copies of the code. They weren’t really storing the history of what had happened to the code.

The AWS project forced me to learn GitHub

Then I took up a project where the application was hosted on AWS and connected directly to a GitHub repository.

This time I had no convenient workaround.

Updates had to go through GitHub, so I finally began using commits, branches, pushes and pulls as part of my regular work instead of merely knowing what these things were.

Initially, I found some of it unnecessarily elaborate.

I was used to opening a file, changing the code, testing it and keeping a copy once I knew it worked. Now there were extra steps between changing the code and getting that change where it needed to go.

For a while GitHub felt a bit like paperwork between me and my code.

I was also still thinking in terms of files and folders. It took me some time to understand that the important part wasn’t where GitHub kept the files.

It was the version history.

I could see what had changed, when it had changed and return to a known working state without depending on whether I remembered correctly what I had done three days earlier.

Still, at that point I was mainly using GitHub because the project required it.

Had that AWS setup allowed me to continue with my dated folders, I suspect I would have continued doing exactly that.

The financial tool that changed my mind

A couple of months ago, the tool suddenly stopped working properly.

I couldn’t immediately find the cause. There had been enough changes that looking at the latest code wasn’t telling me where the problem had started.

Eventually, it took me almost three days to trace it.

But I had a more urgent problem first.

The live website couldn’t remain broken while I spent three days debugging the code.

So I restored the last working version from GitHub.

The website was back.

This is when realized the core benefit of working with GitHub.

Until then, I had mostly thought of version control as a better way of keeping old versions of code. What I hadn’t appreciated was that it allowed me to separate two completely different problems.

The first problem was getting the website working again.

The second was finding out why it had broken.

I didn’t have to solve both at the same time.

Once the working version was restored, the pressure came down immediately. I could go back to the faulty code, compare the recent changes and test things properly without every failed attempt affecting the live website.

That was much more useful than simply having a backup.

My dated folders had given me copies.

GitHub gave me a history I could work with.

What I learned

I came to GitHub very late by developer standards, and I don’t think there is much point pretending otherwise.

But I also don’t think my old system was ridiculous.

It had grown around the way I worked at the time. One long-term client, fewer simultaneous changes and a codebase I knew so well that much of its history was sitting in my head anyway.

For years, that was enough.

Then I began handling more projects and more changes at the same time. Depending on memory became less convenient and, more importantly, less safe.

That experience also changed the way I think about development tools.

You can read about a tool for years and understand perfectly well what its features do. But sometimes you don’t really understand its value until the problem it solves lands on your desk.

GitHub could have helped me years earlier.

I simply didn’t feel the need badly enough.

The work eventually made the decision for me.