Forem: xiaoguang_

The AI That Makes You Feel Stupid—but In a Good Way

xiaoguang_ — Tue, 07 Apr 2026 10:15:21 +0000

You’ve seen it. Every dev forum, Twitter thread, and Discord server is full of panic about AI. “GPT will take my job!” “AI is coding better than me!”

Here’s the thing: most developers are thinking about AI the wrong way. They imagine some future robot sitting at their desk, typing flawless code while they sip coffee. But that’s not what’s happening. AI isn’t a replacement; it’s a mirror. It shows you what you already do—and sometimes, how sloppy you’ve been.

For example, I once watched a junior dev spend three hours writing a function to validate emails. Then they asked GPT to do the same thing. GPT wrote it in five seconds—and made it slightly better. The panic moment? Totally understandable. But here’s the insight: the junior dev learned more in that panic than in any tutorial. They saw the gap between “good enough” and “actually elegant.”

AI is basically a magnifying glass. It amplifies the difference between average and excellent. It doesn’t replace humans who understand context, who can decide which path is worth taking, who know what “good enough” really means.

Here’s the memorable part: worrying about AI replacing you is like worrying that a calculator will make arithmetic teachers obsolete. You’ll never be obsolete if you know why you’re doing what you do.

Practical takeaway: don’t try to out-AI the AI. Use it. Let it show you where your blind spots are. Learn faster, code smarter, and spend more time on the things AI can’t touch: judgment, empathy, and creativity.

AI isn’t your enemy. It’s your fastest way to becoming the developer everyone else fears will actually replace the lazy ones.

Read with color: https://kimkorngmao.com/notes/the-ai-that-makes-you-feel-stupid-but-in-a-good-way

My Honest Take on AI Coding Tools After Months of Heavy Use

xiaoguang_ — Wed, 01 Apr 2026 10:16:32 +0000

I started using AI tools daily last year. Not as a gimmick. Not to skip thinking. Just as part of my normal workflow.

At first I was skeptical. I worried the code would feel off, or I’d lose the muscle of solving problems myself.

Turns out the opposite happened.

The tools forced me to get clearer. You can’t paste a vague idea and expect magic. You have to explain the goal, the constraints, the edge cases. That exercise sharpened how I think about problems before I even write a line.

Most days now look like this:

I sketch the logic in plain English.

I ask the AI to turn it into code.

I read every line.

I change what doesn’t fit my style or the project’s needs.

The AI writes fast. I still own the decisions.

What surprised me most was how much time I suddenly had for the parts that actually matter: architecture, user experience, performance trade-offs, and talking to the team. The boring boilerplate disappeared. The interesting problems stayed.

I also caught myself becoming a better reviewer. When the AI suggests something clever, I pause and ask why it works. When it suggests something lazy, I explain the better path. That back-and-forth improved my own judgment faster than any side project ever did.

None of this means I stopped learning fundamentals. Data structures, system design, debugging under pressure—those skills matter even more now. The AI handles syntax. I handle consequences.

Here’s the part I keep coming back to: the developers who will do well aren’t the ones who type the fastest. They’re the ones who know when to accept the suggestion, when to reject it, and when to step away from the tool entirely and think.

AI is a very good pair programmer.

It is not the architect.

It is not the product owner.

And it definitely isn’t you.

I’m curious where you stand.

Have you integrated AI tools into your daily work yet?

What changed for you—good or bad?

What’s one rule you follow to stay in control?

Drop your experience in the comments. I read every one.

Read on my site: https://kimkorngmao.com/notes/my-honest-take-on-ai-coding-tools-after-months-of-heavy-use

Why I Still Keep a Personal Website

xiaoguang_ — Tue, 31 Mar 2026 03:55:28 +0000

I didn’t build my personal website to impress anyone.

At least, not anymore.

At first, I treated it like a portfolio website.
Something to showcase work. Something to look “complete.”

But over time, that idea started to feel limiting.

✦✦✦

Most portfolio websites try to present a finished version of someone.

Clean. Polished. Final.

But that’s not how real work feels.

Things change. Skills improve. Interests shift.

So I stopped thinking of my site as a portfolio.

I started treating it more like a working space.

✦✦✦

Now it’s closer to a notebook.

A place where I can write things down.
Small ideas. Observations. Experiments.

Nothing too formal.

Just enough to capture how I think at the moment.

✦✦✦

This changed how I approach writing.

I don’t wait for a “good” idea anymore.

I just write when something feels worth noting.

Short posts help with that.

They’re easier to start. Easier to finish.
And easier to come back to later.

✦✦✦

Interestingly, this also works well for search.

Not because I’m trying to rank for keywords like personal website or portfolio website.

But because I’m writing in a way people actually search.

Simple phrases. Clear thoughts. No over-explaining.

That seems to matter more than anything else.

✦✦✦

I’ve also noticed something else.

A site that keeps growing feels different from one that stays the same.

Even small updates make it feel alive.

And that makes me want to keep working on it.

✦✦✦

If you’re building your own personal website, it doesn’t need to be perfect.

You don’t need a full portfolio on day one.

You can start with:

one page
a few notes
a simple layout

That’s enough.

✦✦✦

Over time, it becomes something else.

Not just a portfolio website.
Something more personal.

Something that reflects how you think.

✦✦✦

That’s the part I didn’t expect.

And probably the reason I’m still maintaining it.

Connect Telegram Notifications in Laravel App Quickly

xiaoguang_ — Mon, 23 Mar 2026 09:38:21 +0000

Integrating Telegram notifications into a Laravel app is a solid move. It’s faster than email and less intrusive than SMS.

Here is a streamlined way to wire it up.

1. Database and Bot Setup

First, you need a place to store the handshake between your app and Telegram. Add a telegram_id column to your users table.

Schema::table('users', function (Blueprint $table) {
    //
    $table->string('telegram_id')->nullable()->unique();
    //
});

Next, talk to @BotFather on Telegram. Create a new bot, grab your API Token, and add it to your .env file. You’ll need this token for every request your backend makes.

2. The Frontend "Connect" Button

To link a user, you need them to start a conversation with your bot while carrying their local User ID as a parameter. Using JavaScript to handle the redirect keeps the UI clean.

<button id="connectTelegram">Connect Telegram</button>

<script>
document.getElementById('connectTelegram').addEventListener('click', () => {
    const userId = "{{ auth()->id() }}"; 
    const botUsername = "YourBotUsername";
    window.location.href = `tg://resolve?domain=${botUsername}&start=${userId}`;
});
</script>

When the user clicks this, Telegram opens and sends a /start {userId} message to your bot.

Small note: When the user sends /start, the extra parameter isn’t visible on their end. They’ll just see a normal /start message in their chat.

3. Handling the Webhook

You need a controller to listen for Telegram’s ping. When the user hits "Start," Telegram sends a POST request to your app.

public function handleWebhook(Request $request)
{
    $message = $request->input('message');
    $chatId = $message['from']['id'];
    $text = $message['text'];

    // Telegram sends the start param as "/start 123"
    if (preg_replace('/\D/', '', $text)) {
        $userId = explode(' ', $text)[1];

        User::where('id', $userId)->update([
            'telegram_id' => $chatId
        ]);
    }

    return response()->json(['status' => 'success']);
}

Don't forget to exclude this route from CSRF protection in your VerifyCsrfToken middleware.

Connecting your bot to a webhook:
You can set your bot’s webhook by opening this URL in your browser (replace <YOUR_BOT_TOKEN> and your webhook endpoint accordingly):

https://api.telegram.org/bot<YOUR_BOT_TOKEN>/setWebhook?url=your_webhook_endpoint

example: https://api.telegram.org/bot123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ/setWebhook?url=https://kimkorngmao.com/telegram/webhook

Once opened, Telegram will push all messages to your Laravel controller automatically.

4. Sending the Notification

Laravel’s Notification system makes the actual delivery feel native to the framework. While you can use a community package, a simple Http call often suffices for basic alerts.

public function sendTelegramNotification($userId, $text)
{
    $user = User::find($userId);

    if ($user->telegram_id) {
        Http::post("https://api.telegram.org/bot" . env('TELEGRAM_BOT_TOKEN') . "/sendMessage", [
            'chat_id' => $user->telegram_id,
            'text' => $text,
            'parse_mode' => 'HTML'
        ]);
    }
}

A few thoughts

The start={id} parameter is the "deep linking" magic of Telegram. It bypasses the need for users to type codes manually.

Just ensure your webhook URL is secured via HTTPS, or Telegram won't talk to it. It’s a simple system, but once it’s running, the engagement rates usually beat email by a mile.

Read original: https://kimkorngmao.com/notes/connect-telegram-notifications-in-laravel-app-quickly

Laravel 13 Highlights

xiaoguang_ — Mon, 23 Mar 2026 04:04:52 +0000

Laravel 13 dropped last week. The biggest takeaway is that it’s a "zero breaking changes" release for most. It’s mostly about modernizing the syntax and embracing AI.

1. PHP 8.3 is the New Floor

Laravel 13 officially requires PHP 8.3.

Support for PHP 8.1 and 8.2 is gone.
This lets the framework use typed constants and json_validate() internally.
You get a small performance boost just by upgrading the runtime.

2. Attributes Everywhere

The biggest visual change is moving away from class properties to PHP Attributes. It's optional, but it makes models and jobs look much cleaner.

Old Way:

class User extends Model {
    protected $table = 'users';
    protected $fillable = ['name', 'email'];
}

New Way (Laravel 13):

#[Table('users')]
#[Fillable(['name', 'email'])]
class User extends Model {}

3. The First-Party AI SDK

Laravel now has a native AI SDK (laravel/ai). No more wrestling with multiple community packages to talk to OpenAI, Anthropic, or Gemini.

Features:

Provider Agnostic: Swap between OpenAI, Anthropic, and Gemini in config/ai.php without changing your app logic.
Unified API: One syntax for text, images, and audio.

Text Generation:

use Laravel\Ai\Facades\Ai;

$response = Ai::prompt('Explain quantum computing to a five year old');
echo $response->text;

Image Generation:

use Laravel\Ai\Image;

$image = Image::of('A futuristic city in the style of Van Gogh')
    ->landscape()
    ->generate();

$image->store('cities/future.png');

Creating an Agent:

Agents are classes that wrap instructions (system prompts) and tools.

namespace App\Ai\Agents;

use Laravel\Ai\Contracts\Agent;
use Laravel\Ai\Promptable;

class SupportAgent implements Agent
{
    use Promptable;

    public function instructions(): string
    {
        return 'You are a helpful customer support assistant for our SaaS.';
    }
}

// Usage:
$reply = (new SupportAgent)->prompt('How do I reset my password?');

4. Cache Management

A small but smart addition. You can now extend a cache item’s life without fetching the data first.

Old Way (Manual Refresh):

$value = Cache::get('session_data');
if ($value) {
    Cache::put('session_data', $value, now()->addMinutes(30));
}

New Way (Laravel 13):

Cache::touch('session_data', 1800); // 1800 seconds

Just "touch" the key. It resets the expiration timer directly in the cache store (Redis/Memcached) without pulling the data into PHP memory.

5. JSON:API Resources (New in v13)

Laravel 13 introduces a dedicated JsonApiResource for strict spec compliance. It handles IDs, Types, and nesting automatically.

Setup:

php artisan make:resource PostResource --json-api

It uses a declarative style instead of the old toArray() manual nesting.

Comparison:

Feature	Old Way (Manual)	New Way (v13 Native)
Structure	Manually define data, id, type.	Handled automatically.
Attributes	Mixed inside a single array.	Clean `$attributes` property.
Relations	Manual `whenLoaded` checks.	Clean `$relationships` property.

Example Code (v13):

use Illuminate\Http\Resources\JsonApi\JsonApiResource;

class PostResource extends JsonApiResource
{
    public $attributes = ['title', 'content'];
    public $relationships = ['author', 'comments'];
}

You can also use toResource() directly on a model now, and Laravel will find the correct resource class for you.

My Take

If you’re on Laravel 12, don’t stress. The upgrade is mostly a dependency bump.

The "Attribute" syntax is the future—it’s more IDE-friendly and keeps configuration right where the logic is.

If you're starting a new project, go with 13 immediately to get that AI SDK and PHP 8.3 speed.

Supabase Quick Docs

xiaoguang_ — Mon, 16 Mar 2026 06:10:36 +0000

I keep a small note when learning a new tool.

Not a full guide. Not polished documentation.

Just the syntax I actually use.

After a few projects with Supabase, I noticed the same pattern. I kept opening the docs, searching for the same things:

How to insert a row
How to query data
How to update something
How to call an RPC

So I wrote a small “quick syntax sheet”.

This is the version I wish I had when starting.

Supabase is simple once you learn the core pattern.

Almost everything follows this shape:

supabase
  .from("table")
  .operation(...)

If you remember that, the rest becomes predictable.

Setup

Create a client first.

import { createClient } from "@supabase/supabase-js"

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
)

That’s it.

Now every database call starts with supabase.

Select (Read Data)

The most common query.

const { data, error } = await supabase
  .from("posts")
  .select("*")

You’ll probably write this line hundreds of times.

Select specific columns

.select("id, title, created_at")

Example:

const { data } = await supabase
  .from("posts")
  .select("id, title")

Filter rows

.eq(column, value)

Example:

const { data } = await supabase
  .from("posts")
  .select("*")
  .eq("author_id", user.id)

Other common filters:

.eq()   equal
.neq()  not equal
.gt()   greater than
.lt()   less than
.like() pattern match

Get one row

.single()

Example:

const { data } = await supabase
  .from("posts")
  .select("*")
  .eq("id", postId)
  .single()

Insert (Create Data)

Insert is straightforward.

const { data, error } = await supabase
  .from("posts")
  .insert({
    title: "\"My post\","
    content: "Hello world"
  })

Multiple rows:

.insert([
  { title: "\"Post 1\" },"
  { title: "\"Post 2\" }"
])

Return inserted data

Add .select().

const { data } = await supabase
  .from("posts")
  .insert({ title: "\"Hello\" })"
  .select()

Useful when you need the new id.

Update

Update rows with a filter.

const { data, error } = await supabase
  .from("posts")
  .update({ title: "\"Updated title\" })"
  .eq("id", postId)

Without a filter, it updates every row.

That’s a mistake most people make once.

Delete

Delete also requires a filter.

await supabase
  .from("posts")
  .delete()
  .eq("id", postId)

Again, no filter means deleting everything.

Ordering

Sort results.

.order("created_at", { ascending: false })

Example:

const { data } = await supabase
  .from("posts")
  .select("*")
  .order("created_at", { ascending: false })

Limit

Limit rows returned.

.limit(10)

Example:

const { data } = await supabase
  .from("posts")
  .select("*")
  .limit(10)

Pagination

Use .range().

.range(0, 9)

Example:

const { data } = await supabase
  .from("posts")
  .select("*")
  .range(0, 9)

This returns rows 0–9.

Joins

Supabase uses PostgREST syntax.

Example:

const { data } = await supabase
  .from("posts")
  .select("*, profiles(username)")

This joins the profiles table.

Example result:

post
  └ profile.username

Auth (Quick Syntax)

Get the current user:

const { data } = await supabase.auth.getUser()

await supabase.auth.signInWithPassword({
  email,
  password
})

await supabase.auth.signUp({
  email,
  password
})

Sign out:

await supabase.auth.signOut()

Storage

Upload a file.

await supabase.storage
  .from("avatars")
  .upload("user.png", file)

Get public URL:

supabase.storage
  .from("avatars")
  .getPublicUrl("user.png")

RPC (Calling Database Functions)

If you define a Postgres function, call it like this:

const { data } = await supabase
  .rpc("get_popular_posts")

With parameters:

.rpc("get_posts_by_user", {
  user_id: userId
})

The Pattern Behind Everything

After using Supabase for a while, you notice something simple.

Almost every query follows the same structure.

supabase
  .from(table)
  .action()
  .filter()
  .modifier()

Examples:

.from().select()
.from().insert()
.from().update()
.from().delete()

Once that clicks, the API feels predictable.

What I Actually Remember

When working quickly, I don’t remember the whole API.

I remember a few patterns:

.from("table")
.select("*")
.insert({})
.update({}).eq()
.delete().eq()
.order()
.limit()

Everything else can be looked up.

A Small Lesson About Tools

Most tools feel complex at first.

But good tools have a small core idea.

For Supabase, it’s this:

Pick a table.
Choose an operation.
Add filters.

That’s most of the API.

Once you see the pattern, the documentation becomes easier to navigate.

Read on my site: https://kimkorngmao.com/notes/supabase-quick-docs

A Roadmap to Becoming a Web Developer

xiaoguang_ — Fri, 13 Mar 2026 10:00:43 +0000

If you want to become a web developer, the internet has never made it easier.

You don’t need a computer science degree.
You don’t need permission.
You just need curiosity and time.

Here’s a roadmap I recommend.

1. Learn the Foundations

Start with the basics of the web.

Everything else builds on this.

Core technologies

HTML — structure
CSS — layout and styling
JavaScript — behavior

Your first goal is simple:

Build a static website from scratch.

Not a tutorial.
Your own idea.

Examples:

personal portfolio
blog
photo gallery
simple landing page

2. Learn How the Web Actually Works

Many beginners skip this step.

Don’t.

Understanding the web makes everything easier later.

Things worth learning:

How browsers render pages
What happens when you visit a URL
HTTP requests and responses
APIs
JSON
how servers work

You don’t need deep theory.

Just enough to understand the system.

3. Pick a Modern Stack

Once you know the basics, choose a stack and go deeper.

For frontend development, a common path:

React
Next.js
TypeScript
Tailwind CSS

Don’t worry about choosing the “best” stack.

Any modern framework will work.

The important thing is building real projects.

4. Build Projects (Lots of Them)

Projects teach you things tutorials never will.

Ideas:

blog CMS
video player website
note-taking app
AI chatbot
online game
dashboard

Every project will reveal something new:

authentication
databases
deployment
performance
bugs you didn’t expect

This is how developers actually learn.

5. Learn the Backend

At some point you’ll want dynamic data.

Now learn backend fundamentals.

Useful topics:

databases (Postgres, MySQL)
APIs
authentication
server frameworks

Popular tools:

Node.js
Express
Supabase
Firebase

Once you reach this point, you can build full-stack apps.

6. Deploy Your Work

If your projects live only on your laptop, nobody sees them.

Deployment is part of the skill.

Learn how to deploy to platforms like:

Vercel
Netlify
Cloudflare
Docker servers

Shipping projects forces you to learn:

environment variables
build processes
performance
monitoring

7. Write and Share

One underrated skill for developers:

communication.

Write about what you learn.

Examples:

blog posts
GitHub READMEs
tutorials
dev notes

Clear writing improves clear thinking.

And it helps others learn too.

8. Keep Building

There is no finish line.

The web changes constantly.

Your goal isn’t to “learn everything”.

Your goal is to stay curious and keep shipping.

A simple loop works well:

learn → build → ship → share → repeat

Do this for a few years and you’ll be amazed how far you go.

Read on my site: https://kimkorngmao.com/notes/a-roadmap-to-becoming-a-web-developer

Developer in the Age of AI

xiaoguang_ — Fri, 06 Mar 2026 10:03:31 +0000

Software development is changing quickly.

For decades, writing software meant typing every line of code yourself. You opened an editor, read documentation, searched forums, and slowly assembled working systems one function at a time.

Today, the workflow looks very different.

You describe the problem.
An AI suggests the solution.
You guide the system toward the outcome you want.

This doesn’t remove the developer from the process. Instead, it changes the role.

Developers are becoming architects of intent rather than producers of syntax.

The real skill: knowing what to build

AI can write code. But it cannot decide what is worth building.

That decision still belongs to humans.

The most valuable engineers are not the ones who type the fastest. They are the ones who:

Identify meaningful problems
Design simple solutions
Understand tradeoffs
Ship things people actually use

AI accelerates execution. It does not replace judgment.

Speed changes how we learn

When building becomes faster, experimentation increases.

You can try five ideas in the time it used to take to build one.

This leads to a new pattern:

Build quickly
Learn what works
Throw away what doesn’t
Repeat

Iteration becomes the main advantage.

The teams that learn the fastest will win.

Small teams, bigger outcomes

Tools that multiply developer productivity change team dynamics.

Historically, large engineering organizations were necessary to build complex products.

Now, a small group with strong judgment and modern tooling can move incredibly fast.

Less coordination.
Less overhead.
More focus on the product.

The bottleneck moves

As AI removes friction from coding, new bottlenecks appear:

Product thinking
Clear communication
Good taste in design
Understanding user problems

In other words: human skills matter more, not less.

Clear thinking leads to clear prompts.
Clear prompts lead to better systems.

The future developer

The future developer will likely spend less time writing code and more time:

Designing systems
Reviewing AI-generated solutions
Teaching models through feedback
Communicating ideas clearly

Coding becomes a conversation.

Not just between humans and machines, but between ideas and execution.

The tools will keep improving.

But the core job remains the same:

Understand problems deeply, then build something useful.

Read on my site: https://www.kimkorngmao.com/notes/developer-in-the-age-of-ai

Write Code Like You’ll Maintain It

xiaoguang_ — Fri, 06 Mar 2026 01:58:06 +0000

Most of us write code for the moment.

We’re trying to fix a bug. Ship a feature. Hit a deadline.

Maintenance feels like a future problem. But here’s the truth: future you is the one who pays for today’s shortcuts.

I’ve learned this the hard way.

The code isn’t done when it works

Getting something to run is only step one.

You know that feeling when the feature finally works and you think, “Good enough”? That’s usually the point where the real work should start.

Ask yourself:

Would I understand this in six months?
Would a new teammate understand this in six minutes?
Is the naming obvious?
Is the logic doing one thing or five?

If the answer makes you hesitate, it’s not done.

Working code is not the goal. Clear code is.

Name things like you mean it

Bad names are expensive.

data, value, temp, handleStuff — these are signs you were in a rush.

Naming forces you to think. When you struggle to name something, it usually means the idea isn’t clear yet.

For example:

calculatePrice()

Calculate what price? With tax? With discount? For which user?

A better name might be:

calculateDiscountedPriceWithTax()

Longer? Yes. Clearer? Also yes.

Clarity beats cleverness every time.

Fewer abstractions, not more

Early in my career, I loved abstractions.

Custom hooks for everything. Utility layers. Reusable patterns for cases that only happened once.

It felt smart.

But too many abstractions hide intent. They make simple code harder to follow.

If something is only used in one place, it probably belongs in that place.

Duplication is not always bad. Confusing indirection is worse.

You can always extract later. It’s much harder to simplify over-engineered code.

Comments are not a rescue plan

If your code needs a paragraph to explain it, something is wrong.

This:

// This function loops through the array and checks if the user is active

…should not be necessary.

Your code should already say that.

Comments are useful when they explain why, not what.

For example:

// We intentionally skip caching here because user permissions change often.

That helps future you. It explains context. That’s what comments are for.

Write smaller functions

Large functions hide bugs.

When a function does too much, you stop reasoning about it. You just hope it works.

A simple rule I follow: if I have to scroll a lot to see the whole function, it’s probably doing too much.

Break it into smaller pieces. Each function should do one clear thing.

This makes testing easier. It also makes reading easier.

And reading code is most of the job.

Think about the next person

Code is a form of communication.

You are not writing for the compiler. You are writing for other humans.

Even if you work alone, the “other human” is future you.

Be kind to that person.

Avoid clever tricks unless they truly simplify.
Prefer boring solutions.
Stick to common patterns in your ecosystem.

Boring code is underrated. It is predictable. Predictable code is easy to trust.

Actually, I don’t think clever code is cool anymore. I think understandable code is cool.

Tests are a gift to yourself

Tests are not just for catching bugs.

They document behavior.

When you come back to a piece of code and don’t remember what it’s supposed to do, the tests tell you.

Even a few basic tests help:

Does it handle empty input?
Does it handle invalid input?
Does it return the expected shape?

You don’t need perfect coverage. You need confidence.

That’s enough.

Slow down a little

Rushing feels productive.

But debugging unclear code later is slow. Very slow.

Spending an extra 10 minutes:

Renaming variables
Removing dead code
Simplifying a condition
Splitting a function

…usually saves hours down the line.

It’s not glamorous. But it works.

The real goal

When I look back at old projects, I rarely think, “Wow, that was fast.”

I think:

Why is this so hard to follow?
Why did I make this so complicated?
What was I even thinking here?

Good code ages well.

It reads simply. It feels obvious. It doesn’t try to impress anyone.

That’s the kind of code I try to write now.

Not perfect. Just clear.

And honestly, that’s enough.

Write Code Like You’ll Maintain It - Kimkorng Mao

Clear code today saves you from confusion tomorrow.

kimkorngmao.com

Stop Trying to Scale Everything

xiaoguang_ — Fri, 06 Mar 2026 01:52:02 +0000

A few years ago, I thought everything needed to scale.

Every side project had to become a startup.
Every blog post had to become a content engine.
Every tool had to turn into a platform.

If something showed early traction, I immediately asked: “How do I grow this?”

That question isn’t wrong. But it can quietly ruin good work.

Not Everything Needs to Be Big

We live in a world that rewards scale.

Venture capital rewards it. Social media rewards it. Even advice online pushes it. If you’re not growing, you’re “leaving opportunity on the table.”

But small things have power.

A small tool can solve a very specific problem really well.
A small blog can reach exactly the right people.
A small product can fund your lifestyle without owning your life.

Actually, most of the internet runs on small things.

When you try to scale too early, you change the nature of what you’re building. You start optimizing for growth instead of usefulness. You think about funnels instead of features. You worry about onboarding flows before you even know if the product matters.

And that shift changes your decisions.

The Cost of Optimization

Optimization sounds smart. It feels responsible.

But optimization adds complexity.

You add analytics. You add growth experiments. You add email capture. You add dashboards. You add settings pages for features only two people asked for.

Suddenly, your simple idea becomes heavy.

I’ve done this. I’ve added systems before proving the core idea worked. I’ve hired help before understanding the problem deeply. I’ve scaled infrastructure before scaling demand.

It rarely ends well.

You don’t just add code. You add maintenance. You add mental overhead. You add pressure.

And pressure makes you build for numbers instead of people.

Build Something That Feels Complete at 1x

Instead of asking “How can this reach 1 million users?” try asking:

“Is this great for the first 10?”

When you build for 10 people, you pay attention. You answer emails. You watch how they use it. You fix the rough edges.

You build something tight.

If it grows after that, great. Growth built on top of something solid is different from growth used as a strategy to find solidity.

There’s a difference between:

Building something small that grows.
Building something to grow.

That difference matters.

Some Projects Should Stay Small

This is the part people don’t say out loud.

Some projects are better small.

A niche newsletter.
A focused SaaS tool.
A personal blog.
A paid community with 200 members.

If it supports your goals, pays your bills, and feels sustainable, why force it into something bigger?

Scale increases surface area. More users means more support. More complexity. More expectations.

Sometimes you don’t want a company. You want freedom.

And freedom doesn’t always scale.

Growth Is a Tool, Not the Goal

Growth is useful when it supports something meaningful. It’s dangerous when it becomes the meaning.

It’s okay to build something that stays simple.
It’s okay to serve a small group deeply.
It’s okay to stop at “enough.”

Actually, “enough” is underrated.

The internet makes it easy to compare. There’s always someone bigger, faster, louder. But you don’t see their tradeoffs. You don’t see the stress or the loss of control.

You only see the numbers.

What I Do Now

Now, when I start something new, I ask a different question:

“If this never gets big, would I still be proud of it?”

If the answer is no, I rethink it.

Because if you only enjoy the outcome at scale, you won’t enjoy the process. And most of your time is spent in the process.

Build things that feel good at 1x.

Let them grow if they earn it.

And if they don’t, that’s fine too.

Stop Trying to Scale Everything - Kimkorng Mao

Build Small First, Let Growth Happen Naturally Later

kimkorngmao.com

Human in the Loop

xiaoguang_ — Wed, 06 Aug 2025 09:54:35 +0000

I used to think writing code was the whole job. Type the right syntax, hit compile, ship it. Then AI Code Agent showed up. Suddenly half my keystrokes were suggestions. At first it felt like cheating. Then it felt normal. Now it’s the only way I work.

The shift is simple. Instead of telling the computer how to do something, I tell it what I want. The “how” is handled by an AI that’s read more code than I ever will. My job is to stay in the loop. I guide, correct, and decide when the result is good enough. I’m no longer a typist. I’m a filter.

This changes the skills that matter. Memorizing syntax is less useful. Spotting subtle bugs is more useful. Explaining intent in plain words is now a core skill. The AI can write a for loop, but it can’t tell me if the loop solves the real problem. Only I can do that.

There’s a trap here. If I stop paying attention, the code still looks fine. It just quietly drifts from what I actually need. The loop only works if the human stays human. That means asking “why” before asking “how.” It means pushing back when the answer feels off.

I’ve started treating the AI like a junior teammate who codes fast but misses context. I review every line. I ask questions. Sometimes I reject the whole thing and start over. The process is slower than pure autopilot, but the result is better. And I still learn something new each time.

This isn’t the end of programming. It’s a new layer. We still need architecture, testing, security, taste. We just get to spend less time on boilerplate and more time on decisions that matter. The loop keeps us honest. As long as we stay in it, the tools serve us, not the other way around.

A Simple Guide to Bash Commands for New Developers

xiaoguang_ — Wed, 23 Jul 2025 02:45:44 +0000

Original post: https://www.kimkorngmao.com/notes/simple-guide-bash-commands-for-new-developers

If you are a new developer, you probably use a nice GUI (Graphical User Interface) to code. It's easy. But when you start doing real work—like backend systems, deployment, or CI/CD—you will need to use the Terminal.

Using the terminal and Bash commands is a skill you must have.

This article is for new developers who are not used to the command line.

Commands You Should Know

Basics & File Management

pwd, ls, cd, touch, mkdir, rm, cat, less, head, tail, echo

Searching & Editing

grep, find, nano

Managing Git

git clone, git status, git log

Processing Text

awk, sed, jq

Calling APIs & Basic Networking

curl, ping, wget, netstat, lsof

1 Basics and File Management

`pwd` – Where am I?

This command shows you the path of the folder you are in right now.

pwd

It will display something like this:
/Users/yourname/projects/myapp

`ls` – What's in here?

This lists all the files and folders in your current directory.

ls          # A short list of files and folders.
ls -lah     # A detailed list of all files.

-l gives you more details (like size and date).
-a shows all files, even hidden ones (those starting with a dot .).
-h makes file sizes easy to read (like KB or MB).

`cd` – Change folder

Use this to move between folders.

cd bash_cmd_learn      # Go into the 'bash_cmd_learn' folder.
cd ..       # Go back up to the parent folder.
cd -        # Go back to the last folder you were in.

`touch` – Create an empty file

This creates a new, empty file.

touch rean.txt   # Creates a new file named rean.txt.

If the file already exists, this command just updates its timestamp.

`mkdir` – Make a new folder

mkdir logs          # Creates a new folder named 'logs'.
mkdir -p data/db    # Creates 'data' folder and then 'db' folder inside it.

The -p option is useful. It creates the parent folder if it's not there.

`rm` – Remove a file or folder

rm rean.txt      # Deletes the file rean.txt.
rm -rf logs/        # Deletes the 'logs' folder and everything inside it.

-r means recursive, so it deletes the whole folder.
-f means force, so it doesn't ask you for confirmation.

Be very careful with rm -rf. It deletes everything forever and does not ask you. There is no undo.

`cat` – Read a whole file

This command prints the entire content of a file to the screen. Good for small files.

cat README.md

`less` – Read a file page by page

If a file is very long, use less. It lets you scroll up and down.

less 2000_log_file.log

Press q to exit.

`head` and `tail` – See the start or end of a file

Sometimes you only need to see the first few lines or the last few lines.

head app.js        # Shows the first 10 lines.
tail app.js        # Shows the last 10 lines.

`echo` – Print text

This command prints text or the value of a variable.

echo "Hello, Developer"
echo $HOME          # Shows the path to your home directory.

You can also use it to write text to a file.

echo "PORT=8080" > .env     # Creates a file named .env with this text.
echo "DEBUG=true" >> .env    # Adds a new line to the end of .env.

> overwrites the file.
>> adds to the end of the file.

2. Searching & Editing

`grep` – Find text inside files

This is one of the most useful commands. It searches for a pattern of text.

# Search for any usage of async functions in JS files.
grep "async function" *.js

# Search for all lines that import modules (ES6 style).
grep "^import" *.js

`find` – Find files or folders

Use this to find files by name, type, or size.

# Find all JavaScript files in the src/ directory and its subdirectories.
find ./src -name "*.js"

# Find all test files that end with .test.js.
find . -type f -name "*.test.js"

`nano` – The simple editor

nano is a very easy-to-use editor for beginners allow you edit the files in the terminal.

nano index.js

This opens config.yaml for you to edit.

Press Ctrl + O to save your changes.
Press Ctrl + X to exit.

3. Basic Git Commands

You will use Git every day. Here are the most common commands.

git status - See what files have changed.
git add <file> - Prepare a file to be saved.
git commit -m "Your message" - Save your changes with a message.
git log --oneline - See a short history of all your saves.
git pull - Get the latest changes from the server.
git push - Send your saved changes to the server.
git clone <url> - Copy a project from a server to your computer.

4. Processing Text

`awk` – Get a specific column of text

Imagine you have a log file where data is separated by spaces. awk can pull out just the columns you want.

# From a Node.js server log, print the first column (the timestamp).
awk '{print $1}' server.log

# Print the IP address if it's the third column.
awk '{print $3}' server.log

`sed` – Find and replace text

sed is for finding and replacing text in a stream or file.

# Replace 'development' with 'production' in a .env file.
# This only prints the result; it doesn't change the file.
sed 's/development/production/g' .env

# To update the file in-place, use the -i flag.
sed -i 's/development/production/g' .env

`jq` – Work with JSON

If you work with APIs or config files like package.json, jq is a powerful tool for handling JSON.

# Pretty-print package.json
cat package.json | jq '.'

# Get the value of the "name" field in package.json
cat package.json | jq '.name'

# Get all dependency names from package.json
cat package.json | jq '.dependencies | keys[]'

5. Network Commands You Should Know

`ping` – Is the server online?

Use ping to check if you can reach a server.

ping google.com

# Ping 4 times and then stop.
ping -c 4 google.com

If it works, you’ll see replies with response times (e.g., 64 bytes from ... time=23.4 ms). If it’s not , you’ll get errors like Request timed out or Destination Host Unreachable.

`curl` – Talk to APIs

curl is a great tool for testing APIs from the command line.

# Send a GET request to a health check endpoint.
curl http://localhost:8080/health

# Send a POST request with JSON data.
curl -X POST http://localhost:8080/users \
  -H "Content-Type: application/json" \
  -d '{"name": "new dev"}'

`wget` – Download files

Use wget to download a file from a URL.

wget https://example.com/some-file.zip

`lsof` and `netstat` – What's using that port?

If you get an error like "port already in use," these commands can help.

# Show me what program is using port 8080.
lsof -i :8080

This will show you the command and PID using the port. You can then use kill to stop it if you need to.

You don't need to remember all these commands at once. The best way to learn is to start using them for your real projects.

Start with simple things: moving between folders, editing a config file, checking logs, or running your app.

Once you are comfortable, you will see that the command line is a powerful tool. You can build your own scripts for testing, deploying, and monitoring your work. And that is a very important skill for a developer.

Forem: xiaoguang_

The AI That Makes You Feel Stupid—but In a Good Way

My Honest Take on AI Coding Tools After Months of Heavy Use

Why I Still Keep a Personal Website

Connect Telegram Notifications in Laravel App Quickly

1. Database and Bot Setup

2. The Frontend "Connect" Button

3. Handling the Webhook

4. Sending the Notification

A few thoughts

Laravel 13 Highlights

1. PHP 8.3 is the New Floor

2. Attributes Everywhere

3. The First-Party AI SDK

4. Cache Management

5. JSON:API Resources (New in v13)

My Take

Supabase Quick Docs

Setup

Select (Read Data)

Select specific columns

Filter rows

Get one row

Insert (Create Data)

Return inserted data

Update

Delete

Ordering

Limit

Pagination

Joins

Auth (Quick Syntax)

Storage

RPC (Calling Database Functions)

The Pattern Behind Everything

What I Actually Remember

A Small Lesson About Tools

A Roadmap to Becoming a Web Developer

1. Learn the Foundations

2. Learn How the Web Actually Works

3. Pick a Modern Stack

4. Build Projects (Lots of Them)

5. Learn the Backend

6. Deploy Your Work

7. Write and Share

8. Keep Building

Developer in the Age of AI

The real skill: knowing what to build

Speed changes how we learn

Small teams, bigger outcomes

The bottleneck moves

The future developer

Write Code Like You’ll Maintain It

The code isn’t done when it works

Name things like you mean it

Fewer abstractions, not more

Comments are not a rescue plan

Write smaller functions

Think about the next person

Tests are a gift to yourself

Slow down a little

The real goal

Write Code Like You’ll Maintain It - Kimkorng Mao

Stop Trying to Scale Everything

Not Everything Needs to Be Big

The Cost of Optimization

Build Something That Feels Complete at 1x

Some Projects Should Stay Small

Growth Is a Tool, Not the Goal

What I Do Now

Stop Trying to Scale Everything - Kimkorng Mao

Human in the Loop

A Simple Guide to Bash Commands for New Developers

Commands You Should Know

1 Basics and File Management

pwd – Where am I?

ls – What's in here?

cd – Change folder

touch – Create an empty file

mkdir – Make a new folder

`pwd` – Where am I?

`ls` – What's in here?

`cd` – Change folder

`touch` – Create an empty file

`mkdir` – Make a new folder

`rm` – Remove a file or folder

`cat` – Read a whole file

`less` – Read a file page by page

`head` and `tail` – See the start or end of a file

`echo` – Print text

`grep` – Find text inside files

`find` – Find files or folders

`nano` – The simple editor

`awk` – Get a specific column of text

`sed` – Find and replace text

`jq` – Work with JSON

`ping` – Is the server online?

`curl` – Talk to APIs

`wget` – Download files

`lsof` and `netstat` – What's using that port?