What programming actually is

What is a program? The simplest definition that is not wrong

A program is a list of instructions a machine carries out in order. The difference from a recipe you hand a person is right there: a person fills the gaps and understands what a pinch of salt means. A machine neither understands nor asks.

Anything you did not say does not happen, and anything you said wrongly happens exactly as wrongly as you said it. It is a simple sentence and the whole difficulty of this craft sits inside it. Most of the errors you will meet do not come from not knowing the language; they come from the sentence in your head being slightly different from the sentence you wrote.

Separate three words from the start. Code is the text of the instructions, the thing you type and save to disk. A programming language is the set of rules that text has to follow so it can be translated. And a program is what happens when that text is translated and run. The text stays; the program comes alive in memory, does its job and ends.

So being a programmer means holding this one ability: writing what you want precisely enough and unambiguously enough that a machine with no understanding can carry it out. The language and the tools come afterwards.

A real program, in five lines

These five lines of Python do real work: they walk a folder full of images and print the names of the files bigger than a given size. The job comes up on every site, because heavy images are the slowest part of most pages.

from pathlib import Path

for f in Path("images").rglob("*.jpg"):
    size = f.stat().st_size
    if size > 200_000:
        print(f.name, round(size / 1024), "KB")

Read it line by line. The first line brings in the tool for working with folders. The second says: inside the folder called images and all of its subfolders, take every file ending in jpg, one at a time. The third gets the size of the file in bytes and keeps it somewhere called size. The fourth sets a condition: only if that number is greater than two hundred thousand. The last line prints the file name with its size.

Three things in those five lines show up in every other language too: a loop that repeats work over each member of a set, a condition that decides, and a variable that holds something temporarily. Understand those three in one language and the next language is mostly a change of appearance rather than a new idea.

And one thing this program does not have: nowhere does it ask whether the images folder exists at all. If it does not, nothing happens and no error is printed either, because the loop runs over an empty set and finishes. A program that does not work yet does not complain is the most confusing state for a beginner, and it is what the section from our own work at the bottom of this page is about.

From problem to working code, in five steps

The first step is the problem, and it gets the shortest write-up: what exactly has to be solved, what goes in and what the output looks like. My site is slow is not a problem statement; I want the list of images above two hundred kilobytes is.

The second step is the algorithm, and it is the one almost everyone skips. An algorithm here means writing the steps in your own words before a single line of code: open the folder, take the files one at a time, look at each size, and if it is over a certain amount write down the name. If you cannot explain a task step by step in plain language, your problem is not Python.

The third step is the code: those same steps, this time under the rules of a language. The fourth is running it, and it is the first moment you truly learn what you said. The fifth is fixing it.

The fifth step does not finish, it repeats, and for every programmer it takes the most time. The common picture is that a professional writes the code correctly and it is done; what actually happens is that a professional works out faster where it went wrong. One small rule makes that loop several times quicker: change one thing at a time. Change three things together and get it working, and you do not know which one it was, so next time you start from nothing again.

Why most of a programmer's time is not spent writing code

What shows from the outside is typing. Below the waterline sit four other jobs that no course makes a video about.

First, reading code that is already written. Code gets read far more than it gets written, whether it is yours or someone else's. Second, reproducing the error: until you can make a bug happen again on purpose, every change you make is a guess, and the thing that appears to fix it may have nothing to do with what you did.

Third, naming things and making decisions. Variable names and the way work is split between functions are not decoration; a bad name turns into a real bug three months later, because you yourself forget what you meant. Fourth, waiting: installing, running, testing, a server coming back up. Time no curriculum counts and every real working day contains.

None of this is said to discourage you. The opposite: if you know the real work looks like this, then the first time you spend an hour stuck on one error you will not conclude you lack the talent. That hour is the work.

What exactly do you need in order to start?

An ordinary computer, a free text editor, a language, and a terminal. That is all. None of those four costs money and none needs expensive hardware; the program you saw in this lesson runs on the weakest laptop you own.

The terminal is that black window beginners are afraid of, and it is really just the place where you give the computer an instruction without hunting for a button. Learning it takes half an hour, and after that half your work happens there.

Our position, which does not sit well with how most courses are advertised: do not buy a course until you have written ten lines of code. Pick a small real task from your own life first, such as tidying up file names or counting something in a text file, and build that with the documentation and a few searches. If you still feel you need a structured path afterwards, buy the course then, and you will know what you are looking for.

There is also a shorter route that suits plenty of people better: instead of a general purpose language, start by building a web page. You see the output in the browser, the feedback is immediate, and those same three ideas of loop, condition and variable are waiting for you in JavaScript later.

Programming, coding, software engineering: what is the difference?

In everyday talk these three get used interchangeably, and that is fine. To be precise: coding is the act of writing instructions in a language, programming covers the whole business of solving the problem, of which coding is one step, and software engineering starts to mean something when several people work on one thing and that thing has to last for years: versioning, testing, documentation, delivery.

The distinction is useful in practice. If you are learning, you begin with coding, but the thing you actually need to practise is programming, which is that second step everybody skips. Software engineering is not something you practise at home either; you need it once you become several people, or once your code grows big enough that you lose your own way inside it.