Drafts of the Mind #1

Hello,
Today, I’m starting a new series where I share my own thoughts.

Recently, I’ve been reading many articles, blog posts, and news pieces. While reading them, I often feel they don’t reflect real human thinking, because most of them are written by AI. There’s no real person’s emotions or ideas behind that kind of content. Yet when we look at the titles or how they’re written, they look like they were created by professionals in the subject. But that’s not true.

I also realized that I use AI quite a lot myself. I’ve even published a few articles completely written by AI. Those were very easy to create because they didn’t require any real ideas or skills. Anyone can produce something with AI. There’s no need for effort or experience. But when you fully rely on AI to produce something, you probably face a quality problem.

And that’s where my realization started. If I use AI for all my work, then AI can easily replace me. Because the things I produce wouldn’t really belong to me, they wouldn’t include my thoughts.

I’m not saying my thoughts are always better or more accurate than AI’s. But at least they’re mine, not AI’s or anyone else’s.

Finding My Own Voice

This realization made me think about my creative process.
If I don’t want AI to replace my thoughts, I need to learn how to express them better. To make it possible, I decided, I will publish new posts almost every weekday.

But expressing real ideas is not easy, especially when your knowledge is limited or your confidence is low. Sharing unclear or incomplete thoughts publicly can even feel risky. When I decided to start sharing my knowledge and ideas, I noticed my skill set wasn’t strong enough yet.

My knowledge is limited, that’s why I don’t have many ideas to share. And since English isn’t my native language, I often feel I can’t express everything clearly. These are my current limitations.

Still, the best learning method I’ve ever heard is “learning by doing.” That’s why I want to show my work while learning new things.

At the beginning, I’ll mostly share what I read and what I learn while doing my job. Over time, I hope to find my voice. Then it will be easier to produce new content. Until then, I’ll probably publish some imperfect posts, and I apologize in advance for them. But I believe I’ll find my voice with your constructive feedback.

During this process, I’ll use AI to challenge my ideas or improve clarity, but I don’t want to create entire articles with AI.

The Purpose of This Series

Basically, I want to build my own thoughts.
I want to develop my own opinions on different topics and take a side in conversations.

To make this possible, I decided to read books, articles, and other materials, and write down my reflections as I go.

Let’s Get Started

Today, I started reading Designing Data-Intensive Applications. The first chapter is about reliable, scalable, and maintainable systems. Most developers already know these terms, but the book explains them very clearly to keep readers on the same page before diving into later chapters.

In this post, I’ll focus only on reliable systems. In the next posts, I’ll continue with scalable and maintainable applications.

What Is a Reliable System?

According to the book, a reliable system continues to work correctly even when things go wrong.
In short, reliability means being fault-tolerant or resilient.

In a software ecosystem, faults always occur. They can’t be completely prevented. But to build a reliable system, we must design it so that it can tolerate some faults. Of course, we can ask: is it possible to build a system that tolerates every fault?

As you know, that’s impossible. We can only build systems that tolerate certain types of faults, not all of them. That’s why we often call such systems resilient systems.

If we can’t tolerate or prevent faults properly, our system starts to deviate from its specification and eventually fails to respond correctly to users. That’s what we call a failure.

Why Can’t We Always Build Reliable Systems?

There are many reasons why we can’t always build reliable systems.
Hardware faults, software bugs, and human errors are always part of the process.

A system might work perfectly under current conditions but fail when requirements change. When developing a system, we make assumptions, often about the future. For example, we might assume our system can handle up to 10,000 users asynchronously, or process 100 TB of data in ten minutes.

But when those assumptions change, our reliable system can suddenly become unreliable. That’s why we can’t design systems that stay reliable in every possible situation.

However, to meet our requirements well, we can design fault-tolerant systems that work under certain assumptions. As developers, we should always be aware of these assumptions while building the system.

If we don’t know them, our system becomes unpredictable, especially when circumstances change.