Thinking in Geodes: Autism, Learning, and the Art of Taking Things Apart

Apparently, There Is a Normal Way to Learn Things

I am autistic. That is a fairly simple sentence describing something that has made my relationship with the world considerably less simple.

For much of my life, I struggled with things other people seemed to pick up almost effortlessly. Instructions that appeared perfectly reasonable to everyone else could leave me staring at a problem, wondering which critical piece of information had apparently been distributed at a meeting I wasn't invited to. Meanwhile, I could sometimes look at a complicated technical problem, identify the underlying issue, and propose a solution that seemed painfully obvious to me.

Other people would look at me like I had just performed some elaborate feat of intellectual wizardry. In reality, I had simply noticed that a particular component wasn't doing its job. I would love to tell you that this makes me some kind of misunderstood genius, but unfortunately, I am also perfectly capable of spending twenty minutes looking for something sitting directly in front of me. The brain giveth, and the brain apparently forgot where it put the screwdriver.

I was diagnosed with autism as an adult, at thirty-six. Suddenly, a great many things about my life made considerably more sense. It didn't magically resolve decades of frustration, but it gave me a better explanation than simply assuming I was somehow doing being human incorrectly.

One of the biggest realizations was that I wasn't necessarily struggling to understand the information itself. I was struggling with how the information was being presented. That distinction changed how I approached learning, troubleshooting, and eventually designing things myself.

I Don't Want the Instructions. I Want to Know What the Parts Do.

Traditional instruction often starts by presenting a complete process. Here are the steps, follow them in order, memorize the terminology, and practice until it becomes natural. For some people, that works beautifully. For me, it can feel like being handed the assembly instructions for a machine without being told what any of the components actually do.

I can follow instructions, memorize commands, and reproduce a procedure. But if I don't understand why the individual pieces are there, I don't really feel like I understand the thing. I have learned a sequence of actions, not a system, and sequences are fragile. Change the interface, rename a menu, move a setting, or introduce an unexpected condition, and suddenly the instructions are little more than decorative literature.

This is particularly frustrating when dealing with software designed around conventions everyone is apparently expected to absorb through cultural osmosis. Someone will tell me to "just click the usual thing," which is wonderful advice assuming I have access to the universal registry of usual things.

What I actually want is a functional explanation. What is this component responsible for? What does it receive? What does it produce? What happens when it fails? How does it interact with everything around it? Once I understand those relationships, I can usually work out the rest. I don't need to memorize every possible configuration of a machine if I understand the pieces from which that machine is built.

Which brings me to electronics, where this approach started making an extraordinary amount of sense.

Everything Is a Little Block

Electronics gave me one of the most useful mental models I have ever encountered. At a basic level, electronic circuits can be understood as collections of components, each with its own recognizable behavior. A resistor opposes the flow of current. A capacitor stores electrical charge and opposes changes in voltage. An inductor stores energy in a magnetic field and opposes changes in current. A diode primarily allows current to flow in one direction, and a transistor can switch or control electrical signals.

Yes, the actual physics is considerably more complicated. I am aware. Please put down the oscilloscope.

The important part is that each component has a recognizable function. I can learn what a resistor does without first understanding every possible circuit that contains one, and I can learn what a capacitor does independently. Then I can put them together and start exploring how they interact. Now I have an RC circuit, and I can observe how changing one value affects the behavior of the whole arrangement.

Add another component, observe what happens, and repeat. Eventually, something that initially looked like an incomprehensible mess of wires and components becomes a collection of familiar behaviors interacting with one another. I don't have to understand the entire machine at once. I just have to understand the pieces and the relationships between them.

For years, I thought of this as learning with LEGO blocks. Each block does something, each connects to other blocks, and a complicated structure is just a collection of simpler structures arranged in a particular way. Of course, the analogy isn't perfect. LEGO bricks don't generally explode because you connected them backward, whereas electronics occasionally likes to make its objections known through smoke.

But the underlying idea works remarkably well, and eventually I realized I could apply it to almost anything.

From LEGO Blocks to Geodes

Lately, I have started calling these conceptual blocks Geodes. Partly because I wanted a name that belonged to the concept rather than somebody else's toy company, but mostly because I think geodes are pretty. I am allowed to have an aesthetic preference in my engineering philosophy.

A geological geode looks relatively ordinary from the outside. Crack it open, however, and you discover an intricate internal structure. That is surprisingly close to how I think about systems. From the outside, a Geode presents a simple function. Inside, it might contain an entire collection of smaller Geodes working together. The complexity exists, but I don't need to carry all of it in my head every time I want to use the thing.

A Geode, as I define it, is a conceptual component with a clear responsibility, understandable inputs, and predictable outputs. It does one job, although that job might represent something considerably more complicated internally. The important part is that I can understand and reason about it as an individual piece.

Take an email client, for example. Most people probably think of an email client as an application that sends and receives email, which is perfectly reasonable. I look at it and see a collection of Geodes. One handles establishing a connection to the mail server, another handles authentication, another manages the protocol conversation, and another retrieves messages. Further Geodes parse message content, manage local storage, present the messages to the user, and handle composing and sending replies.

Each Geode has a responsibility that can be understood and tested independently. If the application suddenly stops downloading email, I don't have to think about the entire application as one enormous, mysterious entity. I can follow the chain and ask whether the connection succeeded, whether authentication worked, whether the server accepted the request, and whether the message retrieval and parsing processes completed successfully. Somewhere along the way, a Geode isn't doing its job, and my task is to identify which one.

This is essentially modular engineering, separation of concerns, and systems decomposition, concepts that software engineers have been using for decades. I didn't invent those principles. I just independently arrived at a way of thinking about them that makes sense to my brain, then gave it a prettier name. Engineers have been doing considerably worse things with terminology for years.

The Trick Is Knowing When to Stop Looking Inside

There is another important part of this method. Once I understand a Geode well enough to trust its behavior, I can stop thinking about its internal implementation. I don't need to mentally reconstruct the entire authentication process every time an email client logs in. I know what the authentication Geode is supposed to do, what it needs, and what success and failure look like. That is enough for the problem I'm currently solving.

If something goes wrong, I can open it back up and investigate. Otherwise, it stays closed, which is important because trying to consciously track every detail of a complicated system is exhausting. Imagine building a house while simultaneously thinking about the molecular structure of every nail. It's technically relevant, but not particularly useful when you're trying to install a door.

Geodes let me decide which level of complexity I need to work with. A computer can be treated as a Geode, but open it up and there are smaller Geodes responsible for processing, memory, storage, networking, and power management. Open the processor and there are smaller Geodes still. Keep going and eventually you're discussing transistor behavior and semiconductor physics. Keep going beyond that, and congratulations, you've accidentally enrolled in a physics degree.

The point is that I can move between levels of abstraction without having to hold every level in my head simultaneously. I can understand the system from the outside, selectively investigate the parts that matter, and reuse what I have already learned without rebuilding my entire understanding from scratch.

Why This Matters When You're Autistic

I want to be careful about something here. Autistic people are not all the same. There is no universal autistic learning method, no magical engineering superpower, and certainly no secret committee distributing complimentary programming skills with every diagnosis. I can barely get a group of people to agree on where to eat. I doubt we're coordinating an entire neurological demographic.

This is simply how my brain works.

I often struggle when information is presented as a collection of arbitrary rules, unexplained conventions, or procedures that depend on implicit knowledge. I do considerably better when I can identify the underlying logic and build my understanding from there. That means I may need more time, more references, or a different explanation to learn something other people find straightforward. It also means I can sometimes recognize relationships, inconsistencies, or solutions that other people overlook.

Neither experience cancels out the other. I can be exceptionally comfortable reasoning about a complex technical architecture and still find an unfamiliar administrative process unnecessarily difficult. I can design a system from first principles and then need to look up the syntax for a command I have used fifty times. I can understand what a piece of software needs to accomplish while struggling to remember where its developers decided to hide a particular setting.

There is an important difference between understanding a concept and remembering somebody else's implementation of it. My understanding is often stronger than my recall, and for a long time I treated that as a personal failing. These days, I treat it as a design constraint, something to account for rather than something to be ashamed of.

My Memory Is Not a Filing Cabinet

One of the most useful things I have learned is that I don't need to memorize everything. I need to understand enough to know what I am looking for and where that information fits into the larger system.

When working with unfamiliar systems, I use documentation, examples, notes, references, diagrams, and increasingly, AI tools to bridge the gap between understanding what I want to accomplish and remembering the exact steps required by a particular implementation. I might understand how a networking protocol operates while needing to look up a configuration directive. I might understand the architecture of an application while needing a reference for the precise syntax of a library function. I might know exactly what a circuit needs to accomplish while checking a datasheet to confirm a component's characteristics.

That isn't a contradiction. It is simply the difference between conceptual understanding and memorized detail.

Some people seem able to retain enormous collections of commands, procedures, and conventions. Good for them. My brain apparently decided that storage space would be better spent on thirty-seven interconnected ideas about something I haven't built yet.

Rather than fighting that, I use external references as an extension of my working process. Documentation becomes a lookup table, notes become persistent state, and diagrams become maps of relationships. AI can become an interactive reference or a way to translate an unfamiliar explanation into something I can actually work with. None of those tools replaces understanding, but they make it easier for me to apply the understanding I already have.

When something doesn't make sense, I break it into Geodes until I find the part I don't understand. Then I learn that part instead of trying to memorize the entire universe surrounding it.

Learning Backward, Sideways, and Occasionally Upside Down

Another consequence of this approach is that I don't always learn things in the order they're traditionally taught. A conventional course might begin with terminology, move into foundational theory, introduce increasingly complex examples, and eventually arrive at a practical application.

I often start with the practical application because I want to build something.

To build it, I need to understand a particular subsystem. To understand that subsystem, I need to learn three smaller concepts. One of those concepts requires a little mathematics, so I learn the mathematics I need, then return to the subsystem and eventually to the original project.

This isn't necessarily the most academically elegant way to learn a subject, but it gives every new piece of information a purpose. I am not learning a formula because chapter seven says it will be on the exam. I am learning it because I have a specific problem, and the formula is the missing Geode.

That makes a tremendous difference to my motivation and comprehension. The information has somewhere to go, it connects to something I already understand, and it becomes useful immediately.

Of course, this method has limitations. Learning only what is immediately necessary can leave gaps in foundational knowledge, and those gaps occasionally come back to bite me, usually after I have confidently announced that something should be simple. So I have learned to revisit the foundations, especially when I encounter something that doesn't fit my existing mental model. The goal isn't to avoid structured learning, but to make structured learning meaningful.

Sometimes the Obvious Answer Really Is Obvious

There is a particular kind of problem-solving experience I have had throughout my life. Someone presents a complicated problem, several people discuss it, and a collection of possible explanations emerges. People begin investigating increasingly elaborate theories, while I look at the situation and ask a question that seems almost embarrassingly simple.

"Did we check whether that part is actually working?"

Occasionally, that turns out to be the problem. Not because I possess some extraordinary ability to see through complexity, but because I am looking for the smallest functional unit that could explain the observed behavior.

If a system is supposed to do five things in sequence and the fourth thing isn't happening, I want to know whether the third thing produced the correct output. I don't particularly care how impressive the rest of the system is. The fourth Geode cannot do its job if the third one hands it garbage.

This approach is especially useful in troubleshooting, where complicated symptoms often emerge from surprisingly simple failures. It also means I sometimes miss things that other people immediately recognize through experience or intuition. My method is not infallible, and sometimes I am the person proposing an elaborate explanation for a problem that turns out to be a loose cable. The universe enjoys maintaining balance.

But when the method works, it works because I am not trying to reason about the entire system at once. I am following the behavior of its parts, one responsibility at a time.

This Is Becoming How I Design Things, Too

What started as a way to understand electronics has gradually become a philosophy for designing software, tools, and systems. When I approach a new project, I don't want to begin with one enormous application that somehow does everything. I want to identify its responsibilities, work out the smallest meaningful pieces that can accomplish those responsibilities, and understand how those pieces communicate.

A Geode should have a clear purpose, understandable interfaces, and predictable behavior. Ideally, I should be able to replace or improve one without reconstructing the entire application around it. Real systems are rarely perfectly independent, of course. State, timing, shared resources, and unexpected interactions can complicate even the cleanest architecture. I'm not suggesting that everything can be reduced to a magical collection of completely isolated components, only that we should make the boundaries as clear as we reasonably can.

This also influences how I think about user interfaces. I want interfaces that communicate intent. If a button performs an action, I want the user to understand what that action is. If a process has several stages, I want those stages to be visible and understandable. If something fails, I want the system to explain which responsibility failed and what can be done about it.

I don't want users to memorize arbitrary rituals just to operate something I built. I have spent enough of my life dealing with those rituals myself, and there is no reason to inflict them on other people.

Maybe the Problem Isn't Always the Person Learning

Something that bothers me about conventional education and software design is how frequently difficulty gets attributed to the person experiencing it. If someone struggles to understand an explanation, we often assume they need to try harder. If someone cannot navigate an interface, we assume they need more training. If someone repeatedly forgets a procedure, we assume they need to memorize it better.

Sometimes those things are true, but sometimes the explanation is poor, the interface is confusing, or the procedure relies on information that was never communicated. Sometimes the system was designed around a particular way of thinking without acknowledging that other ways exist.

I am not suggesting that the entire world should be redesigned around my personal preferences. That would be ridiculous, although I do have some notes.

What I am suggesting is that clarity, modularity, explicit behavior, and accessible references benefit far more people than just those of us who struggle with conventional learning methods. A well-designed system should not require its user to think exactly like its creator. It should provide enough information for different people to form a useful understanding of what it does.

That is one of the reasons I care so much about intent-focused design. I want technology to make it easier for people to accomplish what they are trying to accomplish, not force them to become experts in the arbitrary decisions somebody made while implementing it.

I Am Not Trying to Think Like Everyone Else Anymore

For a long time, I thought becoming better at learning meant eventually learning to do it the way other people did. Read the material, remember the instructions, follow the process, and repeat until it becomes natural. When that didn't work, I assumed I needed to try harder.

Now I approach things differently. I identify what I want to understand, break it into meaningful pieces, learn what each piece does, and connect those pieces into a larger model. I use references for details I don't need to permanently memorize, and when the model stops making sense, I open it up and find out why.

Geodes aren't a cure for autism. They aren't a universal learning system, and I certainly wouldn't suggest that every autistic person should start treating the world like an electronics laboratory. They're simply the mental framework I developed to make complicated things understandable. Over time, that framework has become something more. It is how I learn, how I troubleshoot, how I design, and increasingly, how I think technology should be built.

I spent a great deal of my life trying to adapt my thinking to systems that weren't designed for it. These days, I am more interested in building systems that can adapt to the people using them. I don't think the purpose of technology should be to make everyone think the same way. I think it should help people do more with the minds they already have.

And if my particular contribution to that future involves taking everything apart, putting it into little conceptual boxes, and giving those boxes pretty geological names, I can live with that.

At least until I discover that one of my Geodes isn't working. Then we're going to have words.