Do you ever create flowcharts or psuedocode for your own reference?
Posted by New_Independent5819@reddit | ExperiencedDevs | View on Reddit | 29 comments
Personally I tend to just start coding. The closest I come to psuedocode is writing out requirements in a ticket. Product tends to make the flow charts in my experience, and those seem to be most helpful for understanding how various systems outside of my scope are going to interact in a given flow.
I feel like when I was in school they made it sound like we were going to be writing psuedocode and making flow charts before every task, but after a decade in this career I’ve mostly only seen flow charts come from managers and psuedocode maybe used to explain something in a slack thread but not as a planning tool.
Particular_Ad_644@reddit
Sequence diagrams were useful for me to understand object/oriented programming flows. I liked using draw.io for creating architectural context diagrams
yolk_sac_placenta@reddit
I tend to write the goal or behavior first. This is usually client code, a test or docs first. In other words I articulate the end goal as if it already exists.
For planning things out, a lot of sequence diagrams but none of the other stuff.
throwaway0134hdj@reddit
Flowchart is basically the chart version of code so yes I do sometimes
shozzlez@reddit
Nah. Ain’t nobody got time for that.
cstopher89@reddit
All the time. Its the best way to convey an idea and talk about it with clarity. As the saying goes a picture is worth a thousand words. As I get further in my career I find them more and more useful. Especially when you have to be concerned about a very large scope that can't possibly be understood without. Hell I even use them to clarify dependency chaind when they get a little to long to keep in mind. I want all my mental energy going toward the problem at hand not trying to keep a mental house of cards stacked neatly.
poralexc@reddit
I'm always using plantuml for pictures, but usually for showing multiple layers of a complex system rather than flowcharts of implementations.
SeriousDabbler@reddit
Yeah especially once I've exhausted my 5-7 chunks of information. At that point it's good to write something down. Usually a block diagram. I like draw.io
janiejestem@reddit
Came into programming with physics/math background - tend to have a whiteboard with equations, flowcharts and pseudocode on it... usually i only start coding once i'm certain to have the solution.
TLDR - yes, all the time.
New_Independent5819@reddit (OP)
Out of curiosity, what kind of coding are you doing? For me that would be huge overkill for most of my day to day tasks unless I’m planning a new feature
janiejestem@reddit
Currently cryptography related, and a little ai integration on the side.
I agree, it's overkill most often - unless the docs were there from the beginning and kept up in shape.
As mentioned in other comments here - when dealing with the mess of others it's also really useful - feeding into my habit...
...also i think, it might be language related - when i type out a quick prototype in python i tend to do it sloppy, or don't even do it if logics are not confusing myself too much - but when writing rust for example i really like to minimise the time i spend fighting the borrow checker.
OdeeSS@reddit
I white code comments to represent the methods and code I want to write and then slowly fill it in. Helps me plot the flow of my code and change it
okayifimust@reddit
Pseudocode is the worst idea in the history of computers.
If you're even the tiniest bit competent, just write code. You'll have to write it eventually, anyway, and raising pseudo code isn't easier than reading code, either.
(Real pseudocode that is, some shorthand might be useful in some cases)
Flowcharts are great for the visually minded, and they hide the nitty gritty details, or entire layers of implementation.
Most of what we see are fairly well defined tickets, and they have fairly limited scope. They usually don't need much planning, much less any amount of planning where flow charts or pseudo code might come in handy.
Big new process, something that spans multiple systems, or something that needs to be understood by non-devs? I will absolutely draw up a chart.
A single, straight forward endpoint, or an entire controller that does nothing that is not completely linear in nature? I'll code that top to bottom.
nfigo@reddit
I've done it when I had to figure out how someone else's system worked, and it was too complex for me to keep it in my head.
It helps when you have to clean up or work with someone else's mess.
New_Independent5819@reddit (OP)
I wish I’d considered that early in my career.
My first dev job was on a project that had been customized for 50 different clients over the course of 20 years. Every time they customized for a new client, they would copy the entire directory into a new repo and make customizations from there. And all 50 repos were stored on the laptop of some guy who left 10 years ago that sits on the cubicle he used to occupy. And mind you these weren’t even git repos. They were StarTeam. My job was breaking the customizations out of each one into their own repos that used a core library.
I’ve still never seen a bigger mess and I hope I never do. Almost decided this industry was not for me lol
JuanGaKe@reddit
Thanks for this. For each time I've been told "perhaps you could go faster if just copy that directory and customize the things they're asking for", and said: yeah but that will bite us someday. Indeed is a bit longer the path of crafting some options-system along a core library.
nfigo@reddit
Majestic
elperroborrachotoo@reddit
Yes, because if I'm the only one to understand this code, I'll be chained to it for eternity.
LargeSale8354@reddit
Sometimes as a rough guide, often as documentation
dystopiadattopia@reddit
Depends on the task, but the longer I've been doing this, I find that I tend to write a rough draft only good enough to confirm that I'm on the right track. And then I go on from there.
mxldevs@reddit
I always write down pseudocode, or some brief explanation of what my implementation strategy is going to be.
If the code requires me to write more than one function, I will almost definitely be writing out a rough map.
This isn't just for myself, but for anyone else reading the ticket.
It seems the main difference is you have other people working on specifications. I'm just given a problem and I'm the one coming up with the technical specifications.
Whitchorence@reddit
I scribble notes on a notepad sometimes.
roger_ducky@reddit
Funny thing.
All code I write at higher than the lowest level looks like pseudocode.
That’s how you tell it’s maintainable code, since “looking like pseudocode” documents your intent to the maintainer.
MissinqLink@reddit
I don’t pseudo code but I sometimes write something in JS first because it is super forgiving and easy before trying to implement in a language better suited for the job.
davy_jones_locket@reddit
All the time.
I use flow charts to make sure EVERYONE knows the context, whether they're writing code or not. PMs can understand it. QA understands it. Junior developers can understand it. It's a great tool.
Psuedo code mostly when I'm doing interfaces to figure out how I want contracts and stuff before I implement it
SansSariph@reddit
I find the most value in writing out interfaces so I can prove to myself how they mesh together and where I need more data encapsulation. The "pseudocode" ends up being more English descriptions of contracts that becomes documentation.
I do mostly system design work now though and find traditional pseudocode more useful if I'm stuck on a hairy algorithm problem.
TastyToad@reddit
I don't do diagrams, I do lists. I split the task into smaller chunks, write down things to double check or test and questions I have as I go. No lose ends, if I can think about something it will be handled one way or another.
In my opinion flowcharts and pseudocode are somewhat useful at the early stages of the career. They are there to help you refocus from the minor details of implementation to the higher level thinking (control and data flows, component interactions etc.). Once you train yourself to do that in your head they bring very little value in day to day work.
The only exceptions I can think of are: - architecture diagrams (non-specific as I don't follow C4 or UML or any other formal system here) - useful in documenting how different parts of the complex system interact with each other, come in handy once you're past 3 or 4 independent subsystems - sequence diagrams - help with understanding asynchronous interactions and possible failure modes - state machine diagrams - for one of those once in a decade cases when you have to implement an actual non-trivial state machine
Noobsauce9001@reddit
For myself I'd only do so if it's so complicated I need to think it through- and that's often a matter of "I haven't tackled this kind of problem before, so it's a learning experience for me".
Otherwise I'll just leave some placeholder functions/TODO comments to scrap things out if I need to. I work in frontend for reference,
New_Independent5819@reddit (OP)
That makes sense. Thats kind of what led to me making this post.
I’ve been working on some embedded personal projects that interact with mechanical moving parts or HVAC, and the flows get pretty complex and have the potential to break sometimes-expensive physical objects (and some real-word safety hazards) if certain conditions aren’t considered. This had me thinking about making some flow charts.
My career has been backend web dev, so I don’t normally have such concerns at work lol
Noobsauce9001@reddit
It's sorta unrelated but I have recently been getting into flow charts for non-dev projects. Specifically, some cosplay projects I've been working on:
Ex: Runescape cosplay I made https://miro.com/app/board/uXjVOrKJECo=/?share_link_id=624637112431
(You can see my finished result here: https://www.reddit.com/r/2007scape/comments/1ohif5f/foam3d_printed_cosplay_for_the_renfaire/ )
The underlying idea is the same - it's a way of helping me capture all the information involved at once, merely to help me "get it" more.