MEMOIZATION

More Than Writing Code

Before I started learning to code, most of the work I knew was hands-on. My background was working on a cattle ranch, spending time around animals, and working on cars and equipment. It was a world where problems usually had something physical attached to them—something you could inspect, take apart, adjust, or repair.

That kind of work teaches you to pay attention. Animals need consistent care, and equipment needs maintenance. When something goes wrong, you have to look closely at what is happening and decide what to do next. You may have an idea of the cause, but you still need to check it. Guessing can send you down the wrong path and leave the original problem unresolved.

When I started studying software development, the setting changed considerably. Instead of working with machinery or caring for animals, I was looking at a screen and trying to understand how instructions became a working program. Much of it was unfamiliar, but the process of figuring things out felt connected to the work I already knew. I was beginning again in a different field, and boy it sure was a difficult one for me, but by bringing a practical background with me I learned how to apply it in a new way.

Learning Through the Details

My first coding venture in school was diving headfirst into C++. Coming from a background of ranch work, animals, and working on cars and equipment, I was stepping into a field with its own language and way of thinking. I was learning what programming was while also trying to learn a language that asks quite a bit of a beginner.

C++ is not especially beginner-friendly. There is a lot to understand before you can feel comfortable writing even a relatively small program. Along with variables, conditions, loops, and functions, you encounter rules about types, declarations, scope, and how different parts of a program fit together. As you move further, references, pointers, and memory management introduce another layer of complexity.

The difficulty comes partly from learning all of those things at once. When you are new, you may not know whether the problem is your syntax, your logic, or your understanding of the concept itself. You can have a clear idea of what you want the program to accomplish and still struggle to turn that idea into something the compiler accepts.

Even the feedback takes practice to understand. A missing semicolon or mismatched brace can produce several compiler errors, and the messages can contain terminology you have barely encountered. Before you can fix the code, you sometimes have to figure out what the error message is trying to tell you. That adds another task to an already unfamiliar process. Then there is the difference between getting a program to compile and getting it to behave correctly. A program can run without doing what you intended. A loop might stop too early, a condition might check the wrong thing, or a calculation might produce an unexpected result because of the types involved. Those problems require you to follow the program’s behavior step by step and examine your own assumptions.

What made C++ demanding was the precision it required while I was still building that understanding. I could not rely on knowing roughly what a line meant. I needed to understand how the language would interpret it and how it affected the rest of the program. Small details could change the result, and overlooking them could leave me staring at code that seemed reasonable but would not work.

That can be discouraging when you are starting out. You want to build something, but much of your attention goes toward getting the basics right. A short assignment can take longer than expected because each unfamiliar detail sends you back to an explanation or example. It is easy to measure progress by whether the program is finished and overlook how much you are learning while trying to finish it.

I began to appreciate the value of working through smaller pieces. Understanding one loop thoroughly is more useful than copying several that I cannot explain. The same applies to a function or a compiler error. Taking time to understand why something works gives me a better starting point when I encounter a similar problem again.

My background helped me find some patience with that process. Working on equipment already involved investigating problems, checking assumptions, and accepting that the first explanation might be wrong. Learning C++ required me to apply those habits in an unfamiliar setting, where I was still learning what to inspect and which questions to ask.

I would not describe C++ as an easy introduction to programming. It made the beginning demanding, and there were concepts that needed repeated attention before they became clear. But it also gave me an early appreciation for how carefully software has to be constructed. As I understood more, I could begin to see the reasoning behind code that had once looked like a collection of unfamiliar symbols.

The rewarding part was being able to explain something that had previously confused me. Following a function, understanding why a loop ended, or finding the cause of an incorrect result gave me evidence that I was making progress. Those moments helped make a difficult beginning feel worthwhile and gave me something solid to build on.

Making Room to Learn

“What is ‘familiarly known’ is not properly known, just for the reason that it is ‘familiar’.” ¹

That distinction captures something I have experienced while learning to program. Code can look familiar before I can explain why it works, and an explanation can make sense before I can apply it independently. Working through a problem myself reveals the distance between recognition and understanding. The moniker of Memoization grows out of that experience. I want to preserve lessons I can return to, while also recording the reasoning that made them useful. When I revisit an earlier solution, I want to understand its assumptions, recognize its limits, and decide whether it fits the problem in front of me.

In programming, memoization means storing the result of a computation so it can be reused when the same inputs occur again. That idea gives this archive its name. By recording a problem, the approach I took, and why a solution worked, I give myself a starting point when a similar challenge appears. The connection is a metaphor: applying a past lesson still requires judgment, especially when the circumstances have changed. What I want to preserve is enough understanding to build on earlier work without having to rediscover every lesson from the beginning.

Starting with C++ taught me that learning to program takes time, and that understanding something once does not always mean I am ready to use it on my own. A concept can make sense while I am reading an explanation, then become much less clear when I sit down to write the code myself. Working through that gap is an important part of learning.

Some lessons come from studying a concept. Others come from trying an approach, finding its limits, and revising it. I need both. Studying gives me a foundation, while building something helps me discover which parts I understand and which parts still need attention.

That has meant making room to be a beginner. Coming from work where I had familiar tools and practical experience, it was an adjustment to need help with things that might seem basic to an experienced developer. I had to become comfortable asking questions, revisiting material, and spending longer on a problem than I initially expected.

My experience with cars and equipment gives me a useful perspective. You do not become familiar with a system simply by looking at it once. You learn through working with it, understanding how its parts connect, and encountering problems that make you look more closely. I am finding that programming requires the same willingness to build understanding over time.

With a gasoline engine, all you need to run is fuel, air, and spark. They need to arrive in the right amounts and at the right time, and compression matters too. If the engine will not run, I can work through those requirements and narrow down what is missing. Experience gives me a sequence of checks, even when I do not yet know the cause. Code requires a different set of checks. A program might fail because of an unexpected input, a condition that never becomes true, or a function that changes something another part of the program depends on. There is no single checklist that explains every failure, believe me I checked. So I have to understand what the program expects, follow what it actually does, and find where those two things diverge. Now, my mechanical background does help with the patience and investigation, but I still have to learn the rules of the system in front of me. Around engines, there is an old saying: “There’s no replacement for displacement.” In programming, however, adding more code rarely gives me the same promise. Sometimes the best improvement actually comes from removing a few lines, choosing a better algorithm, or avoiding work that has already been done. Memoization fits that last idea: keeping a useful result available instead of repeating the calculation. This archive serves a similar purpose in my learning, preserving the reasoning behind a solution so I have something to build on the next time I encounter a familiar problem.

When something breaks, I try to understand why before moving on. Getting the program working again matters, but I also want to know what caused the problem. Was I misunderstanding how a function behaved? Was I making an assumption about the input? Had I changed something without considering where else it was used? Answering those questions makes the fix useful beyond that one situation. There is a temptation to move quickly once an error disappears, especially after spending a long time trying to solve it. But pausing to explain the solution helps me check my understanding. If I cannot describe why the change worked, there is probably still something worth investigating. Even a brief note about the cause can give me something to return to later.

I am also learning to recognize when a problem needs to become smaller. If an entire program feels overwhelming, I can focus on one function or test one piece of logic. If a layout is not working, I can examine one section before adjusting the whole page. A smaller problem is easier to navigate through, and what I learn from it often helps me understand better the larger one.

Progress often comes from those small steps: understanding a function, simplifying a layout, or choosing a data structure that better fits the task. Sometimes it means recognizing an error sooner than I would have before, or being able to explain code that once confused me. Those changes certainly are easy to overlook, but they show that the time spent learning is making a difference.

“Goals are good for setting a direction, but systems are best for making progress.” ²

Making room to learn means allowing enough time for that process. I want to keep building projects, while also giving myself the chance to understand the decisions behind them. Each problem I work through adds to the experience I can bring to the next one.

Building Forward

This archive is a place to record that process—the projects I work on, the choices I make, and the lessons I want to carry into the next project. I want to share how those projects take shape, including the challenges that require another attempt and the decisions that become clearer with experience.

Since diving headfirst into C++, I have continued expanding my knowledge of C, C#, Python, Java, and JavaScript. Learning across these languages gives me opportunities to revisit familiar concepts from different perspectives. Each one introduces its own conventions and ways of solving problems, helping me become more thoughtful about how I structure a program and approach a task. Alongside that programming knowledge, I am developing my skills in HTML and CSS to build and refine experiences on the web. Working on my website gives me a practical place to connect structure, appearance, and behavior. HTML shapes the content, CSS controls its presentation, and JavaScript adds interaction. Bringing those pieces together helps me understand how individual decisions affect the finished experience. Git has also become part of my development process. Tracking changes gives me a clearer history of how a project evolves and allows me to revisit earlier decisions. It encourages me to approach changes more deliberately and builds a foundation for working with others as I continue developing my skills.

My learning has also extended into cloud computing and IT service management through earning my AWS cloud certification and ITIL 4 certification. Studying these areas has broadened my perspective on what it takes to support software beyond writing it. I am learning to consider the infrastructure it depends on, the services it supports, and how technical work connects with the needs of the people and organizations using it. “We have the technology.” A detail I photographed in a coffee shop in Hailey, Idaho—a fitting reminder as I learn what I can build with it.

Together, these areas of study are helping me develop a broader understanding of software development. I am still building experience with each technology, and I want to keep turning that knowledge into practical work. Projects give me the opportunity to discover where my understanding is strong and where I need to spend more time.

“Experience is what you get when you didn’t get what you wanted.” ³

That idea connects with what I want Memoization to preserve. At times, I fall short of what I aim for, but those attempts can still teach me something useful. Recording what happened, why it happened, and what I would change helps me carry that experience onwards.

As I continue learning, my goal is to create with care and purpose. Memoization is my way of keeping a record of that effort—giving each lesson a place to live and a chance to inform whatever I build next, one line at a time.