01 / THE ORIGIN
From my notes to a shared guide.
A lot of this guide began as notes I took over the years. Writing things down has been part of how I learn: working through an idea, finding an explanation that clicks, and leaving something useful for myself to come back to.
I even developed an AI note-taking protocol: a set of instructions for explaining concepts in the way I prefer to learn them. It inspired much of the format here. Start with something concrete, work through an example, and make room for the questions and trade-offs that come with using it.
Heyrian brings those notes into a guide other people can explore. My hope is that an explanation that helped something click for me might do the same for someone else.
02 / A LITTLE CURIOSITY
Another language, another way to think.
I’m not fluent in every language I explore, but I enjoy seeing how the same problem is approached differently. A language can make one idea feel natural and another feel awkward. Looking at those differences has given me perspectives I would have missed by staying in one place.
That curiosity is part of this guide. Following an idea across languages helps me separate the concept from a particular syntax, and question habits I had started to take for granted. I want to share that experience here, while continuing to learn alongside the people reading it.
03 / WHY THESE IDEAS MATTER TO ME
More ways to describe what you mean.
Patterns, data structures, algorithms, and architecture give names to decisions we make in software. These ideas show up inside the libraries, frameworks, and systems we build on. Understanding them helps me see how the pieces work together and ask better questions about the choices underneath.
I think that understanding still matters when AI can produce so much code. Knowing the concepts gives you more ways to describe what you want. Consider these two prompts:
“I need to handle envs.”
“Config comes from defaults, a preset, and overrides, in that order; overrides win. Reject unknown presets at the boundary, and freeze the result so nothing edits it later.”
The second prompt doesn’t name a single pattern, but every clause in it is a concept with a name: layered defaults, validation at the boundary, immutability at the exit. Knowing those ideas is what lets you say the second sentence at all. It also works in reverse: when the code comes back, you can recognize which of those decisions it actually made, notice the ones it skipped, and ask for exactly the change you need instead of regenerating and hoping.
That is what I hope this guide helps with: building enough understanding to express your intent, recognize the choices in front of you, and take responsibility for what you build.
04 / AN OPEN INVITATION
Want to help shape it?
A work in progress.
The site is still improving, and I’m rolling out content carefully, taking time to work through examples and revisit explanations. Even with that care, I’m not perfect; nobody is. There may be mistakes, gaps, or ideas I understand differently as I learn more. Expect corrections and revisions along the way. My aim is to keep making this guide clearer and more useful, and to stay open to being corrected.
I’d love to see this guide become better through other people’s perspectives: a correction, a clearer explanation, an example from a language you enjoy, or a connection I haven’t noticed yet.
If you’d like to contribute, keep an eye on this space. I’ll share ways to get involved as the project takes shape. In the meantime, I hope you find something here that makes you curious enough to try it yourself.
Thanks for reading, and for learning alongside me.
Explore the guide