Pseudocode helps us understand tasks in a language-agnostic manner. Is it best practice or suggested approach to have pseudocode creation as part of the development lifecycle? For instance:

  • Identify and split the coding tasks
  • Write pseudocode
  • Get it approved [by PL or TL]
  • Start Coding based on Pseudocode

Is this a suggested approach? Is it practiced in the industry?

  • What are "PL" and "TL" that would approve your pseudocode? Oct 18, 2010 at 16:38
  • @Andy PL/TL : Project Lead or Team Lead for the developer who is writing the pseudocode.
    – Vimal Raj
    Oct 18, 2010 at 18:14

16 Answers 16


Writing pseudocode before coding is certainly better than just coding without planning, but it's far from being a best practice. Test-driven development is an improvement.

Even better is to analyze the problem domain and design solutions using techniques like user stories, use cases, CRC cards, diagramming, as espoused by methodologies such as Cleanroom, RUP, Lean, Kanban, Agile, etc.

Thoroughly understanding the nature of the problem and the components you use to implement the solution is the principle behind best practices.

  • Test Driven Development result in less seams in the code.
    – user1249
    Oct 18, 2010 at 14:42
  • @Thorbjørn, TDD doesn't dictate where seams should go (but then again, neither does pseudocode). It's used to ensure they have a sensible interface, and follow-up changes to the codebase are tested. It's up to programmers to follow sound design principles and techniques to determine where seams should go and their type. Perhaps using, user stories, use cases, CRC cards, data-flow diagrams, sequence diagrams, modeling, etc. Oct 18, 2010 at 15:17
  • @huper, it is my experience that the interfaces get the best when you do the tests first, and the actual code later instead of having to retrofit a working implementation to a new API. That would be a visible seam.
    – user1249
    Oct 18, 2010 at 15:21
  • @Thorbjørn, that last comment doesn't make sense to me. Saying "interfaces get the best when you do the tests first, and the actual code later" seems to be pro-TDD. In a new project there is no working implementation to retrofit to a new API. And please tell me what you consider to be a seam as it seems like we're not in agreement on its definition. Oct 18, 2010 at 15:47
  • 1
    I am accepting this answer, even though the issue is in debate. I do accept that Pseudocodes are better than just writing code without planning. But it can't be practiced as a procedure in a development firm, May be it s fine to let the freshers do the pseudocode first approach, but you can't expect senior people to pseudocode before they start coding...
    – Vimal Raj
    Nov 4, 2010 at 9:30

I use comments as a kind of very high-level pseudo code, in that I write the comments before I write the code. I find that thinking through the entire problem, even at a high level, improves my code considerably.

  • Not to mention it's a great aid for scanning the code later.
    – kubi
    Oct 19, 2010 at 20:57
  • Interesting idea - I hadn't heard of that before. I'll have to try that one.
    – Michael K
    Nov 24, 2010 at 14:59

No, do not pseudo-code first

This is too much overhead. You're doing the work of writing the logic with none of the benefits. I'd suggest any of the following instead:

  1. Prototype in the language you're going to ship with (AKA Write one to throw away)
  2. Architecture diagrams w/ code snippets to test assumptions / key designs
  3. Test Driven Development where you write your interfaces/code structure first, followed by tests, followed by implementing the code.

All three of these move you directly towards your solution, unlike pseudo-code. Personally I tend to use techniques 1 or 2 depending upon team size. For smaller (e.g. 5 people or less) teams, prototyping works very well. For larger teams that have multiple groups of developers working in parallel, I've found that documentation produced early by technique 2 works well because it gives you something to discuss early and helps you define component boundaries better. I'm sure TDD would work very well too, but I have yet to work on a team which had committed to this process.

  • Somebody said "If you write to throw one away, you will throw away two"... I don't know if it is true though.
    – user1249
    Oct 18, 2010 at 15:23
  • I would say the greater risk is that you write one to throw away and end up shipping a prototype. I've certainly heard of a few times that has happened...
    – glenatron
    Oct 19, 2010 at 13:24
  • +1. IMO (2) and (3) will likely give the most value here. Oct 19, 2010 at 20:36
  • BUT, if you code on paper, you can throw it away without the danger of shipping it...
    – Michael K
    Nov 24, 2010 at 15:00
  • "Write one to throw away" violates DRY.
    – StuperUser
    Nov 14, 2011 at 12:15

In my opinion, pseudo-code has only two valid purposes:

(1) For programming students who need to learn the concepts of modularity and algorithms, but aren't yet fluent in a programming language.

(2) To communicate how something will work to a non-technical person, or just for the sake of expediency in a white-board type meeting.


Is pseudo-code a suggested approach? For beginning programmers, I say yes. It helps the new programmer learn how to translate a problem into code without worrying about the exact syntax of the language. This shapes the thought process and can help ingrain useful habits (and I suppose bad habits too). This is why it is used in schools so much.

Is it practiced in industry? In my experience, no. No one has the time to rough out the project between the documentation (requirements, specifications, story boards, use cases or whatever else they use) and the actual code. It is generally assumed that sufficient thought has already been put into the problem prior to the green-light to code. At that point, coding the project is more important than adding one more layer of design preparation.


I would definitely recommend pseudocode. It helps you clarify what you are going to do and identify items you may have forgotten or potential problems. Its far easier/faster to fix your code when it's still in the planning stages rather then waiting until you've already coded a large portion of it.


I'm going to disagree with the previous answers and say no, but with a caveat: you can get rid of psuedocode only if you're feverishly devoted to refactoring your code to deal with issues that crop up. Psuedocode is, at its essence, a way of defining your code before you define your code; it's an unnecessary abstraction in many circumstances, and since your code will never be perfect the first time (and likely, not follow the psuedocode's design to completion), it seems extraneous to me.


If you're writing COBOL or C, pseudocode may be helpful because writing the actual code will take much longer, and if you can verify your algorithm/requirements from the pseudocode, you can save some time.

In more modern languages, pseudocode doesn't make as much sense. What would work better is writing method stubs, and filling out the top level logic, and as much detail as necessary to verify the algorithm and requirements, all of this in actual code. You can then show that code to the Team Lead for approval, and have your real code already started.


The only times I've used pseudocode in the last 10 years are on interview when we're working on a whiteboard and the particular language doesn't matter.

It's certainly helpful for talking through a process/algorithm in loose terms without getting bogged down with syntax. E.g. writing a C++ class which has C# properties, just to illustrate the point.

It has its' place, but should only be used where needed (it's work that you'll throw away) and certainly not part of a formal process, unless you have ISO-type standards that insist on it.


Pseudocode can be useful if you're unfamiliar with the language, or if you need to change mental contexts. On the rare occasion that I write pseudocode, it's on paper. Sometimes just taking your hands off the keyboard and scribbling on paper can help get around a mental block.

But as a formalised part of the development process? No way. It's a sporadically helpful tool for individuals. There are better ways to "know what you're writing before you write it", like:

  1. defining the contract (pre/post/invariant conditions) of the method before you start
  2. TDD
  3. 1 and 2 combined (writing tests to execute the contract)

I'd also suggest that getting any sort of approval before you start writing code is likely to cause much more hassle than it's worth. Design reviews (pre-implementation) can be useful, but they need to be at a higher level than individual algorithms.

  • +1 for saying it's helpful for individuals, not as a process.
    – Michael K
    Nov 24, 2010 at 15:04

For myself and the people I have worked with for the last few years pseudocode has pretty much turned into not entirely perfect real code. unless you work with many languages at the same time, most people seem to start thinking in the general pattern of their main language. I have worked in .net shops for a while so most people's whiteboard scribbles around the office tend to look like vb or c# with some of the punctuation missing.

The exercise is still valuable when debating options and such, but the language agnostic bit tends to drift away as you spend more time with a few languages.

  • Of course it will. I don't think that matters, though. I see the value in being able to concentrate on the logic flow rather than the semantics of your language. You don't have a compiler checking you pseudocode!
    – Michael K
    Nov 24, 2010 at 15:02
  • It certainly doesn't matter to me, but I have had people on my team that insist it is acceptable to put things in the pseudocode step that has no realistic/efficient/safe implementation in the languages we use. I find that problematic. I can agree in a theoretical sense, but I work in enterprise, we aren't going to switch languages just to get a feature or two, so I would much rather keep it close to the intended implementation.
    – Bill
    Dec 9, 2010 at 18:28

More and more, pseudocode is written graphically with tools like UML. For instance, try out yUML.

an online tool for creating and publishing simple UML diagrams. It's makes it really easy for you to:

  • Embed UML diagrams in blogs, emails and wikis.
  • Post UML diagrams in forums and blog comments.
  • Use directly within your web based bug tracking tool.
  • Copy and paste UML diagrams into MS Word documents and Powerpoint presentations...

...yUML saves you time. It's designed to for those that like to create small UML diagrams and sketches.

Without yUML, creating a UML diagram might involve loading up a UML tool, creating a diagram, giving it a name, fiddling with layout, exporting it to bitmap, and then uploading it online somewhere. yUML doesn't make you do any of that...


Great work. You started a good discussion. As of me, I used to write pseudo codes when I was learning programming to understand the various loops and algorithms. This was more then one and half decades ago. That days, even programming languages were not much powerful... and event driven programming was future. Now with 4GLs and 5GLs, we think in the language itself rather then in plain English. When we think of a problem, we think in terms of objects and operations. And until it is a complex algo, writing pseudo codes (or P-S-E-U-DO-Codes, just kidding) does not make any sense. Better, represent the solution in a graphic way.


This is not a yes/no kind of question. Rather, one should wonder when to use pseudo-code. It is important to understand the problem before designing a solution, and it is important to have a clear view of the solution before you implement it. Pseudo-code can be used in any of these steps:

  1. When defining the problem, it's common to write down use cases, sometimes using sequences of actions.
  2. When designing a solution. Class diagrams are nice, but they only describe the "static" part, i.e. the data. For the dynamic part, as soon as you need to deal with a loop and non-trivial data, I find pseudo-code to be the best method available. Graphical alternatives include state machines (good for complex control flow with little data) and dataflow diagrams (good for simple flows with complex data).
  3. When implementing the solution (or just before). Some programming languages are hard to read (think, assembly). An alternative representation can be valuable in this case. If you are unfamiliar with the languages, it's also worth doing.

Pseudo-code that's actually proper code in a high-level language is also used, it's usually called prototyping.

In addition to achieving understanding, pseudo-code is also good for communication.

If you are wondering if you should use pseudo-code on a regular basis, I am personally against all kinds of rigid rules. This can easily turn into a boring waste of time if used for trivial problems everybody in the team understands. Using pseudo-code for specifications that you maintain throughout the project's life can also be costly and offer little value.


Depends on the language used, and your familiarity with it.

Many modern languages such as Python or Java are already so close to pseudocode that writing some ad hoc pseudocode first is wasteful, IMHO. Better just do it right away using the tracer bullet approach.

It's a different deal if you're making some low-level, close to metal things, or aren't yet comfortable with the language you're using. Then pseudocode can definitely be useful.


There tend to be a couple circumstances where pseudocode tends to get broken out in my work, which is in academia where programming tends to get used as a tool or the "and now we solve it" filling in the middle of a project:

  1. When the code is going to be more counter-productive to an actual understanding of what's going to happen than pseudo-code will be. SAS for example, will take up half the whiteboard doing some fairly basic programming tasks. See also C, which some other posters have discussed.
  2. With a lot of data analysis and statistics coding, there tends to be a lot of tinkering with the code as results are generated. Pseudocode is somewhat easier to use for "herein lies a back-and-forth process, if the diagnostic plot doesn't look right, try X".
  3. Students learn lots of different programming languages. For example, among people I know, a statistics problem might be analyzed in SAS, R or Stata. Something that requires something closer to traditional programming might be done in R, Matlab, C, C++, Java, Python... it really depends on what particular student is implementing the program, and for what purpose. But it's still useful for the Java people and the Python people and the Matlab people to have a joint idea of what the others are doing, and how the approach, rather than the code itself, works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.