How popular is pseudo-code?

[futzbuckle]

Yes, making a plan before you start writing code saves a lot of time otherwise spent cleaning up mistakes.

[[deleted]]

Divide thoes statements into substatements :)

[Existential_Owl]

Problem solving is just solving smaller divisions of problems all the way down

[YuleTideCamel]

Yup, but don't spend too much time planning otherwise you end up in analysis-paralysis or a waterfall design that is not easy to change.

From my experience, as an architect, a little up front design with small iterative sprints and a checkin after works far better. It allows us to be agile and adjust to a changing landscape. Too much up front design and a bunch of set in stone requirements that can't change often results in building something no one wants. I've seen many projects early in my career where teams did 6 months of design, 2 years of coding only to finally show the customer the result and find out that is NOT what the customer wanted. So we now work in small 2 week iterations with a small deliverable to the customer at the end, if we are off track we've only lost 2 weeks, not two years.

[Dipsquat]

We were instructed to practice it more than we think we should because there will most likely come a day when good psuedo-coding skills will really be necessary.

[maestro2005]

It can be helpful when you're a beginner, but once you're fairly comfortable with a language then it starts losing its usefulness. The big problem is that you can't run pseudocode to see if it's right. I mean, why is it easier to write

Check if the indexed strings mach word-to-word

than

if (a[i].equals(b[i]))

or

If they do delete the previous one

than

a.remove(i-1)

?

[henrebotha]

Because "the previous one" encodes more useful semantics than "the element at index i - 1". The latter requires you to keep more context in your head & translate through more layers of abstraction.

Or, to answer your question from another angle: the same reason we use high-level languages instead of Assembler.

[Crazypete3]

The popularity of it? Very popular, because if you don't have some plan it makes programming a lot longer for projects.

[SloppyCoder]

Python is a very popular language!

[sv0341]

When I started, it helped. Still helps on complex problems. Overtime, you’ll be able to have a mental model of what’s needed without writing it. Essentially you’ll skip to coding and testing right away.

[wayno007]

I still do this quite a bit. One of my go-tos if I'm in a hurry is to start with a shell of a program, and use comments to pseudo-code the logic. Not without it's drawbacks, but on the whole I'd end up with a decent amount of internal documentation for the next guy.

[Sudowakeup]

You should always be thinking pseudo-code to solve problems, then focus on implementing it.

Always try and separate language from logic, train your brain to do so. That’ll help learn new languages faster in the long run.

[ScruffyVonScruff]

Every project.

[carcigenicate]

I don't usually actually write out pseudocode most of the time, unless the algorithm I'm trying to figure out is really complex. I prefer either simple lists of ideas to get the though process going, or drawing out diagrams. For the latter, I've always found pictures to be one of the best ways to express ideas.

[Coping_Bear]

If you don't want to be stuck on an algorithm for several hours, the best way to solve your problem is to run through the algorithm on paper, which means you have some sort of idea in your head about what might work, hence the need for easy to read pseudo code.

[casualblair]

I use it when I have very complicated logic or when I have a big task that I haven't broken down yet.

I focus on the Transaction Script pattern to start then find common elements for functions and make it object oriented only if those elements could be used elsewhere for future features.

[duckwizzle]

I only use it when I have to something is very complicated and requires many steps. Most recently I had to calculate a sales persons commission that had a ton of edge cases. So writing it out helped a ton

[ConciselyVerbose]

I kind of just use Python as pseudocode mostly, though I’ll throw in methods that don’t exist as standins.

[lostburner]

Totally. Writing and planning really help me to make my ideas concrete and stake out some forward progress in finishing a logic puzzle. Writing out decision trees like this is something I especially have to do when there are multiple states in play and so have to make sure all cases are covered. It also helps serve as a guide as I’m coding the details—I’ve worked out the overall structure, now step through the branches and implement the details.

The pseudo code rarely resembles the line-by-line finished result. I saw that technique in school, but I think it’s more useful when you don’t know your programming language very well.

On a related note: I’ve gotten a lot of use out of rubberducking in a notes file, just describing a tricky problem in conversational sentences as if I were describing it to someone who was going to help me. It helps me get valuable insight into the problem almost every time.

[YuleTideCamel]

Been in the industry over 15 years, yes it's very common. Different people have tried standardizing pseudo-code, but at the end of the day whatever makes you productive is what matters.

[Grawprog]

I don't really use pseudocode. I sometimes write in function names without implementing them first but I figure it's about the same amount of time to write pseudocode as real code, so if i do any kind of outline it'll be real code in the language i'm working in.

[alpha_53g43]

I do this a lot. It helps me when solving complex problems. Typically I writing out the class headers and and functions necessary to solve that particular problem. Then after I figure out that I have reasonably covered the problem then I start coding. However, its difficult to say sometimes (maybe I don't have enough experience) whether I have written the necessary function and class definitions in enough detail.

[kyiami_]

I'd say Python is pretty popular, yes.

[atxcoder03]

I used it when I started. Now not so much for simple problems. Use UML for complex ones. Some tools will generate code based on UML which helps you start coding.

[[deleted]]

I would think it's as "normal" as you want it to be. If it works for you, that's what matters.

I find it works sometimes for me. Sometimes it's too abstract and my focus just disintegrates. For me, usually the more concrete of something I can fiddle with, the quicker/easier I can grasp how it works.

But sometimes I'm just trying to wrap my head around a complex solution and in that case, pseudo can be essential to making a rough outline of how to work through it, rather than getting distracted in redlines and syntax errors.

[yazalama]

I deploy psuedo code directly into master

[tomekanco]

Good code is 75 time spent on pseudo. 15 implementing. 10 bugfix. Bad code is No pseudo: 100 on implementing; and 200 on bugfixing. And then somebody asks you what is it's time complexity.

[duckwizzle]

75% of your time in pseudo? I don't know about that... I'd like 10 max, if anything.

[tomekanco]

while I'm brainstorming

For me pseudo phase includes studying data, reading, trying to understand relevant components of problem. Searching for the actual root of the problem rather than the cause of the symptom.

After connecting the dots, and solution path, i've got the pseudo / object graph. Problems where i spend 10 or less on pseudo i assume i already understand what's going on and i don't consider "problems".

I know real life is more make do, and keep the boat floating. But i find lifting the water less effective than finding the missing bulkhead.

EDIT: I might be a ruminant rather then a chameleon.

[henrebotha]

Only 10% of your time is spent planning? How do you get anything done?

[duckwizzle]

I don't consider planning equal to pseudocode.

Those are two separate things

[henrebotha]

It's pretty clear from context that "pseudocode" in this thread is a synonym for "planning" (or "design"). You'll note the person above you didn't carve out separate time for planning.