Minimalism in Code and Life

Minimalism in Code and Life

I like the idea of simplicity and minimalism. Although, to be candid, I only follow these disciplines loosely. My goal, however, is always to reduce the amount of complexity in everything I do. The idea of a minimalist-like life is enticing. It attracts me because I know that owning fewer things means less stress and fewer things to worry about. This is why I like the idea of simplicity and minimalism, and please be aware that I use both terms interchangeably.

The first time I heard about minimalism was many years ago, likely in an article about architecture. It described minimalism as a way to build and lay out a living space. At first, I didn’t know what it meant, but after some exposure, I understood it to mean a simpler design: a place without clutter, with clean lines and open areas, and fewer but functional pieces of furniture. That’s how minimalism was presented in that context.

This idea of minimalism can be applied to many aspects of life. In this post, I’d like to write about how simpler systems, design, and processes can often be better than the alternative—even though simplicity can be difficult to achieve. In most cases, making something simple requires a lot of work and intentionality. Achieving minimalism or simplicity is not simple—at least not for me.

In software development, avoiding complexity is a constant goal. But the opposite also happens: “best practices,” FOMO, vanity, or the desire to follow trends push many software engineers and teams to adopt unnecessarily complex tools and infrastructure. There’s also the urge to build something future-proof and “scalable,” which is what we in the industry call premature optimization.

Avoiding this isn’t easy, especially in large corporations where ignoring certain guidelines might seem unsafe, naïve, or even rebellious. However, the tools, infrastructure, and overall complexity should be based on the application’s needs and expected usage. Misunderstanding this often leads to poor project estimates. That’s why starting simple and expanding only when necessary is a good approach. There are tools that help with this. For example, in software engineering, we can apply the divide and conquer algorithm to break down complexity into manageable parts.

A common example of teams choosing complexity over simplicity is in tool selection, whether it’s a piece of infrastructure, a framework, a programming language, a database technology, or even an LLM, since those are widely used now.

There’s nothing wrong with adopting new tools. In many cases, a new framework can abstract away some complexity and make development easier and more enjoyable.

For example, I remember when Bootstrap was released in August 2011 by Twitter developers Mark Otto and Jacob Thornton. Originally called Twitter Blueprint, it was later renamed Bootstrap. It revolutionized front-end development by democratizing access to responsive UI components, allowing developers to focus more on functionality and less on tedious CSS quirks, especially valuable before modern CSS tools became mainstream.

Over the years, many tools have emerged to improve development, enhance productivity, and boost software quality. Today, even solo developers and small teams have access to infrastructure that was once exclusive to large corporations due to high setup costs. But many of these tools, especially cloud services, have been heavily marketed to convince developers that not using them puts you at a disadvantage. While they offer benefits, they also come with added complexity and cost.

If you’re a solo developer, have a small team, or are building a simple app or static website, a single server or VPS can be more than enough. Your deployment, maintenance, and costs will be far simpler than with a cloud account and a suite of services, and often more affordable, too.

Here’s a simple guideline table I created with GPT-4o:

App Type Server Type Concurrent Users (safe)
Static website (HTML/CSS) 1 vCPU / 1 GB RAM VPS 500–1,000+
CRUD app (e.g. blog) 2–4 vCPU / 8–16 GB RAM 200–1,000
Real-time app (chat, games) 4+ vCPU / 16–32 GB RAM 50–500
Media streaming or AI Depends heavily on workload Varies widely

Currently, this blog and a few of my web apps run on a self-hosted VPS on DigitalOcean. I used to host them on Azure, then AWS, but the costs were always higher. While those platforms made scaling easier, I had less control and more limitations. That was unnecessary complexity for me.

There are risks with self-hosting:

  • Downtime during traffic spikes
  • Security and maintenance burdens
  • Limited scalability without cloud features

Still, for many users and apps, it remains the simpler option.

Another area where I keep things simple is my code editor. I install only a few extensions, maybe a plugin, but overall, my setup is very vanilla. I like it that way. At work, we have access to LLM-powered extensions in editors like VS Code. I decided to try one for writing unit tests, where a lot of boilerplate is needed. It did okay, though I made several changes afterward. I know these tools will improve.

However, the extension was intrusive. It hijacked keyboard shortcuts, auto-inserted suggestions as I typed, and made coding distracting. Yes, I could probably configure it, but to me, the return on that time investment wasn’t worth it. I disabled it, and now my editor no longer gets in my way.

I enjoy simpler tools that I control and that don’t interfere with the things I enjoy, like coding or writing. For tasks I find tedious, like writing boilerplate tests or configuring a server, I welcome automation. But for creative tasks, I prefer focus and minimal distractions.

These are a few work-related examples. At home and during leisure, simplicity also plays a role. One thing I’m proud of is traveling with fewer items. I still bring a decent amount, but I’m more intentional. I never check in bags, and I usually travel with just one carry-on and one pair of shoes. That has made travel so much better.

Last year, we went to Singapore and Japan for about three weeks, with just a backpack and one pair of shoes. It was great. Same thing when we traveled to Peru. Even trips to New York City to visit our kids—one bag, one pair of shoes. I used to pack multiple pairs and multiple bags. But I realized I often didn’t use half of what I packed.

I still have many areas I’d like to simplify. A simpler life doesn’t mean missing out. On the contrary, it means fewer things but better quality, fewer experiences but more rewarding ones. I’m not there yet, but it’s a goal. I want a minimalist approach to work, life, travel, and everything in between. The goal is fewer things to manage, more space to focus on what I truly enjoy.

Like anything in life, this goal is a moving target. There’s no finish line—just an ongoing awareness and the intention to improve each day.

I hope you have a wonderful weekend!