Interesting! I think it's really important to learn how to get past the blank editor problem - there's nothing more intimidating than a blank sheet of paper. I've not tried doing it with pseudocode.
I rely on writing a test first - identifying one behaviour of the program I want to write and imagining that I've already written it. What does it look like? What will it do? What function gets called? With what? What will it return?
For me, a test gets me solving one small problem, gets something down on the page and stops me fretting about everything else that's going on in the code/in my life/ on TV.
Does your pseudocode have an afterlife? Does it be become comments or do you tend to bin it once it's been replaced by code?
I think that's a really natural progression, and I normally write function declarations or tests first too. But, for beginners/jr devs, I think writing more traditional pseudocode is super helpful. It depends on the program, but I am normally minimalist on comments for simple code, maximalist on longer form documentation.
for your afterlife question, as it was recommended by steve mcconnell( software engineering expert ) Once the pseudocode is written, you build the code around it and the pseudocode turns into programming-language comments. This eliminates most commenting effort.
As a result the comments will be complete and much more meaningful.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.