Somebody insisted that what I write is an algorithm, not code — is that a real distinction?

They are genuinely different, and the relationship is straightforward once stated: code expresses an algorithm.

An algorithm is a procedure — a finite sequence of unambiguous steps that takes an input and produces an output. It is an abstract object. It exists independently of any language and can be written in English, in pseudocode, on a whiteboard, or in your head.

Code is a concrete text in a particular programming language that a machine can execute. The same algorithm has many possible codings; two implementations in different languages are the same algorithm and different code.

So binary search is an algorithm. Your twelve lines implementing it are code.

The distinction matters when you are reasoning about correctness or complexity, because those are properties of the algorithm rather than of the text. It matters much less when you are describing what you spent your afternoon on.

And the answer to your second question is that he was being pedantic, and slightly wrong as well.

Most programs are not one algorithm. A typical application is mostly plumbing: reading configuration, handling requests, mapping between representations, calling libraries, formatting output. Very little of it is an algorithm in the technical sense, and calling a whole program "an algorithm" is a stretch that the word does not support.

"Code" is the correct and ordinary term for what you write, is used universally by people who do it professionally, and has been for decades. It is not slang and it is not imprecise.

My guess about what happened: in some older engineering education, particularly outside computer science, the word people learned was algorithm, and "code" was not part of the vocabulary. He was not correcting you so much as reporting that your word was unfamiliar to him.

Worth noting a third word that sits between them and gets used sloppily: implementation.

An implementation is a particular realisation of an algorithm, which is very nearly what "code" means here but emphasises the choice rather than the text. People say "the reference implementation" precisely because there could be others, all of the same algorithm.

Once you have algorithm, implementation and code as three words with three jobs, conversations about performance get noticeably clearer.

There is a genuinely useful version of the distinction that is worth carrying away from an otherwise unhelpful exchange.

When something is slow or wrong, it is worth asking which layer the problem is in. Is the algorithm wrong — the approach is quadratic when a linear one exists, or the procedure does not handle a case? Or is the code wrong — the algorithm is right and the implementation has an off-by-one, or is allocating in a loop?

Those call for completely different responses. Optimising code that implements the wrong algorithm is the most common way to waste a week, and the reason people do it is that they were not separating the two things.

So the vocabulary point was pedantic and the underlying distinction is worth having.