Do you or don't you ....pseudo code?

Curious to know what opinions are regarding writing pseudo code for a large Visual Studio project.

Back in 1983 when I had my first computer programming class, it was taught in Pascal on the old TRS-80 Model 4 console, and my teacher drilled us thorougly on writing out pseudo code before writing any actual code. Over the years, I found that I write little pseudo code, but for large projects I still sketch out some basic stuff in Notepad before starting any coding.

Now, with VS2005 and all its revision-friendly features (i.e intellisense, global variable renaming, etc), its easy to be lazier and just jump right in. Not the best practice. Anyway...

1) Do computer courses nowadays emphasize pseudo code at all?
2) Do YOU write any pseudo code before/during a modern project? If so, what tools do you use (Notepad etc?)
3) Have you never used pseudo code?

I only Pseudocode when I am not sure how i am going to flow out the function/application/process. That way I can try to catch the kinks.

For a very large, complicated project that requires a team of programmer to work on, psuedocode will eliminate a lot of headaches later on... So my answer is, with small projects, no psuedocode is required. However, with larger projects, planning (that includes sketching a psuedocode) is a must.

I second stanv completly (on this subject)

I see many programmers spend lots of time on old projects if they don't have their proper diagrams/pseudo code. Doing this up front may cause you some extra time, but when you have to go back to some old programs to make updates, it take 10 times longer figuring out what you did 10 years ago. I just pull out my notes and in a few minutes, I know what each part does.

Just my 2 cents.

I dont pseudocode but I do use notes from project requirement gathering. If its a large project then I will flowchart or pseudocode. Also, commenting your code reasonably well helps to restore your memory when viewing old code.

we don't pseudocode here either, but we do have a design process from which comes a document that has all the logic in it.... so there's no need for the pseudocode.

-tg

I think it all boils down to company procedures or personal preference. Pseudocode is still taught at the classroom level, but is not drilled into your head like it used to be. The best practice is whatever works for you to complete your task without stopping to remember how you were going to go about completing it. Some people use sketches, some use flow charts, some use pseudocode, and some use plain old notes.