For Non-Programmers: An Idea from Programming!
Linus Torvalds has changed the world twice now, dangit, which is 0 (±2 due to rounding errors) more times than I have changed it. His first world-changing contribution was of course, Linux, and his second was git. Linux is Torvalds’ My Antonia — widely regarded as his most significant contribution to the world. That means git must be his Death comes for the Archbishop.
See the parallel I’m drawing here? I could have sworn I’ve mentioned this in a previous post. The former is widely regarded as his masterpiece, but the latter is the real magnum opus — it’s the one I would tell friends to read.
Many years ago, my wife came home and found me sitting alone in the dark with tears in my eyes: I had just finished the last episode of Battlestar Galactica (and it was lovely). Have I mixed enough metaphors here? The final episode of BSG is Willa Cather’s Death Comes for the Archbishop is Torvalds’ git.
However, while git may be incredible software, the underlying ideas are the real star.
What git is actually about
Git is not brilliant because it’s written in C and was able to host merges of the Linux kernel in less than a few weeks. It is not brilliant because it led to GitHub and arguably the mass adoption of open-source software as a business strategy. Git is brilliant because it’s a codified workflow for idea experimentation and reconciliation
To \t or not to \t? — thegoldenmule
I’m not going to argue about which workflow is best: OneFlow, GitFlow, GitHub Flow, Forking Workflow, GitLab Flow, etc. Line endings, tabs v spaces, trailing commas — I may be seen dying on several hills but you will not find my bloodied corpse on the summit that is git workflows. The fact is, the power of git is found in its ability to support many workflows, extremely quickly, with extraordinary consistency, in a decentralized way.
Here’s the real meaty center of this post: git has transformed collaborative software development but the core ideas have a chance to transform so many other endeavors.
Examples
Consider a word processor, like Google Docs. You can create a document and multiple people can edit the document at once. Google Docs is amazing, but only if you’ve never used any programming tools. Google Docs is slow and it’s unsafe. There is no quick method to start off on a new idea, a wild tangent, with the complete assurance that you can go back to an earlier state of the document. You can’t store side by side ideas and come back to them later — you can’t even look at ideas side by side. There is an awful linear history that is difficult to access, provides no good mechanisms for viewing differences, and doesn’t allow you to decide what constitutes a “revision”. There is no way to reconcile differences between drafts. There are only workarounds: creating copies, copy/pasting crap into other documents, making your own backups by hand. There is no way to work offline. There is no option but to trust Google with your data. What a terrible, horrible, no good, very bad workflow.
Imagine what an impact decent tools could have for a writer.
I am related to two pastors. They each write a speech once a week. I am told that twenty-one minutes is the perfect length of a sermon, but sometimes there’s too much to say and they turn into twenty-seven minute sermons. Past the thirty minute mark, we call them “gravy-burners” — as the Sunday gravy left to simmer on the stove has now turned to charcoal. The best tool they have at their disposal for this amount of writing is the smoking, decomposing pile of refuse we call the modern word processor. They have no way to quickly experiment. No way to review progress, compare their own ideas, or ask for feedback from their peers.
Consider Pro Tools.
This tool allows musicians to record tracks, arrange music, make the fattiest of beats, and the illest of rhymes. Realtime audio plugins are a modern marvel. But what’s this? — The only thing between the musician and utter destruction is an undo stack, a complete mastery of Save As, and decent knowledge of external backups. What happens when a musician wants to collaborate? Many musicians stick their projects in Dropbox, which is in itself a terrible, awful service that could use some distributed-version-control love. How do you try something quickly, or head a different direction easily, or foster collaboration without hitting the friction of your tooling not supporting the differences in your ideas? Git doesn’t directly solve these problems (though I have a strong suspicion that it could) — remember, git isn’t the point here, the ideas behind git are. What does an audio diff look like? How do you resolve conflicts between the aforementioned fatty beats?
The idea of safe, distributed branching, comparing, and reconciling could have an incredible impact here.
Finally, consider the digital artist, working in 3d sculpting tools or Photoshop. Game artists may know about “version control” but the vast majority don’t use it. Even among the VCS-aware, there are no tools for diffing and resolving PSDs. What would those tools even look like? Why has Adobe not spent any time on letting artists easily try TWO things out at once, safely? Or collaborate on and reconcile different ideas?
I’ve run out of examples
I have not run out of examples — whoever wrote that pesky paragraph header is lying. Ever done a thing and then wanted to try a new thing without compromising your ability to go back to that first thing? Ever wanted multiple people to work on different pieces of a thing and then safely reconcile their thing work? HAVE YOU EVER WORKED ON A NON-TRIVIAL THING???
If you answered yes to any of these questions, then git’s core ideas could help what you’re doing. We should be thinking about how to let git’s model of thinking pervade other things we do.
