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.

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

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

(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.

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.