Unless it's something quite trivial, yes - I use pseudo code extensively.
If I don't know how to code up a program, I start out just thinking about how I would do it, without a computer. If run time is of no particular concern, I'll do the task (or a simple version of the task), a few times until I'm confident of the pattern I want. I write that out, but it's too general and "human" to be really useful for coding, so I take that "write up" and break it down into pseudo code. From the pseudo code, I break it down into C code.
If run time is critical, I'm always looking for algorithmic speed up tricks that work so well with computers: divide and conqueror, sorting and binary searching (instead of just searching all the way through a large amount of data, over and over), indexing, hashing, bit tricks, counting sort, etc. People are generally efficient in how they work, but computers have some specific tricks that just are stunningly faster, if they can be applied to the program you're coding up.
Although I want my programs to run fast, I have learned that it's best to temper that with real clarity in the design of the program. Simple is not crude, it's elegant; removing the dross, and leaving the work of art so it can be seen and appreciated. Code that is not intuitively clear, better have a damn good reason for it's creation. Fortunately, simplicity tends to make fast programs, but more importantly, they are easy to modify, and keep bugs down to the absolute minimum, as well.
