If you mean on Stack Overflow, I don't know whether anyone there makes a puzzle/problem distinction or how they make it, and I don't think it's something on which PSE folks can usefully comment.
If you mean here on Puzzling, the principle would be the same as for mathematical questions. It's pretty well expressed in this answer by xnor. Something is a problem if its solution is basically routine and involves doing standard things in standard ways; it's a puzzle if its solution involves some surprising bit of insight. xnor mentions some other factors, but I think they are rather less important than that.
This principle clearly doesn't entirely capture the difference between puzzles and non-puzzles. A standard newspaper sudoku puzzle can be solved routinely -- it's not hard to write a computer program that does it -- but it's clearly a puzzle. I think part of the reason why is that it's intended for recreation, though that's a problematic criterion since it's a fact about whoever made the puzzle rather than about the actual puzzle itself.
For something to count as a programming puzzle and be appropriate here, I think (though this isn't intended to set Official Policy or anything; if it turns out to matter enough to have an official policy, we should debate it more carefully) it should have the following properties.
Solving it should be non-routine. If a good-but-not-exceptional software developer could solve it in half an hour without thinking "aha!" or "wow!" at any point in the process, it's probably not a puzzle.
It should be fun. E.g., if something requires 300 lines of code then it is probably not fun. Any program you have to write for a puzzle should be short and sweet, much shorter than the great majority of nontrivial programs written out in the real world.
There should be something particularly nice about the question or its answer or, even better, both. A particularly elegant algorithmic technique, a bit-twiddling trick that does something much more concisely than one would expect, that sort of thing.
I don't think the turtle-graphics question you link to meets these criteria, though it's within spitting distance.
Many recreational programming challenges would be a better fit for Code Golf than here. In particular, that's likely true for any challenge like "write as short a program as you can that does X" or "write a program that does X as quickly as possible".
Also relevant: the actual official PSE policy on mathematical questions which, as well as the non-routineness criterion, mentions two others that I think are broadly applicable here: questions should be comprehensible to a reasonable fraction of PSE readers, and to whatever extent a question involves domain-specific technicalities there should be a "Puzzling-friendly payoff": some reason why ordinary PSE readers might find it worth looking at despite the technicalities.