I only write pseudocode if I'm trying to explain something on a forum post. I tend to just write real code personally.

Same with me.

For complex functions, I sometimes add comments to help me figure out the structure flow:

bool LoadConfigFile(const std::string &filepath)
{
     //Try to load the file.
 
     //Make sure the file loaded properly.
     if(!file)
     {
           //Log an error message and return.
           
           
           return false;
     }
 
     //Crawl through the file line by line.
     while(...)
     {
           //Check if it's a comment.
           if(...) continue;
           
           //Separate the variable name from the value.
 
           //Push back the variable into the results with the value.
           
     }
 
     return true;
}

Not the best example - but if it was a more complex file format, this kind of commenting helps me (it especially helps me identify what parts should be separated into different functions).

I don't do this for every function, just ones that I need to think through. The process only takes about 60 seconds, and then I leave most the comments inplace as actual comments.

Here's another example, where I use the comments to separate sections of the function, rather than forming structure.

void intializeModelViews()
{
     //--------------------------------------
     //Create the models.
 
     //--------------------------------------
     //Create the views.
    
     //--------------------------------------
     //Attach the views to the models.
 
     //--------------------------------------
     //Hook up the view signals to the slots.
 
}

I tend to do this when I have alot of visually-identical code that needs to occur in a certain order. (e.g. I have four *different* views and four *different* models and they need to each connect two signals to two *different* slots...). Different enough that it doesn't make sense to wrap it into a function, but similar enough to group it together.

In this situation, I'm doing it more for the code's appearance, rather than to help me think through it.

My experience coding the program has always been a bottom up design approach, creating each implementation one by one until it works but not having an entire understanding of how the whole code structure.

Seeing this thread makes me want to go for the top down design approach which is better because using that approach means you have a better understanding of the entire coding structure but not how to create the implementation.

If it is something more complicated like getting a collision to work, I would draw some coordinates and test my code on paper. It usually helps to have a visual aid because it gives me something to work off of and getting my creative juice flowing. Even working on 5 small games, everytime you are doing something new, it will always take longer than you think.

Comments do help to remind me which part of the code needs fixing and why I code it this way rather than saying this is how the code works.

I often use something called Program Design Language. There is even a very old article on this site: http://www.gamedev.net/page/resources/_/technical/general-programming/using-pdl-for-code-design-and-documentation-r1384

Basic you start writing your program as high-level non technical comments and fill in the details afterwards. You end up with well documented code.