How I explain what I do:
Programming is like solving a puzzle
Think about a cryptic crossword puzzle.
In the beginning, I don't know what the solution is, I only have an idea what it will look like. I am confident, however, that I will recognize it once I have it.
The process of getting there is not mechanical. It involves a whole lot of obscure trivia. The amount of obscure trivia about the problem domain that I have accumulated in my lifetime has an influence of my efficiency at solving the problem. Sometimes I have to go back and learn some more trivia. That is, in crossword puzzles, I will regularly look up some bits of antique Greek mythology, or anatomical terminology. In programming, that's like learning how to use a bit of software that someone else has written (for us software types: checking out an API that's new to me).
It is creative in the way that I need to try out new ways to plug bits of trivia together in order to arrive at a solution. It is rewarding in that I feel a little bit of progress for every little clue that I solve. This is why, even after weeks of hacking away at "one problem", I am still motivated. I can also see how the solution is beginning to shape and grow (there are exceptions, but more on that later).
In crossword puzzles, for every clue there is exactly one solution, even if you might not be able to identify it without correlating crossing answers. In programming, even after everything is in place, there are often multiple valid solutions for a part of the problem. Possible solutions will differ in expressiveness or the degree to which they can be understood by someone else, style or elegance of the code itself, efficiency, and often there are degrees to which they are actually appropriate solutions for the original goal.
Corollary: How this helps me understand planning
Figuring out possible answers to neighbouring parts will drastically reduce the solution space for a specific part. Um ... let me try that again.
This time, picture a jigsaw puzzle. If I point at the middle of an empty space and ask, "Which of the pieces belongs here?", nobody can answer that. But once the rest of the pieces are in place, the shape of the missing piece becomes obvious.
In developing a software program, it is often not so clear why that is so, but it makes sense to start at the fringes in much the same way. Start filling in the obvious answers first. That gives a sense of progress that is false to some degree, because the not-so-obvious answers will take much more effort to fill in. That means the velocity with which we fill in answers will drop significantly at some point.
However, filling in an answer will be easier once the adjacent puzzles are solved: Interfaces will take shape and data structures will be known.
Now it is possible that we realize that the adjacent solutions don't allow an efficient solution to the remaining unsolved part of the puzzle. Then we have to go back and change things. But in my experience, having thought about part of the problem well enough to provide some answer surprisingly makes it easier to make up my mind about another part of the puzzle.
Thus when planning efforts towards solving a larger programming problem, among other rules (like "find answers to the highest-risk questions first"), I try not to be too much intimidated by seemingly unsolvable puzzles. Put them on the backlog. Think: "What's the simplest question I will have to answer before understanding this?", put that on the backlog to be answered first. Have faith.
When I'm done, I get extra reward for seeing that the solution as a whole is valid, and now I can verify that it is the only solution - to a crossword puzzle. In developing a large piece of software, I often get to a place where I am not entirely happy with some parts of the solution, but for some reason (time, external constraints, technical idiosyncrasies) I don't find a "perfect" solution. Or I just keep having a nagging feeling that I might be missing something somewhere, but I am not allowed the time (or I am too lazy) to go back and find out what.