Pseudocode might have made sense in the age of assembler, FORTRAN and C programming but nowadays the two main reasons for using it are probably:
Not mastering your programming language.
Not knowing about refactoring - nobody gets a non trivial task right at the first try. Code is not something you write once and never change it afterwards. But that's not a bad thing: Changing code is cheap if the code is clean.
Maybe there are some rare occasions where pseudocode does make sense but in most cases there are better tools to use when you are not yet ready to code: Draw diagrams write specification documents, talk to people, build a prototype, write unit tests (TDD).
What sucks most about pseudocode is that it will not provide any feedback.
Why does this matter to me after all? Because I think that it is much more helpful in the long run to put your energy into the real code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I completely disagree.
Pseudocode might have made sense in the age of assembler, FORTRAN and C programming but nowadays the two main reasons for using it are probably:
Not mastering your programming language.
Not knowing about refactoring - nobody gets a non trivial task right at the first try. Code is not something you write once and never change it afterwards. But that's not a bad thing: Changing code is cheap if the code is clean.
Maybe there are some rare occasions where pseudocode does make sense but in most cases there are better tools to use when you are not yet ready to code: Draw diagrams write specification documents, talk to people, build a prototype, write unit tests (TDD).
What sucks most about pseudocode is that it will not provide any feedback.
Why does this matter to me after all? Because I think that it is much more helpful in the long run to put your energy into the real code.