A Bit About Me ????

Welcome to my technical/non-technical sharing on Dev.to! I’ve been making a living as a software engineer (with stints as a product owner and tech lead) since 2016. I gained most of my experience in startups—full of challenges, but every struggle was worth it.

In this space, I'll share my thoughts on software engineering and the tech industry—covering both technical insights and the broader business aspects.

This is my first technical blog—or technically, my second. I wrote one before but deleted it because I didn’t think it was good enough. ???? I do use AI tools to help refine my writing—rephrasing, proofreading, and improving clarity—since English is not my native language. But the core ideas in every post are mine, based on real-world experience in the tech industry.

Why I’m Writing on Dev.to ✍️

1️⃣ For my future self—so I can look back and see how far I’ve come.

2️⃣ For others on a similar path—sharing what I’ve learned along the way.

3️⃣ For my future colleagues/partners—so they can understand how I think about software engineering.

That said, these are not my final opinions. Ideas evolve—especially in this AI-driven era—so my thoughts will too.

Take everything with a grain of salt. ???? If you have different opinions, feel free to challenge them! I don’t know how long or how often I’ll be sharing here, but for now, I have the motivation, so… I’m just going with the flow.

Alright, enough intro—let’s dive in. ????

Complexity Enlightenment ????

Today, I reread A Philosophy of Software Design by John Ousterhout.

Right in Chapter 1: Introduction (It’s All About Complexity), this paragraph hit me hard:

"This means that the greatest limitation in writing software is our ability to understand the systems we are creating. As a program grows and adds new features, it can become complex. This complexity arises from the hidden connections between its parts. As systems grow, they become more complex. This makes it difficult for programmers to remember everything when making changes. This slows down development and leads to bugs, which slow development even more and add to its cost. Complexity increases inevitably over the life of any program. The larger the program, and the more people that work on it, the more difficult it is to manage complexity."

Reading this paragraph summed up all the struggles my past teams and I faced. It captured the essence of our frustrations.

When reading technical books, some sections we skim, and some we digest slowly. I’m sure I read this paragraph before, but this time, it hit differently. Maybe some realizations only come with experience.

The funny thing is, I’ve also read Sandi Metz’s books (since my background is Ruby on Rails). She frequently talks about complexity. But truly understanding complexity? That takes time and firsthand experience.

How I Experienced Complexity in Startups ????️

The most common pattern I’ve seen in previous startups goes like this:

1️⃣ At the start, we ship code fast.

2️⃣ Over time, things start slowing down.

3️⃣ Adding new features takes longer and longer.

4️⃣ We scale fast, but our codebase wasn’t built for change (we wrote it just to “make things work”).

5️⃣ We end up fixing more bugs than building new features.

6️⃣ Business teams start asking: “Why did things slow down? It was fast in the beginning!”

7️⃣ Guess who gets blamed? Software engineers. ????

Yes, developers play a role, but the real culprit is complexity and dependencies. I’ve seen this pattern repeat in most startups I’ve worked with. The only exceptions? Startups that failed too early—before complexity had time to emerge.

Of course, there are patterns, best practices, and conventions to help control complexity, and I’ll share my experiences with them in future posts.

But here’s the catch: Tools alone don’t solve complexity. Used blindly, they can make things worse.

???? One extra class, method, or design decision might add hidden complexity that bites us later.

The One Question I Now Ask Before Committing Code ????

Before I commit my code, push it, and call it a day, I ask myself one question:

???? Am I reducing complexity for the codebase/team, or am I adding more complexity?

This has become my main guiding principle before even thinking about a solution.

Final Thoughts & What’s Next ????

Additionally, technical decisions should align with business goals. At the end of the day, what’s the point of a technical solution if it doesn’t solve a business problem?

In startups, every decision directly affects how fast we move, adapt, and survive.

For my next posts, I’ll dive into how I handle complexity in real projects.

I’d love to hear your thoughts—drop a comment below! ???? ????