Imagine a data processing system that takes advantage of local computing resources to provide a rich user experience and robust data validation while offloading a central computing system. It presents complex forms composed of smart fields that prevent entry of invalid data. Much of the validation is done locally, based on attributes applied to the fields to provide prompt feedback. However, when necessary, input can be validated against lists of values retrieved from the central system. When the form is complete, the user submits the data to the central system as a package that gets processed all at once before returning a success indicator or a failure indicator with a possible list of error messages to guide revising the data for resubmission.

Some readers will think it obvious that the data processing system is the World Wide Web. HTML forms — especially when souped up with modern web frameworks — support complex data validation and submit fields to a web server to update centrally stored data. If you’ve ever bought anything from an eCommerce site, you’ve used this technology.

However, as I was writing the first paragraph, I was not thinking of PCs running web browsers and data centers full of web servers, I was describing mainframes and their terminals. Undoubtedly, the web browser provides a more rich and responsive user experience than a 3270 terminal (which, among other things, lacked graphics), but diagrams of communication between parts of the old and new systems are identical in all but details.

I can’t say if the designers of HTML modeled their form system on mainframe data entry but it kind of looks like it. If they didn’t, they might have made their job easier had they done so. The suggestion that a programmer should not reinvent the wheel is often interpreted as applying to recreating other contemporary technology with similar features. However, it also means being aware of the history of computer science and technology in sufficient detail that you can learn from historical systems to make your job easier and your system stronger.

I once worked with a great programmer who had a sign on his wall that said:

The Three Qualities of a Great Programmer: Laziness, Impatience, and Hubris

All of those sound like negative attributes but considered in the right light, they are very insightful. I’ve thought of them often in the years since I read them on his wall.

Laziness

A great programmer is too lazy to perform simple, repetitive tasks and would rather spend two hours writing a script to do a task than 10 minutes doing the same task. (This always reminded me of a short story I once read about a young student too lazy to do their homework so they invented a machine to do it for them.)

Of course, if the task is only done once, automating it is not very practical. But if it’s preparing a weekly report or something, the scripting time is very well spent and pays for itself fairly quickly. And that ignores the fact that someone else can now run that script, can read it to learn about the process, etc.

Impatience

A great programmer is too impatient to wait for a slow-running program to finish, especially if that program does a repetitive task (see above) the programmer wants it to be fast so they can review the output and get on with other work.

Human interaction with a computer is incredibly sensitive to delay in response. If you’ve ever worked with a laggy mouse with a low battery, you know how it feels to have your actions take too long to take effect. Similarly, if you’re running a spreadsheet macro or small program it has to respond in well under a second or you lose flow and get frustrated. If the code originally took 1.5 seconds to run, making it run in 8/10 of a second may not seem a big improvement but it is the difference between a smooth work flow and a frustrating one, the difference between a tool you’ll come back to and come to rely on, and one you’ll set aside and not use.

Hubris

Maybe a great programmer isn’t hubristic. Maybe this is the humorous entry in the list. On the other hand, good software can save bad hardware. And it can do it after you ship. I’ve heard it said, “you can do anything in software” and I almost believe it.

A great programmer is likely to see a challenge and say, “I can do that!” Hubris? Confidence? Optimism? Maybe some of all of those. A meek programmer may look at the same problem, think it impossible, and not dive in. Without a certain measure of hubris, some of our greatest software systems might not exist. Their creators saw a challenge and believed they were up to it, and we all benefit from that.

A long time ago I implemented a program that learned to play Tic Tac Toe. I was a new programmer and not particularly skilled but I’d read an article about how someone had taught a matchbox to play and I thought I was at least that good. The article I’d read was in Scientific American but you can read about MENACE today on Wikipedia. The original work was “AI” in 1961! My program started out only “knowing” the allowable moves and as we played it “learned” strategy. After a dozen or so games, I couldn’t beat it. Even though I wrote it, I marveled at this program’s behavior.

Arthur C. Clarke famously said, “Any sufficiently advanced technology is indistinguishable from magic.” There are 512 possible final boards of Tic Tac Toe and more than 250,000 games (paths from an empty board to one of those 512 finishes). This is on the border of the ability of a human to inspect and understand. The fact that I didn’t really know how my program kept me from winning Tic Tac Toe didn’t make it magic, it was just sufficiently complex that I couldn’t intuit its inner workings. (I was a novice programmer then but decades years later I still find wonder in this program.)

Like those matchboxes and my novice program, a lot of things these days are called “artificial intelligence” but how intelligent are they? I’d argue, “not very.”

Neural Networks

Many AI systems — including my program — are trained to achieve their goal. The system starts with some constraints and rules then by exposing it to data (games of Tic Tac Toe, for instance), you train it or it learns how to behave in a way that seems intelligent.

One type of system that can be trained to seem intelligent is a neural network, based at least loosely on a limited understanding of how the brain works. With a neural network (NN), you repeatedly apply inputs and desired or expected output, and the network magically sets itself up to produce that output when the same or similar inputs are presented. (Please take a hint from the use of “magically” to realize that I’m being vague and general. I’m sure I’ve got details wrong.)

A common demonstration of neural networks is classification of data like images or audio clips. After training, you might use a NN to try to tell if a sound came from a flute or a saxophone, or what kind of animal was in a picture. Say you had several (or several hundred) images of cats and dogs. You might try to train a neural network to discriminate between them.

The test is trying the NN on a novel input.

What Went Wrong?

Somehow, the NN might have noticed that the cats all have a horizontal stroke at the bottom center but the dogs are all hollow. That fits the training data and leads to the same wrong conclusion with the test data.

Whatever the method, the NN focused on the wrong feature of the input and drew the wrong conclusion. When shown an image of a standing animal, it labeled it a dog. This is a classic example of GIGO: garbage in, garbage out.

Considering this small training set, we could try to fix the problem by adding standing cats and sitting dogs to the training images. Then the NN might focus on pointy tails or some other irrelevant feature and still reach the wrong conclusion. (Challenge: can you explain the difference between a cat and a dog well enough for another person following your directions to properly conclude the last image is a cat?)

Humans are great at pattern recognition and extrapolation, at least to the limits of our capacity. We can look at the data we trained the NN with and see things that might be wrong. But if you trained the NN on thousands of drawings (or thousands of photos!), it would be nearly impossible for a human to review the training data, determine the problem, and fix it. The larger the data set, the harder it is to tell what is wrong or to correct the problem.

Generative “AI”

If you play Scrabble or Wordle, you are likely familiar with the fact that “e” is the most common letter in English text. Different analyses show “t” or “a” second. As you might expect, “q” and “z” are fairly uncommon. What if you looked for the frequency of two-letter combinations? You might think “th” would be fairly common (indeed, it’s the most common) and something like “qz” fairly uncommon or absent. Things get interesting with three-character combinations; It turns out they embody a lot of the word-forming rules of the language. If you “randomly” generate text that adheres roughly to the same frequency of trigrams as the original language, you get something that is readable nonsense. Readable, because all the letter combinations look familiar to us and we can sound them out. Nonsense because there are very few actual words in the text.

What if, instead of the frequency of one letter following another, we considered the frequency of one word following another. If we had a large volume of text to train the system with, we could generate novel text from that training set.

If you used all of Shakespeare’s plays as a training set and asked the system to generate some text, it could. The output might be fairly readable (though it likely wouldn’t have much of a plot). But it would be in Shakespeare’s English, not modern, with nary an acronym or neologism in sight. And it would be more like a play than the sonnets Shakespeare is also famous for.

While Shakespeare was prolific, his collected work is still a small part of a small library. And it is microscopic compared to all the text on the Internet: digitized books but also software user manuals, scientific papers in online journals, social media posts, and on and on. That huge volume of text is what is used to train large language models (LLMs). Once the LLM is trained with a large fraction of the Internet, you can ask it to generate novel content. This content will sometimes be gibberish but a really good system will produce text that seems quite coherent.

If a LLM’s training material includes racist rants on social media, there’s a chance it will generate text that reflects that bigotry. Does the LLM have a conscious bias against certain people? No, it’s not even conscious. But it can look that way. And it’s not a good look. Remember GIGO. The system reflects the strengths and weaknesses and biases of the input. Do cats always lie down? Are plays always in Shakespeare’s voice?

A lot has happened since 1961 and many years since have been labeled the “year of AI.” Recent developments have lead to AI techniques yielding more useful applications. Maybe that year has finally come. With AI as with many things, we should be mindful of creators’ intent and the systems’ affects but let’s not cloak such applications in mystery.

I don’t mean to suggest that Git is a CRM tool, but rather that Git has features that you can employ to manage code for multiple clients in ways that make them happier and you more efficient.

At various times in my career, I’ve worked on code that was mostly shared across projects for several different audiences. As an independent consultant, I had utility code that I employed solving problems for various clients. As a developer at a maker of OEM systems, I lightly customized common feature code for numerous customers. And when building plugins for large systems, a lot of glue and foundation code can be shared between different implementations.

The legal agreements around such work often require that the client have access to the source but, in my experience, that access is rarely exclusive. If you can make common code common and still share all the code used by a client with that client, you are more efficient because you don’t have to reinvent the wheel every time and they receive more robust solutions that build on code shared with other implementations. It’s not quite the “many eyes make all bugs shallow” ideal of open source, but it has some of the same advantages. The key to this reuse is disciplined branch management. In the rest of this post, I’ll show you how.

Consider a project being done for Acme Widgets, developed with an eye toward portability and modularity. Details of software modules and implementation language really don’t matter, so I’ll simplify the discussion by illustrating with changes in a single text file.

Document Title

This document describes some software.

It has features.

It is customizable.

We get started by creating a repo for shared source and putting this text in a file, doc.txt.

$ mkdir shared
$ cd shared/
$ git init
Initialized empty Git repository in C:/Code/blog/shared/.git/
$ touch .gitignore
$ git add .gitignore
$ git commit -m "Shared: Initial commit"
[master (root-commit) 33dd3c5] Shared: Initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
$ emacs doc.txt
$ git add doc.txt
$ git commit -m "Shared: First version of document"
[master 85d0374] Shared: First version of document
 1 file changed, 7 insertions(+)
 create mode 100644 doc.txt

Let’s add some common features:

Document Title

This document describes some software.

It has features.

* Feature 1
* Faeture 2

It is customizable.

This common “code” is still on the master branch

$ git diff
diff --git a/doc.txt b/doc.txt
index f1cfe19..2c3bf02 100644
--- a/doc.txt
+++ b/doc.txt
@@ -4,4 +4,7 @@ This document describes some software.

 It has features.

+* Feature 1
+* Faeture 2
+
 It is customizable.

$ git add doc.txt
$ git commit -m "Shared: Add features 1 and 2"
[master 975c1d3] Shared: Add features 1 and 2
 1 file changed, 3 insertions(+)

Now that there is a base to build on, let’s start working on client-specific work. First, we create a repository for the client’s view of the project.

$ cd ..
$ mkdir acme
$ cd acme
$ git init
Initialized empty Git repository in C:/Code/blog/acme/.git/

Then, we make that client repository a remote for our shared repository.

$ cd ../shared
$ git remote add Acme file:///c/code/blog/acme
$ git remote
Acme

And make a client-specific branch in the shared repository.

$ git checkout -b acme
Switched to a new branch 'acme'

And add client notes to the document.

Document Title

This document describes some software.

It has features.

* Feature 1
* Faeture 2

It is customizable.

Acme-specific features include:

* Feature A
* Feature B

And check them in on the client-specific branch.

$ git diff
diff --git a/doc.txt b/doc.txt
index 1dda3c5..737c272 100644
--- a/doc.txt
+++ b/doc.txt
@@ -8,3 +8,8 @@ It has features.
* Faeture 2
It is customizable.
+
+Acme-specific features include:
+
+* Feature A
+* Feature B
$ git add doc.txt
$ git commit -m "Acme: Add features A and B"
[acme 89547d7] Acme: Add features A and B
 1 file changed, 5 insertions(+)

In discussion with Acme, you find that their Feature C really has general utility, so you choose to add it as Feature 3 to the common code. To do this we work on the master branch then merge that common change onto the client branch.

[master 53f5a0c] Shared: Add feature 3
$ git checkout master
Switched to branch 'master'
$ emacs doc.txt
$ git diff
diff --git a/doc.txt b/doc.txt
index 2c3bf02..5daa37c 100644
--- a/doc.txt
+++ b/doc.txt
@@ -6,5 +6,6 @@ It has features.

 * Feature 1
 * Faeture 2
+* Feature 3

 It is customizable.
$ git add doc.txt
$ git commit -m "Shared: Add feature 3"
[master 53f5a0c] Shared: Add feature 3
 1 file changed, 1 insertion(+)

$ git checkout acme
Switched to branch 'acme'
$ git merge master
Auto-merging doc.txt
Merge made by the 'recursive' strategy.
 doc.txt | 1 +
 1 file changed, 1 insertion(+)

All this work is local and has a global view of common and client-specific features. When it is time to share the development with the client, you push just the client-specific branch to the client-specific repository.

$ git push Acme acme:upstream
Counting objects: 18, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 1.60 KiB | 0 bytes/s, done.
Total 18 (delta 5), reused 0 (delta 0)
To file:///c/code/blog/acme
 * [new branch] acme -> upstream

Your work for Acme is done and you are lucky enough to land a new contract with Evil Corp. You negotiate with them to implement Feature 4 (something sufficiently generic that other clients might use it) and Feature Alpha just for them. Evil Corp benefits from your work for Acme and you begin by checking out the master branch and implementing Feature 4.

$ git checkout master
Switched to branch 'master'
$ emacs doc.txt
$ git diff
diff --git a/doc.txt b/doc.txt
index 5daa37c..2f6a3a6 100644
--- a/doc.txt
+++ b/doc.txt
@@ -7,5 +7,6 @@ It has features.
 * Feature 1
 * Faeture 2
 * Feature 3
+* Feature 4

 It is customizable.
$ git add doc.txt
$ git commit -m "Shared: Add feature 4"
[master c5ee2e8] Shared: Add feature 4
 1 file changed, 1 insertion(+)

Then create a client-specific branch for Evil Corp and add their feature.

$ git checkout -b evil
Switched to a new branch 'evil'
$ emacs doc.txt
$ git diff
diff --git a/doc.txt b/doc.txt
index 2f6a3a6..53108fc 100644
--- a/doc.txt
+++ b/doc.txt
@@ -10,3 +10,7 @@ It has features.
 * Feature 4

 It is customizable.
+
+Evil Corp features include:
+
+* Feature Alpha
$ git add doc.txt
$ git commit -m "Evil: Add feature alpha"
[evil 65eab70] Evil: Add feature alpha
 1 file changed, 4 insertions(+)

In testing the release for Evil Corp, you find and fix a problem with Feature 2.

$ git checkout master
Switched to branch 'master'
$ emacs doc.txt
$ git diff
diff --git a/doc.txt b/doc.txt
index 610f380..2f6a3a6 100644
--- a/doc.txt
+++ b/doc.txt
@@ -5,7 +5,7 @@ This document describes some soft
 It has features.

 * Feature 1
-* Faeture 2
+* Feature 2
 * Feature 3
 * Feature 4

$ git add doc.txt
$ git commit -m "Shared: Fix a bug in feature 2"
[master 4488af0] Shared: Fix a bug in feature 2
 1 file changed, 1 insertion(+), 1 deletion(-)

And merge that fix into the Evil branch.

$ git checkout evil
Switched to branch 'evil'
$ git merge master
Auto-merging doc.txt
Merge made by the 'recursive' strategy.
 doc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Finally, you deliver the code to Evil Corp.

$ cd ..
$ mkdir evil
$ cd evil/
$ git init
Initialized empty Git repository in C:/Code/blog/evil/.git/
$ cd ../shared/
$ git remote add Evil file:///c/code/blog/evil
$ git push Evil evil:upstream
Counting objects: 24, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (24/24), 2.17 KiB | 0 bytes/s, done.
Total 24 (delta 7), reused 0 (delta 0)
To file:///c/code/blog/evil
 * [new branch]      evil -> upstream

At this point, Acme notices the bug in Feature 2 and asks you for a fix. Lucky you, you already fixed it. If Acme is willing to accept Feature 4, you can just merge your master to acme.

$ git checkout acme
Switched to branch 'acme'
$ git merge master
Auto-merging doc.txt
Merge made by the 'recursive' strategy.
 doc.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

If they are not, you can cherry-pick the fix for Feature 2 from master to acme. In either event, you then push your update to them.

$ git push Acme acme:upstream
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 907 bytes | 0 bytes/s, done.
Total 9 (delta 3), reused 0 (delta 0)
To file:///c/code/blog/acme
   20a8851..eb3f53a  acme -> upstream

At this point, you can see your work for both clients.

Overview of all code

But your clients can only see the common code and their client-specific code.

Acme’s view of their code

Evil Corp’s view of their code

Furthermore, your clients can update their code (or the common code) and share it with you on their upstream branch. You can fetch that branch and cherry-pick fixes from it to your master branch to share with other clients as appropriate.