Abstractions (3 blogmarks)

← Blogmarks

Abstraction, intuition, and the “monad tutorial fallacy”

https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

The process of learning is more essential than the insight or abstraction that we encounter on the other end.

What I term the “monad tutorial fallacy,” then, consists in failing to recognize the critical role that struggling through fundamental details plays in the building of intuition. This, I suspect, is also one of the things that separates good teachers from poor ones. If you ever find yourself frustrated and astounded that someone else does not grasp a concept as easily and intuitively as you do, even after you clearly explain your intuition to them (“look, it’s really quite simple,” you say…) then you are suffering from the monad tutorial fallacy.

This last sentence feels really important as someone who likes teaching. I’ve found myself frustrated at times trying to teach something that now feels obvious to me. Of course, I’ve had the chance to struggle through to the light bulb moment.

How can my teaching be grounded in presenting learners with an effective learning path instead of a destination?

I came across this post via Justin Jaffary’s post on Divergent Histories.

Your job isn't programming

https://codeandcake.dev/posts/2025-12-12-your-job-isnt-programming

Great explanation of what makes a good abstraction:

Remember: abstractions are ideas, so a good abstraction should change the way you think about part of your codebase. If you introduce an abstraction and it doesn’t change the way you think, you haven’t made an abstraction, you’ve made a layer of indirection.

Computers can be understood

https://blog.nelhage.com/post/computers-can-be-understood/

any question I might care to ask (about computers) has a comprehensible answer which is accessible with determined exploration and learning.

The “with determined exploration and learning” is the important part here.

There is no magic. There is no layer beyond which we leave the realm of logic and executing instructions and encounter unknowable demons making arbitrary and capricious decisions. Most behaviors in one layer are comprehensible in terms of the concepts of the next layer, and all behaviors can be understood by digging down through enough layers.

Even recognizing and sorting out the different layers can be a great starting point. Then when you are thinking about a concept or issue, you can determine what layer is relevant to help set the context.

The trickiest bugs are often those that span multiple layers, or involve leaky abstraction boundaries between layers. These bugs are often impossible to understand at a single layer of the abstraction stack, and sometimes require the ability to view a behavior from multiple levels of abstractions at once to fully understand.

This tells us a lot about what we should strive for when trying to write clear, understandable code and whether we’ve done a good job when creating an abstraction.

Adopt a mindset of curiosity:

My advice for a practical upshot from this post would be: cultivate a deep sense of curiosity about the systems you work with. Ask questions about how they work, why they work that way, and how they were built.

… build your understanding, and your confidence that you can always understand more tomorrow.


My friend Jake Worth wrote his own version of this post — https://jakeworth.com/posts/computers-can-be-understood/

I think this is a great idea for any blogger. Take an inspiring or intriguing concept and give your own take on it.