I’ve heard that styled as “do project the document, don’t document the project” but I don’t know a source to attribute this to.

The idea is to write a rough draft that covers what the project is, what it does, the API structure, and how to use the project, then write the code, “projecting the document”, and finally sort out the documentation - comments in the source, everything else in a manual page, article, or research paper.

This sounds a lot like TDD, but with comments instead of tests. It's an interesting technique I never heard of.

Do you ever get back to code you wrote and find a lot of misleading comments that you simply forgot to delete/update? Or are you always updating the comments before you try a new approach if the first one didn't work out?

The pseudocode comments are way too detailed and too much noise to keep in the code. I’m not going to keep a comment in the code like.

   //increment i 

But also if the comment is something like:

  //Call the API to get a list of customers. 

I’m going to replace it with

  List<Customer> customers= GetCustomers(); 

Use the IDE to create a valid stub function and delete the comments. The method names become self documenting. At any point I have code that compiles.