This is why expressive programming languages matter. If your language is expressive enough, the sketch will be executable.

Expressive languages help, but for anything larger than a homework problem I would still sketch up the system elements and how they communicate on a piece of paper, then write the implementation in a high level pseudocode. My 2c.

It's good advise and has helped me a lot over my 32 years of writing code (you pretty much had to pseudocode when I started as assembly isn't exactly expressive, especially for a young kid).

Does anyone actually do this?

I have never seen people write pseudo code as part of the programming process.

Diagrams, comments, tests, stubs sure, but never really pseudo code.

I do it regularly but it's always invisible if all you see is the resulting code.

I do it to structure my code, but I remove the comments as I implement it because I try to make it obvious in the code what's being done. You know, regular good programming, pick good names, keep the code reasonably short, add comments when needed, etc.

The same way you won't see the detailed outline of a writing once it has been written. Yet, the author likely started with an outline.

Sometimes, for some confusing piece of functionality that I am developing, I would write pseudocode in a comment first to see whether it makes sense; and would use it as an outline for implementing the feature. I've found it useful. I've never read Code Complete though :-)

Yes all the time, how else?

I mean if it's just a few lines, a change to existing code, etc, you can jump straight in with actual code.

But if it's a new object/module etc, start by writing some function names, and some rough structure within them, etc. All in IDE/editor. And I wouldn't call it pseudo-code, just a rough outline.

That's exactly my point.

An outline is a very different beast compared to pseudo code.

It's effectively the difference between operational semantics and denotational semantics.

I studied systems engineering and the first class about algorithms and data structures started using pseudocode, then Pascal. And they still do today.

>Diagrams, comments, tests, stubs sure, but never really pseudo code.

Hate to break it to you ... but those are all forms of pseudocode (or verification of your process (which is nearly the same thing)) :)

Interesting. I always do that when programming something non trivial. I found it very helpful to sort the threads and clear my thoughts and capture what I don't know but I thought I knew.

I then keep the pseudo code as comments in code and go from there.

But I don't know others are doing the same. I'm a pretty mediocre programmer so I have to do it a lot.

in nearly all my 100- and 200-level programming classes 20+ years ago, we had to hand-in a pseudocode for our assignment before our assignment

It didn't have to be completely correct, but it did need to be directionally correct (or, at least illustrate a way of solving the problem, even if we ended-up doing it differently)

I poo-pooed those, and would only create my pseudocode after writing my program - I'd already "been programming" for close to a decade, so why go through the 'pointless exercise' (as I thought at the time) of designing a solution only to have to implement the solution?!

Then I left those intro classes and we started getting more-interesting assignments

All of a sudden, having a plan - even a very simple block diagram, or set of bullet points, etc - became vital to solving the problem

I don't know that I'd tell someone to fully pseudocode their solution before implementing something today ... but blocking it out, getting the high- and medium-level logic/parts drawn-out/written-down is most definitely vital to having a chance at a successful implementation