problem vs algorithm vs program

There are three different things hiding under the loose phrase "writing some code," and keeping them apart prevents a lot of confusion. The problem is what you want done. The algorithm is the method you choose to do it. The program is the method written out in a real language a computer can run. Think of building a bookshelf: the problem is "hold these books"; the algorithm is the plan ("cut four boards this length, join them like so"); the program is the actual sawing and screwing in your garage with your tools.

Each level answers a different question. The problem is a specification: given this kind of input, what output is correct? It says nothing about method. The algorithm is a procedure: a finite, unambiguous, language-independent recipe that meets the specification — you could describe it in pseudocode or even plain English. The program is an implementation: the algorithm encoded in Python, C, or any language, with all the fiddly real-world details filled in (variable names, memory, error handling). One problem can be solved by many algorithms; one algorithm can be turned into many programs in many languages, all expressing the same underlying method.

Why insist on the layering? Because correctness and speed live mostly at the algorithm level, not the program level. If your algorithm is quadratic, no amount of clever C or a faster laptop turns it into a near-instant n log n method — you must change the algorithm. Conversely, a brilliant algorithm can be ruined by a buggy program. Separating the layers lets you reason about the method abstractly ("is this approach correct and fast?") before sweating the implementation details, and lets the same good idea be reused across languages and machines for decades.