What software actually is

Yesterday we made a promise about no jargon and a 21-day shape. Today we honor it by tearing down the most over-loaded word in your inbox, software.

Our neighbor is a scientist. Smart, accomplished, deeply curious. A few months ago he told us he wanted to do something concrete with AI, taking a particular kind of public research data, running a daily analysis on it, and publishing the results on a small website of his own. Not a startup, just a research project with a public face.

He had Claude. He had time. He had domain expertise the rest of the internet doesn't.

He gave up after about a week.

Not because Claude couldn't help him, because Claude could help him patiently every time he came back. He gave up because every time Claude asked him a reasonable-sounding question like do you want this hosted as a serverless function or on a VM?, he hit a wall of vocabulary he'd never been taught.

The AI wasn't the problem, the foundation underneath the AI was. That story is the founding essay of this course, and the reason we're starting Day 2 with it is that you cannot fix the foundation problem without first agreeing on what software actually is. So here goes.

Software is three things and only three things

A piece of software is:

1. A set of instructions,
2. that runs somewhere, and
3. that takes an input and produces an output.

That is it. Every other thing you will learn in this course is a question about one of those three parts: what are the instructions, where do they run, and what is the input or output.

Let's pressure-test the three-part definition with examples your phone is full of.

Calculator. Instructions: a small set of arithmetic rules. Runs on: your phone. Input: the buttons you tap. Output: a number on the screen.

Email. Instructions: a much larger set, but conceptually similar. Runs on: partly your phone, mostly Google's or Apple's or Microsoft's computers. Input: the message you write, plus the messages other people send to you. Output: a screen full of messages, plus other screens (recipients') with your messages appearing on them.

ChatGPT. Instructions: an enormous, mostly statistical set of rules trained on a huge amount of text. Runs on: a row of expensive computers owned by OpenAI, not your phone. Input: what you type. Output: text on your screen.

Notice that the what does it do part can be tiny (calculator) or staggering (ChatGPT), and the answer doesn't actually change the fact that it is instructions, running somewhere, in-out. The complexity is a matter of scale, the shape is identical.

Why this is the most useful sentence you will learn

When you say "I want to build a thing," what you are saying is "I want to design a set of instructions, decide where they run, and define what comes in and what goes out." That is the whole job.

Most of the panic people feel when they try to build anything is panic about one of those three parts in isolation. They know roughly what the instructions should do, which is the easy part. They have no idea where it should run (Day 3, Day 12). They are vague about what the input and output actually are (Day 4, Day 8, Day 11).

When you can name which of the three you are stuck on, you have already done most of the work of getting unstuck.

A small exercise that pays for the next twenty days

Pick a piece of software you used in the last hour. Email, Slack, Spotify, the camera app, Google Maps, anything. Try to name its three parts in one sentence each.

For Google Maps it sounds like this:

• Instructions: figure out where you are, where you want to go, and the fastest route between them.
• Runs on: a little bit on your phone, most of it on Google's computers.
• In, out: you type a destination, you get back a route and a map.

That is not a sophisticated answer, it is the right answer. Sophisticated is on Day 4.

Do this for three pieces of software you use, before you read Day 3. Especially do it for the boring ones (a podcast app, a notes app), because the boring ones reveal that the framework holds for everything.

Two things this is not

It is worth saying what this lesson isn't, because the no-jargon contract makes us responsible for that too.

This is not a technical definition of software in the computer-science sense. Computer scientists have many more careful things to say, and they are not wrong, we just don't need them yet. Most of their precision is irrelevant to the question you are actually trying to answer, which is "where do I begin?"

This is also not a productivity hack. We are not telling you to think of software in three parts so you can ship twice as fast this week. We are doing it because the next twenty lessons each pick at one of those three parts, and unless we share a vocabulary about what software is, we'll spend half of every lesson re-arguing it.

Forward references

In Day 3 we take the second part of the definition (runs somewhere) and crack it open into the single most under-taught distinction in tech. In Day 4 we follow an input through a piece of software, end to end, and watch it become an output. By Day 7 you'll be able to draw the whole journey on a napkin.

Day 2 wrap

The thing you can now say plainly. Software is a set of instructions, running somewhere, that turns an input into an output. Everything else is a question about one of those three parts.

The thing you can now do. Take one piece of software you use every day, and name its instructions, its runs-somewhere, and its input or output in one sentence each.

The guardrail to remember. Don't reach for a more sophisticated definition than this one until you actually need it, because most of the things that go wrong in beginner builds go wrong when someone is in the weeds of one of the three parts without being clear about which one.

See you in the cloud.