DEV Community: Tien Do

Discipline Can't Beat Environment — Design It Before Willpower

Tien Do — Wed, 19 Aug 2026 21:58:02 +0000

I used to think I had strong enough discipline to beat my environment. I don't. The evidence is mine: bring my phone into the bedroom, and I'll always find a reason to reach for it — reading about Buddhism, a programming concept, a podcast with some distinguished engineer. All good reasons on their face. All disturb my sleep and keep my mind in work mode instead of rest mode.

Same pattern after work. I'd tell myself: stop learning at 9 pm, go to bed. One more hour creeps in, then another. Yes, that extra hour makes me more productive in terms of output. But I pay it back — always. The environment is part of me, and my habits just reflect that environment. Self-development books say this constantly. I read it, agreed with it, and still thought I was the exception — that my willpower could override it. I was wrong. This is not a fair game, and losing to it is just a matter of time.

I did try changing the environment: phone further from the bed, hard stop at 9 pm, phone off during work. It didn't last — I got overconfident, decided I didn't need the guardrails anymore, and relapsed.

What's helping me understand why now comes from studying Buddhism seriously over the past three weeks — reading and working through difficult concepts with AI. I used to misread sīla (giới) as a negative constraint, a rule that forces you to fight and suppress your emotions. That's wrong. The reason the Buddha taught not to break sīla — to reduce the chances of breaking it — is that otherwise you spend significant time dwelling on it in your mind, and if your mind is dwelling on it, you can't meditate. If you can't meditate, you don't get to wisdom. That's why it's Giới, Định, Tuệ, in that order — Giới first.

This applies to idle time too. When I have free time, and my mind gets bored, the default reflex is to reach for the phone, the laptop, the digital world. So now, instead of reaching, I ask: what's the simplest thing I can do right now to simplify my current environment, so this bad habit has less room to arise? I keep asking that question and acting on it — again and again — until the environment is shaped enough that the habit is almost impossible to trigger.

It's the same with environment. The point isn't to build a stronger will to resist bad habits once they arise. It's to design the environment so those habits have less chance to arise in the first place.

I stopped trying to be consistent

Tien Do — Wed, 19 Aug 2026 17:34:26 +0000

This isn't advice. I'm not saying anyone should agree with this or do it my way — just sharing where I landed.

For a long time, when I thought about productivity, I thought about mastery. If I wanted to learn a functional programming language, I should become a master of it. Same for any other subject. That mindset did work, at first — it pushed me to actually start. But then I'd stop, long before reaching expert level, and feel like I'd failed.

So I read productivity and self-development books. They all said the same thing: consistency is what matters. Show up daily. I got a new wave of motivation from that and tried it. I did it for a while. Then I stopped. I figured something was wrong with me — I was lazy, overwhelmed, trying to do too many things at once.

Now I think it wasn't that simple. I don't think I need to be consistent. It's fine to follow my need and energy on a given day. Today I felt like writing and sharing on dev.to again, after a year away, so I just did it.

I'm not worrying about whether I'll keep it up tomorrow, next week, or next month. Tomorrow hasn't happened yet. And if I stop sharing again for another year, or never write again — that's fine too. I'm not going to force myself into some unnatural commitment about what I must do in the future. We're not fixed. We change, things change, priorities shift.

Same thing with learning anything — writing, a new programming language, whatever. I've stopped obsessing over becoming an expert. I learn because I need to, or because something triggers me to at that moment. And this time, I don't overwhelm myself by taking on many things at once, or reading multiple books on the same subject before I've even grasped the fundamentals. Learning only actually happens when I apply it and reflect on it in the real world.

I do use an AI agent to help with the writing — it asks me questions and helps pull the ideas into something coherent. But the thoughts are mine.

Why Elm, and How I'm Learning It in the Age of AI Agents

Tien Do — Wed, 19 Aug 2026 17:01:32 +0000

I watched a JetBrains interview with Zig's founder. He talked about keeping the project to a small number of trusted contributors — fewer than ten — specifically because it's now easy for an open-source project to get flooded with low-quality AI-generated pull requests that waste a small team's review time. My first reaction was that this could tip into one person dictating the whole vision. But as I've grown as an engineer, I don't think that's necessarily bad — if the founder's instinct is toward simplicity and not bloated features, it can work well. I see the opposite every day in my Rails job: people over-engineering, abusing gems and metaprogramming to make simple problems complicated.

I started learning Zig with Claude Code. Somehow, that reawakened my old attempts at learning functional programming — Haskell, Elixir, Clojure, Scala, all of which didn't stick — and I decided to stop Zig and go back to FP instead.

This time I picked Elm. I looked for the simplest FP language with skills that transfer to my day job as a Rails engineer, and to other languages I want to learn later — Rust, Go, Zig, Odin. I was intrigued by Elm's famously good compiler errors and want to bring that lesson back to Rails. Elm's model-update-view architecture — the one Redux and other JS frameworks borrowed from — is interesting too, but not the main reason. The real reason: Elm's GitHub repo basically stopped growing years ago, because its founder decided it was enough. That resonates with the simplicity mindset I've grown into — knowing when to stop, remembering why you started, even if it upsets people who want more. That kind of restraint feels rare, and more valuable now, in the age of AI agents.

How I'm learning it: not syntax first. I've loved video games since I was 18 or 19 — that's part of what got me into software in the first place — so I'm building a Space Invaders clone in Elm with Claude Code, no external assets, all of it generated as SVG by code, with interactive HTML explanations along the way to teach transferable concepts.

After a while I felt I needed more grounding, so I went to Exercism — three or four Elm exercises in so far. It's good for strengthening a TDD mindset, the same mentality I already use at my Rails job. I built my own AI skill for it: the agent has to ask me questions instead of writing the solution, and I write the code myself to pass the spec — otherwise I don't actually learn anything. I baked "stay focused on transferable functional programming concepts" into the skill itself, so the agent doesn't drift from that. I'm not trying to solve all 100+ exercises — just enough to grasp it, then back to the game.

One idea for later: clone a well-structured open-source Space Invaders repo, in any language, and have the AI agent extract the useful Elm/FP lessons from it — not copy everything, just enough.

Going Back to Functional Programming, This Time on Purpose

Tien Do — Wed, 19 Aug 2026 16:15:46 +0000

I'm going back to learning functional programming. I've tried before — Haskell, Elixir, Clojure, Scala, books like Grokking Simplicity — and it didn't go well.

Looking back, I mostly read and jumped between resources instead of writing code and sticking with one language. I picked Haskell partly because it's hard, and some part of me wanted people to think I was a good engineer for understanding it. I kept looking for "exciting" projects instead of practicing on ordinary ones, because ordinary bored me — that was ego and dopamine chasing, not a learning plan. I also told myself functional programming had little value for a Rails engineer, which wasn't even true — Rails uses blocks and lambdas functionally all the time — though that wasn't the main reason I quit.

Why now: AI can generate about 80% of my code quickly, and quite well — maybe partly because Ruby/Rails is well represented in AI training data compared to less popular languages. It's easy to lose touch with a codebase and stop knowing what you're actually doing as an engineer when that much of the writing happens for you. I've also reached a point with OOP where I don't think I can improve much further on my own right now — I'm still learning it, still far from expert, but the pace has slowed.

This time the goal isn't to become an expert in functional programming. It's to actually understand what problems it solves and what problems it creates.

I'm not against AI agentic coding — I spend real time daily improving my own agentic workflow. This is separate from that.

When I Use AI — And When I Don’t

Tien Do — Mon, 12 May 2025 12:44:20 +0000

AI helped me ship faster, but it didn’t always allow me to ship better. Over time, I learned to separate speed from clarity and to use AI with more intention, not more dependence.

I started using ChatGPT in late 2022, right after getting laid off. With no job, I had time — so I talked to it constantly. Some days, I spent 5–6 hours experimenting. Ideas bounced back and forth.

At first, everything felt smooth. No red flags yet.

After landing a new job at another startup, I integrated AI into my coding workflow. It felt like magic. Snippets, tests, and scaffolds appeared instantly. I called it my tireless junior dev.

But a few weeks in, I noticed something off: I was shipping more but thinking less. Worse — I felt detached from the codebase.

I used AI to refactor code, build new features, generate controller logic, mock APIs, and especially write RSpec tests. It saved me hours. I enjoy TDD, so I didn’t want to outsource that part — but I had to admit, the output was decent. Part of that came from my prompting skill — I’d spent months sharpening it during unemployment.

On the surface, things looked efficient. PRs moved quickly. I felt productive. But the longer I used it, the more invisible costs started to show.

🚨 Problem 1: Fixing AI output took time

When I used AI to generate logic-heavy code, I often spent more time fixing than writing. That’s not AI’s fault — it's about knowing when to use it, and where to trust my clarity instead. Even with multiple options, most suggestions weren’t up to my quality bar.

🧠 Problem 2: I outsourced my thinking

This one hit harder: critical thinking got slower. I realized I'd gradually handed over my problem-solving process to an assistant. It gave me the illusion that I don't have to think. I get paid to think. To solve real problems. Not to polish suggestions from a prediction engine.

⚡ Problem 3: I became less patient

AI gave me instant answers and I started expecting instant progress. I’ve never been perfectly patient. But, before AI, I at least respected the time it took to solve hard problems. With AI, I got frustrated faster. The illusion of speed trained my brain to expect shortcuts. And when the dopamine stopped, so did my tolerance for difficulty.

📉 Real-World Consequences

When we use AI without thinking clearly, small problems pile up fast:

Code looks like suggestions, not real decisions
Debugging gets messy — nobody fully understands what the code is doing
New teammates have to guess what’s going on
You start to feel disconnected from the work

AI helps move fast, yes. But if you're not careful, it also helps you get lost faster.

🛠 What I Do Now

After another layoff (at the time of writing), I took a step back, not to quit AI, but to rebuild how I think with it.

I went back to basics: pen, editor, whiteboard. Tools that slow me down just enough to reconnect with the thinking process itself.

I still use AI — just differently now:

Dummy data
JSON scaffolds
Boilerplate test helpers
...

But for core architecture, debugging, or solving hard logic, I slow down and use my brain first. If I bring AI in, it’s as a sparring partner, not the driver.

🧭 Final Thoughts

AI isn’t bad. But full dependence is.

Google helped. Stack Overflow helped. Social media helped. But overused? They made us distracted. AI just scales that effect.

So now, I ask myself:

Does this tool increase clarity?
Or does it let me avoid thinking?
Could I still solve this without help?

Try going AI-free for a week — not as a protest, but as a test.
Watch how your brain responds. Track how often you revise AI output vs. your own. Is speed giving you clarity? Or just comfort?

Tools will evolve. AI will stay. But clarity — that’s on us.

I’ve made these mistakes too. That’s why I’m setting better boundaries. Still improving. Still figuring it out — like everyone else.

3 Real-World Refactoring Principles That Help Me Tame Complexity in Startup Codebases

Tien Do — Sun, 20 Apr 2025 07:41:54 +0000

In my previous post, I talked about software complexity.

One principle I consistently follow is:

👉 “The code I touch should be easier to understand and maintain than before—unless I’m writing it from scratch.”

I always start with the smallest unit in OOP—which, coming from a Ruby background, is the function.

To me, a function is the most fundamental building block of a class. Even if a class is 1,000+ lines long, the codebase is still workable if its functions are clear and well-structured. At the very least, it becomes easier to refactor in the future.

In this post, I want to share three principles I use to write clean, maintainable functions:

1️⃣ `Keep It Short (Lines of Code)`

In Ruby, it’s idiomatic to keep functions short.

When I was a tech lead, I often set a soft limit of 10–12 lines per function. But depending on the team’s experience level, that might be too strict and slow the team down.

A practical compromise I’ve found:

20 lines is a reasonable maximum.

It keeps functions simple, readable, and maintainable—without introducing unnecessary friction for the team.

📌 Example: Before & After

Before: A long, hard-to-scan function mixing multiple behaviors

def process_payment(user, order_id)
  order = Order.find(order_id)
  raise "Order not found" unless order

  payment_gateway = PaymentGateway.new(user.payment_token)
  payment_result = payment_gateway.charge(order.amount_cents)

  if payment_result.success?
    order.update!(status: :paid, paid_at: Time.current)

    AnalyticsLogger.log_payment_success(user.id, order.id)

    NotificationService.send_payment_confirmation_email(user, order)

    if user.referral_code.present?
      reward_service = ReferralRewardService.new(user.referral_code)
      reward_service.process_reward_for(user)
    end

    SendThankYouGiftJob.perform_later(user.id) if order.amount_cents > 100_000
  else
    order.update!(status: :payment_failed)
    ErrorTracker.notify("Payment failed", user_id: user.id, order_id: order.id)
  end
end

After: Refactored with clarity, separation, and single-purpose focus

def process_payment(user, order_id)
  order = Order.find(order_id)
  raise "Order not found" unless order

  if charge_order(user, order)
    handle_successful_payment(user, order)
  else
    handle_failed_payment(user, order)
  end
end

def charge_order(user, order)
  result = PaymentGateway.new(user.payment_token).charge(order.amount_cents)
  return false unless result.success?

  order.update!(status: :paid, paid_at: Time.current)
  true
end

def handle_successful_payment(user, order)
  log_payment_success(user, order)
  notify_user_of_payment(user, order)
  reward_referral_if_applicable(user)
  send_thank_you_gift_if_high_value(user, order)
end

def handle_failed_payment(user, order)
  order.update!(status: :payment_failed)
  ErrorTracker.notify("Payment failed", user_id: user.id, order_id: order.id)
end

def log_payment_success(user, order)
  AnalyticsLogger.log_payment_success(user_id: user.id, order_id: order.id)
end

def notify_user_of_payment(user, order)
  NotificationService.send_payment_confirmation_email(user, order)
end

def reward_referral_if_applicable(user)
  return unless user.referral_code.present?

  reward_service = ReferralRewardService.new(user.referral_code)
  reward_service.process_reward_for(user)
end

def send_thank_you_gift_if_high_value(user, order)
  return unless order.amount_cents > 100_000

  SendThankYouGiftJob.perform_later(user.id)
end

2️⃣ One Reason to Change

A function should have only one reason to change. This aligns with the Single Responsibility Principle.

A quick test:

Ask yourself, “What does this function do?”
If the answer includes “and” (e.g., “It charges the user and sends a confirmation email”), it’s doing too much.

In the original example, the process_payment function had several reasons to change:

Payment logic

Logging behavior

Notification flow

Referral rewards

Async background jobs

Now, each function focuses on just one behavior, making changes easier and less risky.

3️⃣ Consistent Level of Abstraction

This one’s subtle but powerful.

If a function mixes different levels of abstraction, it becomes mentally exhausting to understand.

In the original version, the function:

Accessed the database (low-level)

Called an external payment API (infrastructure)

Applied business rules (mid-level)

Sent notifications (I/O)

Triggered background jobs (infra)

That’s a lot of context-switching in one place.

In the refactored version:

The main function (process_payment) stays at the orchestration level

Each helper function stays at a consistent “altitude”, making the whole flow easier to follow and evolve.

I’d love to hear your thoughts.
What principles do you follow to keep your functions clean and maintainable?
Let’s discuss 👇

First post and complexity in software engineer

Tien Do — Sun, 23 Feb 2025 23:44:45 +0000

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! 👇 🚀