I’ll do comments first and then code. It’s a lot faster for me to keep a flow and pseudocode and then write the code in between. If the comments are two pedestrian afterwards (increment i), I will erase the comments.

I started this technique early in my career back in the late 90s after reading “Code Complete”.

It also helps me to pick back up faster if I get interrupted.

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.

At a previous job, when I transitioned off a few projects that I had solely worked on for 7 years, I warned the dev taking over from me: I don't usually comment my code, but when I do, you'd better pay attention.

I think in one of them, only a single source file (C++) had comments, and there were more comments than code. I was explaining an intricate locking pattern around a data cache.

Like you suggested, I added the comments after I'd done the work because it was a work in progress. I added the comments because it was a very fragile piece of code and sensitive to changes (e.g. really easy to cause a deadlock or race condition if changed).

I get the feeling, but I rarely think "I'm completely done now, time to comment!" Better to admit that and document a bit earlier than when it's "finished".

More accurate comments that way, isn't it. Nothing sadder than the optimistic comment from before implementation, which took the regular twisty path towards correctness in the corner cases. More of a risk for the higher level methods than the little "DRY" functions that do something relatively functional.

I frequently think just before committing/pushing, "Time to add some comments!" That doesn't mean the code is fully finished, but it does provide a clear point in time to add them (when needed).

I think this is a matter of coding style.

When I'm writing something I'm generally "top down", breaking the problem into sub-tasks. In this mindset I'll often start a sub-task with a comment describing what it needs to do, and then set out to do it. If it turns out I was wrong about what I needed to do then I update the comment, but that's not that common.

While working on it my comment explains what the block should be doing. Extra points for lists of harebrained ideas that will likely never happen.