i'll occasionally use pseudo code for extremely complex algos (like an entire renderer) or when i have to invent extremely complex algos. its such a powerful development tool, its overkill for 99% of day to day work.

A slightly different way to look at this is writing unit tests first.

Yes, it's not exactly the same; your unit tests should be looking at results and important side effects not implementation, but you'll usually find your implementation will fall out of those considerations anyway.

I sometimes write comments first (not pseudo-code), then write the code to replace them.

I usually do this when I have the entire purpose/functionality of a function in mind (and the function needs to do a lot), since I can quickly write the comments/steps it needs to perform. Whereas if I went straight to coding, I might get slowed down by the details and forget parts of the larger purpose. Then as I'm writing the code I can re-factor as necessary, split out into different functions, etc...

Usually when logic goes a bit complicated. I wrote them down so I don't forget my line of thoughts.

Lately I've been reading a lot of advice regarding coding structure that suggested to draw class interactions and write pseudo-code or comments explaining what you're going to do before starting actual coding. Since it's something I've never personally found useful, I'm kind of curious to know if there's a common preference here.

To explain better what I mean, I once worked with a guy who wrote whole functions in comments before writing the actual code, like in the sample below:

int fibonacci(int x) {
    // If x < 0 throw an exception
    // If x is 0 or 1 return 1
    // Return sum of fibonacci(x-1) and fibonacci(x-2)
}

His comments were probably less code-like than mine, though.

I understand that we people are wired differently from one another and for some it's easier to think first in a more natural language and then translate it to code and others think better in code than in natural language, but I want to ask, do you guys use this kind of techniques? Why do you find them useful or not useful?

Pseudo - Is useful for me to understand what needs to be done in coding.

Comments - Is for any other programmers to understand whats going on in my code. It also helps me in a way while I am coding; if I dont need a certain block of code or trying something out to optimize my code, I would just comment it out instead of deleting it. It is better to have the old block of code (commented) while you are figuring out a new block of code that does that same thing. It will be hell if you just delete the code.

I do not, I prefer "normal" comments, both interface and implementation side.

I sometimes write comments first (not pseudo-code), then write the code to replace them.

Here here.

sometimes i do. when i begin something, usually i dont care about if it is compiles or not, i write the thing almost blindly for 1-2 days, and i only hammer it together to a working code in the folowing days.

Lately I've been reading a lot of advice regarding coding structure that suggested to draw class interactions and write pseudo-code or comments explaining what you're going to do before starting actual coding. Since it's something I've never personally found useful, I'm kind of curious to know if there's a common preference here.

To explain better what I mean, I once worked with a guy who wrote whole functions in comments before writing the actual code, like in the sample below:

int fibonacci(int x) {
    // If x < 0 throw an exception
    // If x is 0 or 1 return 1
    // Return sum of fibonacci(x-1) and fibonacci(x-2)
}

His comments were probably less code-like than mine, though.

I understand that we people are wired differently from one another and for some it's easier to think first in a more natural language and then translate it to code and others think better in code than in natural language, but I want to ask, do you guys use this kind of techniques? Why do you find them useful or not useful?

At this level of detail, it's easier to just write the code. Often enough, it's clearer, too.

When I do something like this, it's usually much more high-level, to rough out some control flow. A line of pseudocode usually amounts to at least an entire function, or even a module.

Rather than writing out pseudocode, i tend to brainstorm with the rest of the team.

We take ten minues out and i write down a step by step or flow chart of what i plan to do on a whiteboard, and then we all dive in and poke holes in it.

Sometimes, the best set of eyes are someone elses...