Formal education in programming is surprisingly useless. Some people with a formal education in 'Computer Science' (and let's be honest, it's more of an art than a science) can tell you about set theory, but can't pick an appropriate database for a project. They can tell you when to represent a number with hex, but can't clone a repo. And worst of all, most people I've spoken with did not enjoy learning about computers.

So here's my much-improved course, based on every joy I've found while learning how to computer.

How the Learning Works

Knowing Why is Half the Battle

People always feel irritated with new software, but when the process seems pointless, it's so much worse. Occasionally someone asks to use my computer for something, and I have to say the standard things:

You can't type because you're not in insert mode. Press i to type words.

There's no start button. Do you want Firefox? Open Firefox with 'Windows plus D'.

Upon hearing this, people's faces scrunch up in disgust, because it looks like the system is being difficult on purpose, with pointless extra steps.

But if you know ed, then you know why half the coreutils work the way they do.

No Phones

People don't read books at a carnival, and nobody learned Unix while they had an unending stream of Netflix, political hot-takes, and celebrity drama to catch up on. They learnt how to Unix at a time when Monty Python was the funniest thing in existence, and being able to telnet a stream of Star Wars animations was simply amazing.

We can't go back in time, but we can replicate the important parts.

Experience Has No Speed Limit

Ask a bunch of people who have been coding for 30+ years, and you will find a whole boat-load of shared problems, and agreed solutions. One well-known problem is the new person, straight from a university, with a very official qualification, saying they know how to computer. Shortly after, they will:

• Install VSCodium with a dozen add-ons,
• send broken code to the server without testing,
• complain about having to learn git,
• make a git commit with 3,000 changes which just says update files,
• then reinvent half of the coreutils using python.

But none of these mistakes need thirty years of experience to overcome.

Everyone with good backup habits has lost precious work and photographs which they failed to back up. But disks survive for 5 years on average, so it takes 5 or 10 years to learn good backup habits; and this is not just about motivation, it's about the details. People who rote-learn the concept of 'backup' may try to backup the entire OS, including /usr/ and /opt/, because they have very little practice in restoring from a backup.

And everyone who makes good CI pipelines has gone through the various steps manually, got bored, and begun to automate the process. But anyone who just sets up a Gitlab pipeline because 'it's the done thing', will copy-paste the suggested stages instead of setting up the right stages for the project.

Twenty years of experience might push you to restore from a backup four times and build a new pipeline twice, but you can do both of these things in a couple of hours, so a course can teach them within a few days. The real learning experiences come rarely, but they don't have to.

The Joys of Solving Problems

Teaching someone git on a computer course is like handing out painkillers to healthy people.

If you study git to pass a course, then you may as well try to memorize a phone-book.¹ The experience will be nothing but pain and confusion, because git will be nothing but a pointless software-thing that you have to do. You will miss the point; you must miss the point, because you never saw the point. The point of git is to solve a problem, which you've never had.

The process of learning can become so much easier, even joyful, if it just moves in the right direction:

1. Here is a script which does the whole task for you (good to know I don't have to do that horrible thing any more)
2. To fix the bug, change the file at line 8, and add this after line 10 (good to have that fixed!)
3. Line 8 must be changed (wait, this is the same change as last time)
4. You need must add this after line 12 (but does this take into account the newline from earlier? Should it be line 12?)

If each change is helpful, people will be happy to get the help...until they do this enough to find new problems. Once you have three people sending you their improvements to a script, then the diff command will suddenly feel like magic.²

1. Use diff to show the changes (now that's much easier)
2. Use 'diff file_1 file_2 > file.patch' to record the changes (now I can just send a .patch file instead of typing out all the changes!)
3. Here is a patch file to stop the computer trying to convert the date to inches (good stuff!)
4. Here are five patch files (Great! No - hang on, which order do they go in?)

Emailing instructions to someone lets them make 10 changes to a file, but for 100 changes, you'll need better tools, like diff and patch.

It feels good to make 100 changes easily, because that was once a lot of work. But once you need to make 1,000 changes, it becomes work again, and you need a new tool: git. And once again, everything feels groovy.

Instead of looking down at 50 years of computer history and thinking 'oh fuck, I need to learn all that?', people can look at 50 pages of dull numbers and think 'oh fuck, I need to calculate the compound interest on all of that?'. This is the 'always upward' momentum that makes computers a joy, and makes the tools make sense.

Make Too

make provides another perfect example of the joyful upward trajectory, and painful fall. And everyone should learn how makefiles work like I did:

1. Don't use a makefile, just make everything yourself by typing in the commands.
2. Get bored, and write a shell script, which runs every command, every time, whether or not it's required.
3. Try to speed up the broken bash script with a hundred janky checks.
4. Finally, learn how makefiles work.
5. Delete the old makefiles, and write them properly.
6. Delete those makefiles too, because recursion isn't clever, it means you don't know what you're doing.

The Syllabus

Each learner has a physical computer, with a text interface, i.e. terminal. The terminal connects to the computer.³

The computer (which every student connects to) is set to the year 1970, and the tools are old. It's set to the year 1970 to explain why the tools are the way they are. Most of the details don't need to be precise: people can use awk or gawk or whatever; what really matters is this:

• Low CPU power (1 core, 1 thread!).
• Low memory.
• Tiny disk-space.
• A small keyboard with no arrow keys.
• dash shell only.

The speed of the old terminals might be approximated with a little shell-statement upon login:

1mkfifo /tmp/bashpipe
2( cat $ff | perl -We 'use Time::HiRes;$|++;while(read(STDIN,$c,1)){Time::HiRes::usleep(15000);print $c;}' ) & exec &> /tmp/bashpipe

No other computer should be usable (including phones).

Day 1: 1970

A stack of paper notes explain how to use the interface, including:

• wall
• mail
• dir (not ls)
• ed (yes, I'm serious)

The system will not have ncurses.

Each computer has around 6 students on it, who can communicate with wall or mail by following the paper instructions.

The Point

• Familiarity with a text interface (it's all text at the end of the day).
• Get used to reading instructions.
• ed sets the standards for so much to come after, so it'll be easier to see why awk and vi use the syntax they do.

Day 2: 1971

Each student receives a printed stack of papers with housing prices (or anything with numbers), and has to calculate a few percentages of this and that, producing a tsv spreadsheet. The work is unrealistically massive - each sum would take a long time to do by hand, and even a long time with a calculator.

Half-way through the day, another email arrives explaining that the department has a new computer, and that the accounts will be transferred. The computer then 'reboots' (any work-in-progress will be lost) and once the students log in again, the new one is slightly faster.

The Point

• Teamwork is necessary to get the job done.
• Getting used to explaining a task using only text.

Day 3: 1972

Students no longer automatically log into the big computer; they log into their own computer, which is even slower than the first one. However, they can log into their old account over telnet, using the big computer's ip address. The new computer lets them run as root.

The students receive email instructions on forwarding their 'e-mail' from the shared computer, to their own computer. None of this has any security (just like in the 70's). And none of it works, because the new computers don't have the $PATH variable set.

Paper instructions inform them how to set the $PATH variable.

Half way through the day (after more work with the still-not-done pile of things to process), one student gets an e-mail with the source-code for some program which helps when calculating one part of the spreadsheet data.

By the end of the day, another email arrives with more information to append to the printed material - the students will probably have even more work than when they began.

The Point

• The $PATH variable isn't about the variable, it's about understanding that everything is a file.
• Learn the basics of documentation (as all students will need the program).

And So on...

The work should pile up quickly, until the students learn to automate it, and work together. The years roll on quickly, with problems which replicate original computer problems:

• IP addresses will change,
  • so students learn the /etc/hosts file.
• More computers and more IP addresses mean /etc/hosts will not keep up,
  • the students will have to recreate something like DNS.
• Every few days, a hard drive randomly breaks, destroying all work.
  • Backups will become essential.
• All the programs the students receive by email have bugs,
  • prompting more compile-jobs which should be automated.

The emphasis on team-work here is not just about learning to work with people, it's about getting people to think in terms of parallel processing.

The 80's

bash

The bourne-again shell rises, and the main system will slowly populate with bash-completion scripts.

Firing and Hiring

Students will be randomly fired, and then re-hired with other 'companies' (which have different tasks). This will create chaos and confusion, as each team will have its own methods and standards, and nobody will have written any of it down, so every new student will feel lost, and have to ask a lot of questions about basic tasks.

ncurses

After having to use more, less will feel like a breath of fresh air.

After having to use ed, vi will feel like angels descending with hot soup.

New Spreadsheet Format

The spreadsheet (and all information, going right back to 1970) must be converted from .tsv to .csv. Students will encounter problems with commas in names of items, fix them with double-quotes, then find more problems with double-quotes.

Bad Actors

One student is randomly given the task of taking a company's information, or just destroying as much work as possible. Much like a game of mafia, the students won't be able to trust each other. They will have to check, and double-check patches, in case someone sends nasty code over.

I need to emphasise here that nobody who learns about computer security will ever say or do anything useful if they have not also attempted to disrupt a system. They can make 'IT-noises' as well as any machine-learning bot, but once you really work with them, the conversation becomes weird, producing a nauseating feeling, because their words don't actually mean anything. They point out 'the IP address has been exposed!', without any ability to tell if this might cause problems; they will ask if a database has been 'patched', instead of asking if the program which runs the database has been patched, because they don't know what those words mean - they're just making 'IT-noises'.

Patches

People speak about patches without knowing the patch command, but there's really no reason for it - the diff and patch commands are easy to learn once you have a reason to use them. And more importantly, it gets people used to thinking of software in terms of incremental updates.

Relational Data

The client (who wanted all that information) has learned how to use e-mail, and they have questions:

Do Capricorns tend to spend more? Can you check by looking at customers birthdays and what they bought?

What age is the average customer in Paris?

Dealing with the Client's Clients

Derry is actually called 'Londonderry'. Can you change the name for everyone living there?

Our client doesn't like the name 'Londonderry'. Can you change the address back?

Another client has complained about the name 'Derry'. Can you change just that one back?

Does the size of the city affect how much people spend? We make a list of how big the cities are (tsv file attached), so you can check against it.

Your last e-mail has mistakes, clients from Londonderry were not accounted for, since their address says 'Derry'. Can you make another field to store their address, and their preferred address?

The 90's

Websites

Barriers between groups break down, and all the students in all teams can finally share information over websites.

Databases

Let's just save everyone a headache, and go right to sqlite3.

git

Finally!

The 00's

Proprietary Software

Adverts for proprietary software arrive in your inbox. They work great at first, then slowly break compatibility with everything, and start charging money.

Management

A new category is created: the manager. The fake companies select random students to become 'the manager'. Their job will be to keep track of the other team members, decide on merge requests, and create graphs which visualize data so upper management feel like they understand what's happening.

New websites appear which describe 'top ten performance indicators' for coders, all of them nonsense. The fake companies begin to hire and fire people at random.

This gives everyone the opportunity to lead a team, and the experience of trying to work around shit management.