Forem: Alam Asy'arie

HtDP Helped Me Discover DDD Without Ever Mentioning It

Alam Asy'arie — Mon, 05 Jan 2026 11:54:43 +0000

I have never read Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. I had only skimmed a few articles about it, which felt abstract and disconnected from actual programming. Even after revisiting some of the most popular DDD articles, I found many of them overly complex or exaggerated. HtDP clarified these ideas for me in a way that no article could.

Language Is a Tool, Not a Goal

Many beginners—including myself—start their programming journey by asking: "Which language should I learn?" Python? JavaScript? Go? This often leads to focusing on syntax over actual problem-solving—a distraction from what truly matters. What matters more is the thinking framework for using those tools to solve real problems.

Consider someone learning carpentry by mastering the use of saws, hammers, and planes without understanding construction principles or reading blueprints. They may cut wood neatly, but they will not be able to build a solid house. Programming works the same way: mastering a language first is not the best approach when learning to program.

The Often-Forgotten Order: Data → Program → Solution

Program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills.

Just as in solving a math problem, we first identify what is given and what is being asked before attempting the solution. The same discipline applies in How to Design Programs. In math, this is known as structured problem solving; in HtDP, it is called systematic design thinking.

HtDP teaches something radical: before writing code, define your data (the "given"). This is not merely about specifying types like int or string; it is about understanding the structure of information in the domain and representing it in the chosen programming language. The order taught by HtDP is:

Data Definition – What information are we dealing with? How does its structure reflect the real world?
Program – How do we process or transform this information?
Solution – The concrete implementation that solves the problem.

Notably, the first stage says nothing about programming languages. Its focus is understanding the domain itself.

Itemization: A Gateway to Semantics

One concept from HtDP is itemization. Initially, it seems simple—representing data that can take several possible values—but the deeper you study it, the more profound its implications.

How does itemization differ from enumeration? Enumeration is a closed, fixed list of values, such as days of the week. Itemization, on the other hand, is a way of representing all possible forms or cases of a data type, allowing programs to handle every scenario in the domain.

For example, consider an Order that can go through several states: Init, Delivered, Done, and Cancel. At first glance, one might treat these states as an enumeration—a simple list of possible values. However, when we apply itemization, we recognize that Cancel is not just another fixed value. It represents a branch in the domain where additional information might be required, such as who canceled the order, when, and why. Unlike Init or Done, which are straightforward, Cancel carries contextual data that cannot be captured by a simple enum.

This illustrates why itemization is more than a fixed list: it encourages us to model all variations and structures within the domain, ensuring our program can handle every case meaningfully. Enumeration is static; itemization is domain-aware and extensible, reflecting the real-world complexity of the system we are modeling.

Data Definition as a Bridge to the Domain

Well-defined data is not merely a technical concern; it captures the essence of the problem to be solved. We translate real-world concepts—with all their complexity and nuance—into structures that computers can understand and process.

This is precisely what DDD emphasizes: deep understanding of the domain, collaboration with domain experts, and creating models that reflect domain knowledge. HtDP introduces these principles at a fundamental level, long before the complexity of enterprise systems arises.

Returning to Fundamentals

My experience with HtDP reminded me of the often-overlooked power of foundational literature. How to Design Programs is not “old” or “theoretical.” It shapes thinking in a way that endures, regardless of programming languages or trendy frameworks.

Languages change, frameworks come and go, but the ability to understand a problem, define data precisely, and build elegant solutions—that is what distinguishes a good programmer from someone who merely writes code.

Start with the problem. Understand your domain. Carefully define and refine your data through itemization. Only then write your program. That is the lesson of HtDP, which, without realizing it, embodies the essence of Domain-Driven Design.

See you until the next discovery.

Learning Programming as Paying Debt, Not Investment

Alam Asy'arie — Wed, 31 Dec 2025 16:36:20 +0000

It is the end of 2025.

More than two years have passed since I started learning programming on my own through the internet. And like the years before, I still feel as if I have made no real progress.

Why does it feel that way?

I think the answer is simple: for a long time, I did not have a clear unease—no concrete reason for what I wanted to do with programming itself.

So I want to trace this back.

Why did I choose to learn programming in the first place?

Raison 'd etre

When I was a child, I experienced something close to existential anxiety. I often wondered about my own existence—why I was here, how the world worked. Then one day my parents gave me a game console.

I saw games as miniature worlds.

And I was shaken.

Game creators, in my eyes, had control like gods. They defined rules, physics, rewards, and consequences. A complete world emerged from intention.

Years later, in junior high school, I encountered a computer for the first time. I am 37 now, so I still remember what it felt like: inserting a floppy disk, typing commands, and suddenly gaining access to something powerful.

I was shaken again.

Somehow, I felt there was a connection between games and computers. At the very least, they both shared a screen—but intuitively, I sensed something deeper. From that moment on, I wanted to understand computers the same way I wanted to understand the world.

By the end of high school, that desire had not faded. At the time, computer science was a highly sought-after major. Many parents wanted their children to study it.

But university required money. I was the first child, and my parents were still struggling financially. For three years I tried to save enough to enroll, and for three years I failed. Eventually, I gave up. Slowly, the idea of programming slipped out of my life.

When we are young and broke we tend to forget our deepest curiosities just to survive.

Déja vu

Years later, a random video appeared on my YouTube feed: a roadmap to becoming a web developer. I watched it.

And I was shaken once more.

I realized something fundamental had changed. Access was now open. Anyone could learn—without formal education, without permission. The cost, however, was direction. You could learn anything, but you might not know why.

I jumped in enthusiastically. HTML, CSS, then JavaScript. At first, everything felt exciting. But HTML and CSS quickly bored me, and JavaScript felt like an endless maze.

Days turned into months. Months into years. I kept learning, yet the result felt like nothing. Not because I learned nothing—but because I felt stuck in the same place.

I fell into tutorial hell.
I jumped between languages and roles.
I watched others who started at the same time move faster, build more, achieve more.

Only much later did I realize the real problem. I was learning without direction. And more importantly, I was learning for the wrong reason.

My motivation was never to build products. I wanted to understand what was inside a computer—how something so seemingly lifeless could exhibit god-like power. I wanted knowledge, not output.

Rénaissance

This is where the idea of debt becomes clear to me.

Learning programming, for me, is not an investment aimed at future returns. It is the repayment of a debt from the past—a debt created when I wanted to learn computers but could not.

Whether this journey leads to a job or not is secondary. What matters is that the debt is paid: that I finally know the computer.

Employment, if it comes, is a side effect. Joke aside, I want my path to be more functional—so I intentionally ignore side effects.

So in 2026, I am starting over—not from zero, but with a corrected direction. I will treat curiosity as my currency. Not portfolios. Not market demand. Curiosity only.

I have chosen a curriculum that feels honest and solid: teachyourselfcs, with selective additions from Open Source Society University.

OSSU, in full, feels too heavy for me. Instead, I will focus on TYSCS combined with How to Design Programs and Concepts, Techniques, and Models of Computer Programming from OSSU's reading material. Both books genuinely interest me.

There is a saying: a man’s life begins at 40.
So my deadline is two years.

By the time I turn 40, I hope to have completed this journey and my debt will have been fully settled.

Even if I do not finish everything, completing HtDP, SICP, CSAPP, and CTMCP would already feel foundational. CS:APP alone might be enough to understand how an iron box becomes a world. But the other books address something deeper—how to think, not just how to build.

It is often said that programming is about create something, not what you learn. That statement is correct—very correct. But in my case, the priority is different. I want to understand before I create. I am not interested in playing God yet.

That is why writing essays makes more sense for me than building portfolios. Essays externalize understanding. They force clarity. They turn vague intuition into articulated thought. Writing is how I will prove—to myself—that the debt is being paid.

This essay marks the beginning of my two-year journey.

If there is something worth sharing along the way—something I truly understand—I will write again.

Happy New Year’s Eve 🥳