Case Study 1: From Words to Pictures

How Marcus Learned to See Data Structures

Background

Marcus Thompson, 42, had spent fifteen years as a high school English teacher. He was brilliant with language. His students called him "Mr. T, the Word Machine." He could diagram a sentence in his sleep, dissect the rhetorical structure of a political speech in real time, and explain Shakespeare's use of iambic pentameter in a way that made even disengaged sophomores lean forward.

When Marcus decided to transition into data science, he expected the challenge would be mathematical. He'd been a humanities person his entire life. Surely calculus and statistics would be his stumbling block.

He was wrong. The math was fine — he'd tutored algebra for years and his logical reasoning was sharp. The problem was code. Specifically, the problem was data structures.

(Marcus Thompson is a composite character based on common patterns in adult learner research — Tier 3, illustrative example.)

The Problem

Six weeks into his Python programming course, Marcus could write simple scripts, define functions, and use basic control flow. But when the course introduced data structures — lists, dictionaries, tuples, sets, and especially nested combinations of these — Marcus hit a wall.

The textbook explained dictionaries this way: "A dictionary is an unordered collection of key-value pairs. Keys must be unique and immutable. Values can be of any type. Dictionaries are created with curly braces or the dict() constructor."

Marcus understood every word. He could pass a vocabulary quiz on dictionaries. But when his instructor asked him to write a program that organized student grades using a nested dictionary — a dictionary where each key was a student name and each value was another dictionary of assignments and scores — Marcus stared at his screen, paralyzed.

"I could recite the definition," Marcus recalled later. "I could even recognize a dictionary when I saw one in code. But I couldn't build one to solve a problem. The concepts were floating in my head as words — unanchored words. I didn't have a mental picture. I couldn't see the structure."

Marcus was experiencing a classic encoding problem. His verbal system was doing all the work. Every concept was stored as a string of words — a definition to be recited, not a structure to be manipulated. Without a spatial, visual representation, he couldn't mentally assemble the pieces into a working whole.

The Turning Point

Marcus's instructor, Dr. Yuna Kim, noticed the pattern. Marcus could answer questions about dictionaries but couldn't use them. His knowledge was declarative (knowing-that) but not procedural (knowing-how), and the missing bridge was structural understanding — a mental model of what a dictionary actually looked like inside the computer.

"Draw me a dictionary," Dr. Kim said during office hours.

Marcus blinked. "Draw it? It's code."

"Everything has a structure. Code especially. Draw the structure."

Reluctantly, Marcus picked up a pen and drew a two-column table on a sheet of notebook paper:

"That's a dictionary," Dr. Kim said. "Now draw a list."

Marcus drew a row of numbered boxes:

"Notice the difference," Dr. Kim pointed out. "A list has position numbers — indices. A dictionary has names — keys. When you want something from a list, you say 'give me item number 2.' When you want something from a dictionary, you say 'give me the item called age.' That's the structural difference."

Marcus stared at his two drawings. He'd read about this difference a dozen times. But seeing it side by side on paper, with spatial layout making the structural distinction visible — that was different. The list was a row with numbered slots. The dictionary was a lookup table with named labels. Different structures for different purposes.

"Now," said Dr. Kim, "draw a nested dictionary."

Marcus thought for a moment, then drew a table where one of the values was itself a table:

The nested dictionary was a table of tables. Each student name pointed to another lookup table of their grades. The structure was suddenly visible — literally, spatially, on the page.

Marcus went home and drew every data structure in the course.

The Transformation

Over the next two weeks, Marcus developed a systematic practice of visual encoding for programming concepts:

Week 1: Drawing data structures. - Lists became rows of numbered boxes - Dictionaries became two-column lookup tables - Sets became circles with unordered items inside (like a bag of marbles) - Tuples became rows of boxes with a lock icon (immutable — can't change) - Nested structures became diagrams within diagrams

Week 2: Drawing operations. - Appending to a list became an animation: a new box appears at the end of the row - Looking up a dictionary key became drawing an arrow from the key column to the value column - A for-loop became a cursor moving through each box in sequence - An if-statement became a diamond-shaped decision point in a flowchart

"What changed was not my intelligence," Marcus reflected. "It was my representation. When data structures were words, I could define them. When data structures were pictures, I could use them. The visual representation let me simulate operations in my head — I could mentally 'walk through' a loop, 'look up' a key, 'add' an item. I was thinking with the diagram, not just about the definition."

His assignment scores jumped from the 60s to the 80s within two weeks. By the end of the semester, he was scoring in the 90s and helping other students by drawing diagrams on the whiteboard during study sessions.

Analysis: Why It Worked

Marcus's transformation illustrates several key principles from Chapter 9:

1. He activated a dormant channel. Marcus's imagery system was fully functional — he'd been using it his entire life for tasks like navigating, recognizing faces, and imagining scenes from novels. But he'd never deliberately deployed it for technical learning. Drawing data structures activated the imagery system for a domain that had previously been verbal-only.

2. The referential connections transformed his understanding. Once Marcus connected "dictionary" (verbal code) to a two-column lookup table (visual code), the concept had two retrieval routes. More importantly, the visual code captured structural properties that the verbal code missed. You can read the words "unordered collection of key-value pairs" a hundred times, but you might not see the structure until you draw it.

3. The visual code supported mental simulation. Marcus's drawings weren't static pictures — they were mental models he could manipulate. He could imagine a new row being added to a table (appending to a dictionary), or a cursor moving through boxes (iterating through a list). This kind of mental simulation is exactly what programming requires, and it's inherently visuospatial.

4. Creating the visuals forced deep processing. Marcus couldn't draw a nested dictionary without understanding what nesting meant. The drawing process revealed gaps in his knowledge — when he couldn't figure out how to draw something, he knew he didn't truly understand it. This is metacognitive monitoring through dual coding.

5. His verbal strengths weren't replaced — they were supplemented. Marcus remained an excellent verbal thinker. His ability to explain concepts in words actually improved once he had visual models to anchor his explanations. The two systems reinforced each other through referential connections.

Discussion Questions

1. Marcus initially resisted drawing because it felt "childish" and he identified as "not a visual person." What does this resistance reveal about the role of self-concept and identity in learning strategy adoption? How does this connect to the fixed-vs.-growth mindset discussion from Chapter 1?

2. Dr. Kim asked Marcus to draw a dictionary rather than explaining it to him again verbally. Why was this pedagogical choice effective? How does it relate to the generation effect (the finding that generating information yourself produces better memory than receiving it)?

3. Marcus's visual representations were crude and simple — basic tables and boxes. Yet they dramatically improved his understanding. Using concepts from this chapter, explain why the quality of the drawing mattered less than the act of drawing.

4. Marcus eventually began helping other students by drawing diagrams on the whiteboard. How does teaching through dual coding combine the benefits of dual coding with the protege effect (Chapter 22 preview)?

5. Imagine Marcus's instructor had instead given him pre-made, professional diagrams of all the data structures. Based on what you know about dual coding theory, would this have been equally effective? Why or why not?

Your Turn

Choose a concept you're currently struggling with — from any course, skill, or area of learning. Follow Marcus's process:

1. Write down the verbal definition or explanation you already know.
2. Identify: what is the structure of this concept? Does it have parts, relationships, sequences, hierarchies, or spatial properties?
3. Draw it. Use simple shapes — boxes, circles, arrows, tables. Don't worry about artistic quality.
4. Look at your drawing. What does it reveal that the words alone didn't? What gaps in your understanding become visible when you try to represent the concept visually?
5. Write a brief reflection: How did the drawing change your understanding?

This case study connects to: Chapter 1 (Marcus's introduction), Chapter 2 (encoding depth), Chapter 4 (Marcus and attention), Chapter 5 (cognitive load), Chapter 8 (learning styles myth), Chapter 11 (transfer of teaching skills), Chapter 24 (Marcus and AI tools).