Notices by Ruth Malan (ruthmalan@mastodon.social), page 7

"understanding of complex systems is distributed"
-- Chris McDermott

I told the story of “smuggling donkeys” today (when I heard it, I thought I was the last person to hear it, probably, but then it seems maybe not??)

And then the question is, what donkeys am I smuggling… and yes. You know. Visual design as **collaborative** system design. :)

Day 15 #AdventOfSystemSeeing

Pulling on Threads: Why? (And What?)

Find an interesting thread in the tangle of the situation and pull on it. If you notice something curious or concerning, ask "why?" (looking for direct causes), and again "why?" as exhaustively as a curious two year old. And you may find yourself... tracing out paths in a causal interaction network. Example: https://hachyderm.io/@inthehands/109378117775642584

Or follow "what does this depend on (or need)?" and "what does that depend on (or need)?" paths.

Day 1 #AdventOfSystemSeeing

Without looking at one (not even a picture), draw a bicycle.

Annotate with observations and questions that your drawing raises for you.

(I have us do this exercise during of some of my workshops. It’s more interesting and useful than it sounds — probably.)

@mattly that must be so cool!

Well, John Green’s a 5. You?

(The tweet: https://twitter.com/johngreen/status/1708515024275189884)

I keep coming back to that quote (not just in the context of chatGPT et al hahah).

“But the brain does much more than just recollect it inter-compares, it synthesizes, it analyzes, it generates abstractions. The simplest thought like the concept of the number one has an elaborate logical underpinning. The brain has its own language for testing the structure and consistency of the world.”
— Carl Sagan

https://www.youtube.com/watch?v=zSgiXGELjbc

Just do something.
When a design problem is so overwhelming as to be nearly paralyzing, don’t wait for clarity to arrive before beginning to draw. Drawing is not simply a way of depicting a design solution; it is a way of learning about the problem you are trying to solve.”
— Matthew Frederick

Architects are system designers — not the only designers of the system, of course! Still, systems and their contexts are continually evolving, and it takes attention to understand the system — across all the boundaries and areas of focus of teams, as well as impacts of and on the system — as use and operational contexts evolve, to foster requisite cohesion and system integrity *over time* as things change...

@mattly nice and yup, good to keep looking around for ways to make the conversation productive!

My “take” on how the term “technical debt” gets used? I know the origin. I just have a thought… I think we (waves around generally) needed a term to have an important set of conversations around. Like, we wanted a way to, with dignity, draw attention to the choices being made, when the pressures to keep focusing on “adding value” means kicking “code habitability” work down the road… An alternative like “neglect” … sounds like we shirked… which, underplays the pressures…