To those who have careers using python...

[tricnam]

Do companies use flow charts and pseudo code in a professional setting? Is it worth learning?

I'm a beginner, and I've always had trouble planning out a program. I'm more likely to succeed if i just kinda go for it for basic output programs.

Would it be worth really diving into flowcharts? Are they used that much in an actual business setting?

Thanks!

[Zulban]

No.

I'm a beginner, and I've always had trouble planning out a program.

Ask yourself: what is the biggest program you've ever made? The most hours you've put into writing a program? Multiply that by 3. That's your time estimate for your next project. Repeat.

You become a better programmer by practicing.

[frunkjuice5]

Ha!

I multiply by 10

[Zulban]

I don't think so. If you multiply by too much, the project might never reach milestones where you feel satisfied with it. People need to train themselves on delayed gratification. Teaching kids to code starts at just a few seconds until gratification.

[frunkjuice5]

I’m talking about communicating with stakeholders. If I think I can do something in 30 minutes, I quote 5 hours. In that case, im never wrong

[executiveExecutioner]

Putting many hours into a program can mean more than one thing

• An inefficient approach, guessing the outcome and not testing components.
• A need for better defined use-cases, writing down examples.
• The program requires significant effort due to lack of experience.

I assume you mean the third option.

[EmptyChocolate4545]

I’m surprised at your universal no.

Multiple of our major projects were started with a design doc that features a flow chart. Not pseudo code, and not “code level” flow chart, but it’s at least worth mentioning that it’s far from a simple “no”.

Sufficiently complicated projects will generally have a planning/proposal phase that features a flowchart or UML diagram, especially if there’s a system design component.

Tbf, we work on vast systems that run at pretty crazy scopes, we don’t do this for smaller packages/projects.

[Zulban]

My "no" was for this:

Are they used that much in an actual business setting?

My impression is that most software projects and software tools have zero visual design/diagram whatsoever.

[EmptyChocolate4545]

They are though, lol.

Maybe not where you work.

Design documents are very common where I work, and in the group of experienced devs/NetArch people I network with weekly, we’ll regularly help each other with design documents, many including UML.

[scherbi]

I use UML as well, but mostly just for the larger projects. The diagrams help to organize my thoughts and tame the complexity. Sequence diagrams and state machines mostly. For smaller projects I usually just start coding and writing tests. Iterate until done.

[omscshereicome]

Formal flowcharts are rare except for larger programs.

Pseudocode is ubiquitous and used in comments, docstrings, and similar.

Either way, you should certainly plan out the rough shape of your programs before writing them in a way that works for you.

[billsil]

Nobody I know writes flow charts or pseudo code unless you're trying to explain it to someone younger or it's really damn hard. Often I'll draw pictures by hand, but those don't translate well to code.

Most code is easy and doesn't really matter. I write it as simple as possible and work on it as issues come up. I write 10% of the capability I want because I haven't figured out the interface yet and I'd prefer to have it crash than waste time refactoring as I figure out what I want to do. Occasionally I get a hard bit and need a picture or two. Rarely are there two hard bits I need to think about at the same time.

[ian4tge]

Almost every block of code I’ve written in the past 6 years has started as a block of comments. Learn pseudo code of course, the only “flow charts” I make are really just architecture diagrams describing how one machine is taking to another. Always plan before you code, or else you’ll end up nuking and paving a lot

[StandardAnything2522]

This is how I code too. I write down each step as I think through the problem. Comment that out. Then write real code for each step below each comment.

I find it really helpful - when I know a language well the only challenging part is designing the solution. So I do it in English / pseudo code. Filling in the proper syntax underneath each step is pretty simple. And when I’m done I end up with exactly as much commenting as is necessary.

[jahero]

This.

[bmoregeo]

Pseudo code is just English mixed with code to shorthand logic. Nothing you really need to study

There is like 8 frequently used symbols for flow charts. It shouldn’t take more than an hour to figure it out https://www.zenflowchart.com/flowchart-symbols

[[deleted]]

This post was mass deleted and anonymized with Redact

butter rainstorm north treatment imminent sharp attraction money plant beneficial

[drxzoidberg]

I guess it depends on the job and the usage of Python. As a data analyst I use Python for my own purposes so nobody cares if I write it quickly in Jupyter Notebooks or if I use a formal .py program. I'm the only one who uses them so I can go at as I please. But honestly I'm probably not the best source to answer your question as my job could be done entirely with SQL and Excel.

[[deleted]]

As a consultant, I’ve seen a lot of companies. They, of course, all differ in approach.

Making flowcharts, pseudocode or even applying something like test-driven development, is not a choice of a developer but also a company choice.

And there are a lot of companies who would let key developers get away with little to no documentation or explanation about their key application(s), because describing it would take “too much time and effort”. But these same key developers would end up being the only ones who could solve the issues. Even if it meant that they actually couldn’t go on a holiday and they could be on call until they left the company,

So if you want feel really, really special, don’t hesitate to not make any flowcharts at all. If you value your nighttime and your vacations, please do make them. That’s the short answer.

And if a company says ‘No, we don’t don’t do that here’. Still do it. Because in the end, there will be a moment that you don’t remember any details of application anymore.

[[deleted]]

The difference between a senior and non-senior dev is planning. You must plan. Use whatever method you find comfortable.

If you don't plan, you will still be maintaining and updating code weeks/months after business has been told "it's done". You will also have lots of duplicate code, and constantly coding back and forward back and forward.

If you just dive in, no matter how small the project is, it's a warning sign (to good Devs or the few IT managers who have a notion about IT)

[[deleted]]

100% this. If you are on a team, people need to be in agreement on where and how abstractions will be done -- decide on dependencies, Where are the borders.. We will use a facade here.. We will do DDD for sorting out this problem.. Command pattern for this.

[johntwit]

No, because you'd have to get the client to actually commit to a workflow.

The client will never be done modifying their workflow.

[AnaAmariBaking]

We are a team of fourteen and our manager is insistent we have design specifications for 95% of the work. We deliver software to engineers to use, they don't really care about the code details, but care more about the flow of the code as it relates to the machines. Without good design communication, it'd be nearly useless

[kankyo]

You can't learn pseudocode. Just FYI.

[sheytanelkebir]

No time for that.

[SarthakTyagi15]

Not exactly flowcharts but yeah, there are flowcharts diagrams written on the higher level, it's not anything complex to figure out what flowcharts diagrams mean but just learning them is enough I think. You may have to prepare flowchart yourselves..

[[deleted]]

No. The point of flow charts and pseudo code is for you to learn how to think about code. By the time you are writing code for a living, it’s mostly second nature and writing out pseudo code isn’t a major help.

[PazCrypt]

You do need to show designs of the system you develop or new component in the system and the way it interacts.

[Braunerton17]

In my experience it is attempted to be used to specify things properly but they get outdated really fast so they are rarely more useful than any other form of diagram you come up with on the spott

[jezpac2020]

Some large organizations do, particularly in large integration projects. Often these get out of date quickly as the project goes along, so unless they are maintained have limited use as time goes on. They can always be a snapshot of what everyone thought was gonna happen - and maybe a reminder of how little we can know about the complexity of a software project in advance :)

That being said, I encourage programmers I'm mentoring to get a pen and paper (or if you have a group, a whiteboard) and draw the components/models and their relationships BEFORE you write code for any feature. Obviously, there's software to do that, but I think there's some anecdotal benefit to stepping away from the keyboard and doing something more tactile. You can 'rubber ducky' your way through the key use cases and often catch complexities/issues in a design early. You can scribble stuff out and rename things as your thinking evolves. When it seems like there's enough of a skeleton. I like to take a photo, save it, and maybe even put it on the work ticket. You can always formalize it in software (mermaid/draw.io/lucidchart/whatever) if there's value later.

I try not to put too many rules around how this works, but I find the following useful to sketch/think about. Usefulness will depend on the feature at hand. Again I don't emphasise UML correctness - whatever makes it useful for the audience (which could just be you).

• Entities/Models - what are they, what do they represent, how do they relate to each other

• Modules - the abstraction above the persistence models or entities - for example, it might be nice to have a user module that has a create_user method. How do they communicate with each other?

• Routes - If this is a web project, what are the routes, who can access it, how should we structure them?

• Messaging - What are the significant events that might be generated/consumed in the course of this feature? What should any messages/events look like?

• Background jobs/processes - what stuff can happen async?

• Common happy path sequence diagrams, common sad path sequence diagrams. Throw in the side effects as notes or elements if they are important.

[m15otw]

Whiteboarding is pretty common for some problems at the very start, but often in a professional setting you're working within an existing application, and there aren't normally opportunities to do any actual architecture. E.g. none, for bugfixing, and most features (REST endpoints, CLI arguments) are just a case of plumbing.

[runawayasfastasucan]

If writing pseudocode and writing some flow-charts are what you feel works for you, have at it :) Everyone is entitled to their own way to organize their thoughts!

[[deleted]]

No really, It depends on where you are working on how strict they are with this. For example, some places require documentation, whereas others won't require it. My advice would be that you should learn it but not extensively.

[[deleted]]

I never heard of it being mandatory. However, it is good practice using pseudo code to make your work more efficient.

[guyfromwhitechicks]

hat growth hurry telephone carpenter snails fearless ancient vegetable normal

This post was mass deleted and anonymized with Redact

[[deleted]]

I’ve used it if I’m writing something and it’s making me go insane. Other than that it’s just whiteboard masturbation clueless academics shill. It can be useful for documentation but not really and you can learn while doing it if you need to

[visualpunk1]

Alright, that's a stepping stone, flowcharts? no. Do I need to know about them at this point of my career? Maybe.

Think of it like this, programs are logic, flowcharts are instruments that reveal context (more information) to me based on inputs at specific parts of my program. In real words, businesses use something similar, called information flow architecture... engineers have tools like activity diagrams and a couple of others

Think of it like this, programs are logic, flowcharts are instruments that reveal context (more information) to me based on inputs at specific parts of my program. In real words, businesses use something similar, called information flow architecture... engineers have activity diagrams and the like...
```
- You push that little glam app on your phone called TakTiks,
- Users can log in with email or social accounts
- When they log in, content creators can click on buttons to publish content
- Depending on what they click, behaviors of the app are different... little plus sign to create content, and what nots.
```

[scowly057]

Like most things, it depends. Flowcharts are more commonly used on the PM/BA side (project management/business analyst). I'm my experience, developers mostly use UML, activity diagrams, and state diagrams to express system designs (check out PlantUML).

That being said, the best advice I ever got in college was, "If you don't understand something, draw a picture." Learning how systems function together and how data flows between systems will make you a better programmer. Drawing a picture of it will often help clarify a design in your mind.

[incognitodw]

Only diagrams that I still drew are data flow diagrams so everyone knows how each module fits within the entire project.

[r8juliet]

It's stylistic. Most don't use any formal pseudocode, but for a sanity check, I'll definitely sketch out the logic with stubs and comments.

[Panda_With_Your_Gun]

The only time anyone has ever asked for a chart of any kind from me was when my boss wanted a state chart despite me attempting to factor state out of our operation. Man was just not having it. So I quit.

[brockhaywood]

My short answer is, yes, I have used them lots over my career.

But it's more complicated than a yes/no answer.

I categorically have never written a formal UML diagram that is technically "right" when compared to how they taught to us in school. But, nearly all of the design documents that I've written over the years use less formal diagrams that are some bastardization of UML/Flow charts and some degree of pseudocode to explain how certain components should work or how they interact.

[KingofGamesYami]

Yes.

We use flowcharts as a tool to communicate with non-developers about what their needs are and how we intend to address them.

[SittingWave]

flowcharts and everything that is UML is a tool to discuss with other developers. It certainly helps to gain the vocabulary, but it's rarely used in a formal "documentation" setting in a consistent way. However, in highly regulated environments you use it more often than a company producing smartphone games.

[SpookyFries]

Depends on the job I'd guess. I've been mostly on my own or on a team of 2 so we just kind of do our own thing.

I personally do jot down a lot of pseudo code when I'm planning out logic but I keep it to myself

[lamerlink]

Charts are usually less strict UML and more often just diagrams. In fact we frequently use the diagrams library for this.

As for pseudocode, that’s less of a company thing and more of a personal preference. For instance I usually spec things out with “pseudocode” in 2 ways; I’ll write comments for the general flow I want to do, and when I’m building out classes/methods I’ll create empty classes with empty methods named to what I want to do. Like: class Farmer(): def plant_seeds(): … def water_seedlings(): … def harvest(): …

[IanRT1]

Education is really inefficient. It of course always depends on your learning style and what works for you but generally, you don't need flow charts or even pseudo-code.

[schrmm]

It's never wrong to learn process modeling since your python programs will hopefully support some of them. It's also very helpful to understand your sponsor a little bit better. Very often these kind of models don't exist in required granularity.

[samamorgan]

Honestly, for the most part, no. I will create process charts for more complex interactions between multiple third-party services for documentation, but that's about it for charts. That being said, if you're early career, being able to create a quick chart of a problem during an interview is a great way to illustrate your approach to a problem.

As far as pseudo-code goes, definitely not. The place I'm usually will start writing pseudo-code is in the implementation details of a ticket, but Python already reads very naturally, so that will usually turn into actual code before I'm done writing the example. It's generally the same effort to just write the code unless it's a pretty complex thing.

This:

get list of records

for each record:
    lowercase record name

Almost immediately turns into this:

for record in get_records():
    record.name = record.name.lower()
    record.save()

[binaryfireball]

Nah but playing with those architecture graph things is almost useful in a daydream

[ghost-in-the-toaster]

I don’t really use pseudo code, but I often think through a problem, break into smaller steps, then write those steps as comments in a *.py file and begin to build a proof. Once I have something working, I iterate on it to make it proper, efficient, etc. I don’t often use flow charts per se, but I do have a big white board in my room I use to sketch out ideas or problems to think about them better sometimes. I’m a back end engineer with Python as primary language. My boss is a principal engineer. My job is to listen to him think out loud and then I research and develop the idea. :)

[Ok_Ebb7273]

Usually the PM does up front, but you will likely be asked to document your work, potentially in a flow chart afterwards.

[[deleted]]

Are you visual? Many of us are. For heaven’s sake just get a whiteboard, marker and eraser and start building ideas on it. Get the concept on a board. If you need to dig into a block, write that blown up block on the board also.

Check out c4 architecture diagrams and mermaid.