You can imagine programming languages as different types of building materials. I actually find this to be a good conversation opener when I meet another software writer. If you ask what languages someone likes or dislikes, you're likely to hear the answer that reflects their community affiliation--what kind of programming culture they come from. Different programming cultures value different things, and each programming language includes choices about what's important. So, for software writers within a programming culture, the answer to a question like "which languages do you like," will probably be fairly similar. But if you ask "what materials do different programming languages remind you of," you remove some of that cultural expectation. Most software writers will be able to address the question thoughtfully--we already use words like "flexibility," and "ergonomics" to describe different languages, so there's a precedent for thinking about them in physical terms. The question is meant to be an invitation to what I bet is the original human activity--Let's Talk About What We Think About Things-- that starts in a whimsical place with a focus on collaboration.

I haven't yet found any similar question that opens a collaborative conversation about software system design. You obviously couldn't ask about any specific school of thought-- at least, not unless you want a canned response. There are some very famous books on the subject, but they tend to be adopted by one or another lineage in such a way that which ones you know or like are culturally influenced. If you try the trick from earlier-- "what kind of x do you imagine different system design schools representing"--the only suitable values of x--the familliar concepts that might be analogous to system design-- are political systems, religions, and philosophy (in a weird way, I think this might be a starting point for a description of P ≠ NP). If you're looking for a safe way to open a conversation on what's good in software system design, philosophy, religion, and politics all have points to de-commend them.

The only trick I really have for this is the one I think of as the Good Youtuber gambit. The people whose videos I love to watch aren't necessarily those who do things I'm interested in--they're the ones who are best able to convey the joy and excitement of whatever they're interested in. When you can't think of a way to ask someone to share their thoughts with you, sometimes you can start by sharing your thoughts with them. But they should be as generous thoughts as you can conceive.

The problem, of course, is that system design fundamentally is philosophical and political. Every system we build has a purpose; each one is a statement about what we value or dismiss. Software systems are full of definitions of concepts and the rules that govern them. That's not a metaphorical statement--the only way to write a program that does anything useful, like let you search cars at a dealership, is for someone to decide on The Set Of Things That Are Important About A Car. That set of things is the system's definition of a car. Part of the reason people get annoyed at engineers is that engineers have the hubris to do stuff like that--to just decide what's important about things. Part of the reason engineers get annoyed at people is that they think it's possible to avoid the question. Engineers know the truth--these questions can't be avoided; you need to find a project manager to give you plausible deniability.

I feel myself to be between those worlds. The same thing that draws me to poetry draws me to software. They seem equally to be ways of transcending reality--of giving your mind that tiny extra bit of freedom it needs to finally make sense of things. A computer will patiently let you explain your big idea for hours; it will help you identify and work through inconsistencies in the way that you think; and once you explain something well enough, it's like there's a little wisp of your thought in the machine, much more loosely bound by space and time than you are.

This is the place in me that system design comes from. The important things I make are not the things that perform tasks; they're the things that increase the scope of what I can express or add nuance to what I can say. If I am clever, I can use each task on the way to any goal as an opportunity to add to my set of tools. More important than the tools--I am able to discover patterns in the types of things I find myself doing over and over; these patterns suggest new places to abstract or refine. I don't know where my interests will take me; I don't know if a system I build today for archiving an image, or posting a statement, will still be what I want tomorrow. But I do know that whatever effort I put into patterns of expression now will be available to me later, even if what I want to express has changed.

During my time in the software industry, I have not seen this thought widely endorsed (though it's been around much longer than me). The approach that I usually see taken, even by the well-intentioned, is to use code to create a single representation of a concept--a social media post, the way you write a document-- and then "monetize" it by the fastest available means. This looks like progress-- after all, it does allow more and more people to easily participate in any system that can be monetized--but it doesn't do the most basic thing-- make software actually work in the interest of the human who uses it, even if their interest diverges from that of the system designer.

I don't know if the things I build will ever prove useful to anyone other than me-- if past experience is a guide, the odds are against it. But it costs me nothing to share all my work with anyone to whom it might.