When I am trying to solve a problem, I write the problem down first, then move into breaking it down in a process. I define the actors involved, the expected input and the expected output and any error conditions that I identify. Then from there I generate a simple hand written flow chart (not fancy) that will serve as a happy path through the problem.

When I get to the engineering of the problem that is where I start identifying parameter limits, error conditions, output limits and then generally write down some pseudo code to give me something to look at, sometimes that means flushing out a more complete flow diagram first. And I generally use just natural language, as none of what I am writing down is real code, although I may use abbreviations or C syntax at times to express something if it is easier. For example, I use the conditional ? : quite often for simple flow control statements just because it is compact to write, even though in code I may not use that operator in that instance.