Ask HN: How did you learn to draw diagrams?

Great question. I can’t recall any standards around this topic, and iirc it came down to common practices. I read a couple of texts to build some fundamental knowledge that I could say I had a reference for.

Now I can pass it on to you.

Had to open up my Apple Books library to find these again, but:

TECHNIQUES OF FLOW-CHARTING Louis A. Schultheiss

IBM Data Processing Techniques Flowcharting Techniques

I pulled these down from some searches on UML diagramming some few months ago since I needed to diagram some envelope encryption work for a team with a previous employer.

The UML-generated code thing is prior to my time, but basic flowcharting techniques on their own are a nice to have skill.

You don’t need to memorize endless shapes, but a few common ones like those in the texts above will convey almost everything you’ll care about day-to-day.

In my experience, this isn’t a skill you have to exercise often, but if you can do it without being overly sophisticated, some people may appreciate having a diagram now and again for large systems, or involved processes.

Sorry, I guess it's been just long enough for me to forget this stuff. I'm wrong! I forgot. There are standard symbols for flowchart diagramming. Honestly the Wikipedia article on it will cover just about everything you'll want to know.

[1]: https://en.wikipedia.org/wiki/Flowchart

[2]: Flowcharting Techniques GC20-8152-1. IBM. March 1970.

[3]: Schultheiss, Louis A., and Edward M. Heiliger. "Techniques of flow-charting." (1963); with introduction by Edward Heiliger.

I like C4 for system design overview and sequence diagrams to show detailed process of interactions in one particular scenario. I found these two the most useful for me.

I also like to write diagrams as code with https://plantuml.com/sequence-diagram cause you can then add it to git and easily version it. Also, a lot of tools on the market have support for PlantUML

swimlanes.io and Mermaid (https://mermaid-js.github.io/mermaid-live-editor/edit) are other 'diagrams as code' options.

Some tips:

- start on paper (or something analog like a whiteboard)

- focus on the essence of what you want to convey, the big picture of you will, not all the detail. Focus on what you want the audience to remember. Less is more

- iterate. If you see your audience isn’t grasping what you convey, you’re not clear. Edit

- draw real time as you explain, which allows you to draw based on audience understanding and what you want to focus on

>draw real time as you explain, which allows you to draw based on audience understanding and what you want to focus on

i am shocked at how little this occurred at the last FAANG i worked at. when i got on a group meeting, and an engineer would start describing a process or system i would start diagramming in the background. when they finished i would pull up my drawing and ask if we missed anything. the answer was usually yes and we would collaborate as we extended the diagram. if i am 1-1 with an engineer and they say they don't understand something, i would break out the drawing tools and explain it as i draw the diagram. 9/10 times the engineer leaves with a great understanding of the problem and is empowered to solve/build/explore further.

i do not understand when an engineer says "i cannot picture the diagram and therefore i cannot draw it". especially when the engineer is senior or above. communication becomes key and when it comes to diagrams, a picture is worth 1000 words.

I like to use excalidraw and do the same in our Consultancy, al my colleagues try to endlessly explain complex situations and as they go i would draw it out and it makes things a lot more clear.

Excalidraw is especially useful because of the 'rougness' you dont have the tendency to line everything up perfectly.

That said i had the same question since i sometimes add too much detail in diagrams and would love to up my skills here.

Went with excalidraw pro recently for convenience but the free version lets you do everything the same export you will have to save locally.

I'm old school, Visio was been the gold standard for so long that I still use it. Draw.io/Diagrams.net provides a good enough solution that that has been my goto lately.

I don't think there is any problem with too much detail, you can always "dumb it down" for your target audience. I regularly work on the super big detailed picture diagram and export relevant parts to other pages as the audience demands. If i'm in an engineering design meeting, we are looking at that big detail. If I am working with release team, then we probably are only looking at high level components. Likewise the DB team may want the detailed view of migrations. To get those smaller diagrams its just a bunch of command-clicking and copy/pasting to a new sheet!

Also as a side note, at least with Visio, you can throw some python at the file to read/write your own diagrams. While I never automated the detailing aspect, I have programmatically created visio rack diagrams from excel spreadsheets

> draw real time as you explain, which allows you to draw based on audience understanding and what you want to focus on

This is critical. While I took formal flow charting and diagramming in college, it can’t replace real time diagramming as you explain.

When I was in consulting, we would often project Visio diagrams on a whiteboard and then extend them using markers. As we moved through the explanation process. My Visio jockey would the transcribe the whiteboard notation to Visio diagrams once we all agreed on the approach. This allowed us to collaborate with the flexibility of a whiteboard while confirming and capturing the final documentation as we went.

(The C4 model)[https://c4model.com/] is a nice way to capture (IMO) the most important characteristics of a system, and you can learn it in half an hour. Optionally, you can add state transition and sequence diagrams for selected parts of the code.

One important thing to take in consideration is that diagrams are not blueprints. What they don't represent is as important as what they include. That's why I like C4: it's limited to answer an important but small subset of questions about your system.

I just gotta say... for a system that's supposed to diagram complexity, the website does not do a very good job of conveying how it actually works. It's like ten pages of super dense text in a weird layout that's incredibly hard to follow =/ I think this front page alone is 10x more complex than any of the diagrams I've had to make, lol.

Are there some example output diagrams that are easy enough for any stakeholder to read and understand, or do they have to read this website first before being able to consume a diagram created in this system?

Practice by trying to explain things in meetings or make sense of things. Started with MS Paint and drew terrible (but effective) images for years live in meetings. Later moved onto Visio but I still like Paint sometimes.

Learning specialist diagram types like basics of Fault trees has been really useful in some situations.

> it would be nice to produce more expressive diagrams to convey more complex ideas

Focus on your reader. It does no good to create an "expressive diagram" if it's too complex for anyone else to understand it.

Good intro to using UML effectively: http://agilemodeling.com/essays/umlDiagrams.htm

Drawing is the simplest way to get better at drawing.

Redrawing is the simplest way to refine a drawing.

The traditional way to do this is with tracing paper and overlaying sheets.

And letting the first attempt suck…and the second..and the…well the next thing is always more drawing.

Not that books aren’t good, it is that mostly you’ll be just nodding along instead of doing the hard work of drawing.

Good luck.

This may be true when you're drawing for artistic purposes, but lacks the feedback loop necessary when you're trying to diagram for the purpose of explaining things clearly to others. If I'm trying to draw a horse, I can compare my finished results to a photo of a horse and see how accurate it is. It's an easy feedback loop. But for you to learn if your diagram has adequately served its purpose, you have to ask other people for their feedback.

Just doing something to get better at it only really works if you can evaluate where you're deviating from your goals and make corrections along the way to account for that and get better. You could draw diagrams for decades of your life in isolation and still not be able to convey meaning through them.

Sorry for not being clear.

I intended not suggest anything about isolation or not showing in progress work or diagramming as bliss ninny pursuit.

But rather as hard work and discipline mostly rewarded by more hard work and discipline.

Probably over years. Over years because that’s the time scale of skills picked up in a career.

On the other hand, there’s not much point in doing anything not to get better at it…or rather it is tragic when there is a point to doing something without hoping to be better at it.

For reference my suggestion is drawn from professional architecture and conveying precise meaning through drawings and sketches with millions of dollars and some arbitrary number of lives at stake. It is not from photo realism horses drawing.

My advice is drawn from exact graphic communication for money with the threat of lawsuits for ambiguity and error.