I've answered many questions on Stack Overflow,
many of which got me to sit down and think in a way like it were an entertaining puzzle!
Here is an example of such a post.
I want to know where the line is drawn to separate programming puzzles and programming problems (sort of like the line between math puzzles and math problems).
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.
I saw (and answered) your first programming puzzle. I think it's a good start, and it does fit better on Puzzling than on Code Golf, which moved away from Puzzling-style challenges (those that have one or small number of intended answers). However, as a long-term challenge setter on Code Golf, I have some advice for you (and other potential programming puzzle writers):
This is (IMO) 90% of the reason Code Golfers use the Sandbox.
A programming puzzle can be written in various ways, including but not limited to (minus those that are on-topic on Code Golf):
All of these involve a task to solve. If it is not well-defined, the readers won't be able to judge whether a given program solves the task or not. One example is the OP's first puzzle (linked above), where the expected result is given as a console output from the print. Some example outputs have trailing spaces to make it rectangular, but the last one has part of them truncated. This makes the task not well-defined, and hence my question in the comment ("Are the trailing whitespaces on each row significant?"). Whether they should be printed or it doesn't matter, the task should mention that.
As already pointed out by Gareth, competition-style challenges (e.g. "solve it in few bytes as possible") are on-topic on Code Golf, and therefore not suitable to Puzzling. Try to make your puzzle more focused so that it has only one intended answer. A puzzle with a few unintended answers is fine; a puzzle that is too open that it may start a competition between answerers is not.
Also, a puzzle which can be trivially solved with knowledge about basic language features (syntax and built-in functionality) is not a good puzzle either. Introducing seldom used features or hiding it in a clever way could be fine.
