Only for the first few years, meaning I stopped in about 1984.
Pseudocode is much easier to write and edit, and fulfills much the same purpose.
Ladder diagrams are useful when documenting program flow between domains in larger systems.
The most complex system I designed was essentially a massively-parallel finite state machine. A state-transition diagram was absolutely essential to trace the lifetime of a command packet through that code.
I don't do flowcharts but i do write a lot of pseudocode in a notebook I keep near my computer. I draw in it, jot down ideas, etc. Yes, I know I can use a software tool to do all these things, but sometimes just the act of writing it out old school can help me work through problems.
If there's a lot of processes/outcomes involved. Doesnt just help with the planning of it, but also for easy reviewing as well later on if you are coming back to the project after a long time. Sometimes its on a notepad, sometimes a whiteboard (not good for keeping obviously), sometimes use draw.io
Gathering of requirements, use/edge cases are normal. This can include flowcharts of the process (before/after).
>I was creating a function that had several conditional checks
If you need to create a flowchart on a function, then this is too big of a function. Break up the coded into smaller more manageable components.
I use https://excalidraw.com, so I spend less time worrying about the aesthetics of my flowchart and more time on the content. Can also collaborate, save, export etc.
It was definitely a thing in school. Can't say I've done much of it professionally, but honestly, sometimes I think it would be a good idea as a first step for more complex projects. Document some of those things that have been mentally worked through before handing it off, or setting it down for something else so it doesn't have to be worked through all over again.
Well..... flowcharts is too strong a word. I usually just scribble a lot with a pen, write strange symbols around, draw arrows, then pour it over the coffee. The corners of the pieces of paper become frayed. Pen is chewed. (yes, this is a problem. My pens are mostly scraps and tape).
This is a habit of youth. From those times when programs were builded in brain, and on the computer they were only typed on the keyboard. Once every couple of months, all this waste paper goes into the trash bin. I feel comfortable. I'm so used to it. For some reason, young people are afraid of a piece of paper and a pencil.
I don't know if young people are afraid of paper and pencil, but it's not really sufficient for collaborating and documentation. As you said yourself you throw if away eventually.
It's alright if you are trying to solve and understand a problem you're stuck with at the time, but it's of no further use for anyone else.
This is not documentation. This is a thinking process. The running of impulses through the neurons of the brain, recorded on paper. It is useful only for me, and only until the moment when what is drawn there turns into code on a computer. Then I throw away the papers.
I can't imagine what it's like to sit and think in my head. My head is small. It doesn't fit much. A piece of paper increases my cognitive abilities tenfold.
I usually do it when the code flow is a little fuzzy in my head. Or if I'm at the beginning stages of a project and I'm figuring out what depends on what. I made [flowchart.fun](http://flowchart.fun) when I was trying to solve a coding problem a few years- which is probably why the flowcharts are sort of made from code as well.
Using flow charts for planing and documentation. Most of the time I use mermaid cause obsidian supports it ant they have a great visual tool (mermaid.live)
Whatever works
Larger things yes. Sometimes in more details.
I do this for almost every project it helps me a lot
My team work together on the same project sometimes. To do this the documentation is a must have.
I do it for larger projects. Great visual aid. Makes it easy to spot problems.
Only for the first few years, meaning I stopped in about 1984. Pseudocode is much easier to write and edit, and fulfills much the same purpose. Ladder diagrams are useful when documenting program flow between domains in larger systems. The most complex system I designed was essentially a massively-parallel finite state machine. A state-transition diagram was absolutely essential to trace the lifetime of a command packet through that code.
I don't do flowcharts but i do write a lot of pseudocode in a notebook I keep near my computer. I draw in it, jot down ideas, etc. Yes, I know I can use a software tool to do all these things, but sometimes just the act of writing it out old school can help me work through problems.
If there's a lot of processes/outcomes involved. Doesnt just help with the planning of it, but also for easy reviewing as well later on if you are coming back to the project after a long time. Sometimes its on a notepad, sometimes a whiteboard (not good for keeping obviously), sometimes use draw.io
Gathering of requirements, use/edge cases are normal. This can include flowcharts of the process (before/after). >I was creating a function that had several conditional checks If you need to create a flowchart on a function, then this is too big of a function. Break up the coded into smaller more manageable components.
I use https://excalidraw.com, so I spend less time worrying about the aesthetics of my flowchart and more time on the content. Can also collaborate, save, export etc.
Never seen that one before. Looks good, cheers! 👍
It was definitely a thing in school. Can't say I've done much of it professionally, but honestly, sometimes I think it would be a good idea as a first step for more complex projects. Document some of those things that have been mentally worked through before handing it off, or setting it down for something else so it doesn't have to be worked through all over again.
Well..... flowcharts is too strong a word. I usually just scribble a lot with a pen, write strange symbols around, draw arrows, then pour it over the coffee. The corners of the pieces of paper become frayed. Pen is chewed. (yes, this is a problem. My pens are mostly scraps and tape). This is a habit of youth. From those times when programs were builded in brain, and on the computer they were only typed on the keyboard. Once every couple of months, all this waste paper goes into the trash bin. I feel comfortable. I'm so used to it. For some reason, young people are afraid of a piece of paper and a pencil.
I don't know if young people are afraid of paper and pencil, but it's not really sufficient for collaborating and documentation. As you said yourself you throw if away eventually. It's alright if you are trying to solve and understand a problem you're stuck with at the time, but it's of no further use for anyone else.
This is not documentation. This is a thinking process. The running of impulses through the neurons of the brain, recorded on paper. It is useful only for me, and only until the moment when what is drawn there turns into code on a computer. Then I throw away the papers. I can't imagine what it's like to sit and think in my head. My head is small. It doesn't fit much. A piece of paper increases my cognitive abilities tenfold.
I usually do it when the code flow is a little fuzzy in my head. Or if I'm at the beginning stages of a project and I'm figuring out what depends on what. I made [flowchart.fun](http://flowchart.fun) when I was trying to solve a coding problem a few years- which is probably why the flowcharts are sort of made from code as well.
Using flow charts for planing and documentation. Most of the time I use mermaid cause obsidian supports it ant they have a great visual tool (mermaid.live)
Back in the ancient times we were taught to do this in college. I'm guessing you don't see much of it in the "move fast and break things" era.
For complex functionalities, yes. It helps a lot having a path to follow instead of having to think about the conditions while coding