The Shape of Thought

The Medium Shapes the Message: A Reflection from Blueprints to Code

Recently, I stumbled upon a fascinating YouTube video titled "Why You Don't See Blueprints Anymore". It walks through the history of architectural blueprinting and how the seemingly technical shift from hand-drawn plans to blueprint copies subtly but powerfully transformed how buildings were designed.

One moment stuck with me: Stewart Hicks, the narrator, explained how buildings gradually became flatter and more standardized because blueprints—being high-contrast reproductions of white lines on blue paper—stripped away all the expressive shading, color, and texture of original hand-drawings. That got me thinking about how the medium we use to capture an idea inevitably shapes the idea itself.

This rabbit hole led me to the work of Marshall McLuhan, a media theorist famous for the provocative phrase: "The medium is the message."

What Does "The Medium Is the Message" Mean?

McLuhan argued that we often pay too much attention to the content of communication ("the message") and not enough to the medium through which it's delivered. But the medium itself—whether it's television, print, code, or even blueprints—shapes how that message is perceived, understood, and even created in the first place.

---

Reflections in Software Development

As a programmer, this concept resonated deeply. The tools we choose don't just build the product; they build the builder. Here are a few examples of how the medium shapes the message in the world of code.

1. Programming Languages: The Grammar of Thought

A programming language is the most fundamental medium for a developer. Its syntax, paradigms, and constraints are the grammar of our problem-solving thoughts.

• Static vs. Dynamic Typing: When I work in a statically-typed language like Rust or TypeScript, I'm forced to think about data shapes, contracts, and edge cases upfront. The compiler becomes a Socratic partner, questioning my assumptions before the code ever runs. In a dynamically-typed language like Python or JavaScript, I can build faster initially, but that freedom demands a different kind of discipline—often in the form of more extensive runtime testing. The medium nudges my focus between compile-time correctness and runtime flexibility.

• Low-level vs. High-level Languages: Writing C forces an intimate understanding of memory management. You can't not think about pointers, allocation, and lifetimes. The language's medium is one of manual control and resource awareness. In contrast, a high-level language like Python abstracts these details away, allowing you to focus on business logic. The medium shifts your thinking from how the machine works to what the program should do.

2. Frameworks and APIs: The Scaffolding of Solutions

Frameworks are famously opinionated. They provide scaffolding that accelerates development, but that scaffolding also directs the architecture of what you build.

• The "Pit of Success": A well-designed API creates a "pit of success"—it's easier to use it correctly than incorrectly. The names of functions, the structure of the data, and the error messages all guide the developer toward a robust implementation. A poorly designed API, on the other hand, is a "pit of failure," where intuitive use leads to bugs. The medium itself is either a guide or a trap.

• Communication Protocols: Consider REST vs. GraphQL. A RESTful approach, with its fixed endpoints and resource-based structure, shapes how we think about data as a collection of nouns (users, posts, etc.). GraphQL, with its flexible query language, shifts the focus to the specific needs of the client. It allows the client to ask for exactly what it needs, changing the conversation from "give me this resource" to "tell me about this entity in this shape."

3. Documentation vs. StackOverflow: The Diet of Our Knowledge

This is a modern classic for developers.

• StackOverflow: A quick snippet is a fast-food meal. It solves an immediate problem but rarely provides deep, lasting nourishment. Over-reliance on this medium can lead to "cargo-culting"—copying patterns without understanding the why. It optimizes for speed, not comprehension.

• Official Documentation: Reading the docs is a home-cooked meal. It's slower and requires more effort, but it builds a robust mental model of the system. It's the difference between knowing a single magic spell and understanding the principles of magic. This medium optimizes for true learning, which pays dividends in the long run.

---

The Tools We Choose, The Thinkers We Become

The story of blueprints is a powerful reminder that our tools are not passive instruments. They are active partners that shape our thinking, constrain our options, and define what we consider "possible." The high-contrast simplicity of a blueprint stripped architecture of its texture and nuance, leaving only form and geometry.

The same is true for software. A language, a framework, or even a documentation style isn't just a conduit for ideas—it's an environment that cultivates certain kinds of thoughts. Fast, convenient mediums like StackOverflow snippets optimize for immediate results but can starve us of deeper understanding. Opinionated frameworks accelerate our work but can blind us to alternative solutions.

The takeaway isn't to abandon our tools, but to choose them consciously and wield them with intention. We must recognize that every tool we pick up comes with a set of implicit assumptions. Our job is to be aware of them.

So the next time you approach a problem, don't just ask, "What tool is right for this job?" Also ask:

"What kind of thinker will this tool help me become?"

---

Cover image by Reto Scheiwiller from Pixabay