Does anyone use pseudocode in the real world?

All the time. I usually write a block comment explaining what I'm trying to do with a piece of code (method/class/etc.) before I even write any "real" code. The pseudocode varies between full English sentences ("1. Make sure the folder exists before creating file, 2. Create file with sanitized name, etc.") to more schematic ("sanitize file name AND create file IFF folder exists").

To me, it's comparable to writing a paper; I could never write a paper without a proper outline and knowing where I'm starting and where I'm going.

Yes

Understanding the algorithm, the states, the model, the constraints, the dependencies, the properties,... at all times is what makes you an engineer.

Technical standards and publications about real life issues (like mutex, db management,...) often use pseudo code, because the actual implementation doesn't matter.

Pseudo code is also relevant because languages change anyway. And in some companies and industries, several teams use totally different codes you won't know of.

Coding right away is possible. But it's not the same job. You can be paid big for actually thinking through your code, and not just writing it.

Definitely. How could you not? Even w/ auto-complete/CoPilot coding is never as fast as thought, especially when mapping out broad outlines of an implementation.

Besides, test-first development is inherently writing pseudocode where you write MagicFunction() and then TestMagicFunction() and iterate to flesh out both.

Also, who doesn't write a first pass of some code and then drops a comment that says /* handle special cases x, y and z here */ for later?

All of that is pseudocode.

Its great for writing code-agnostic specifications for software. And is often easier to read than actual code.

Languages like TLA+ can be considered as a form of pseudocode as they cannot be compiled down to code.

Yet TLA+ is used very much in the real world for describing complex algorithms.

I do it a lot in code review. If I'm asking for a change, I like to offer a suggestion of how i'd implement it, but I'm not actually going to write all the code and get it running, pseudocode is enough.

Then there's always the joke about Ruby, where you just write pseudocode and the interpreter just runs it.

Yes. When you’re having a conversation about programming concepts, but you don’t want to get lost in details of implementation or gotchas related to a given language, you operate in pseudocode.

I will note though that when I was in school there was an “official” pseudo code, and I’ve never met anyone who uses that. It’s usually just a lazy C syntax.

Yes.

- In design docs:

  - use pseudocode for complex business logic, and/or algorithmic parts (similarly as it's used in scientific papers)

  - Also use it when MSD (Message Sequence Diagrams) would be too complex, or too detailed

  - Pro tip: If you're writing design documents and you're pressed for time, start by writing pseudocode. Later, if you have extra time, you can convert the simpler ones into diagrams or other relevant visuals.

- In code comments:

  - use it in case when code is non-trivial, or hard to understand

  - use it for a placeholder for yet to be written code, or in TODOs

It's often used in scientific publishing where it is preferred over executable code.

Not a single time in my 35 years as a software engineer; in times I use state or other diagrams, but besides that I just explain the intention in prose comments where necessary. Pseudocode is just another "language" you have to learn, which is why I prefer algorithm or compiler books with examples in common programming languages.

If I am whiteboarding with people in work I definitely don't try do proper syntax etc. That is pseudocode to me.

It comes in handy sometimes. It's most useful when you know what algorithm you want to implement, but have to do it in a language you don't know too well. Like if I have to do something in Rust or JavaScript.

for the same things as in academia (sketching algorithms), but that just doesn't come up very often for most people

I mean, I sketch ideas out in Excel formulas or quick little Python scripts that I talk out with GitHub co-pilot...

I did quite recently, to communicate requirements to devs working in a language I wasn't familiar with.

Often in code reviews and other discussions to describe some alternative approaches.

mostly when working with strongly typed languages (go, typescript) and i dont want to go through the trouble of writing out perfect syntax to share a quick idea. ends up kinda looking like python i suppose

yes - i'm not a programmer but i need to translate business rules for my contractors to build. it helps us 'meet in the middle' when discussing abstract things.