Vibe Coding

Posted: February 13, 2025 | Author: | Filed under: Development, Trick | Tags: | Comments Off on Vibe Coding

Two weeks ago I started to noticed about something that’s both fascinating and slightly unsettling: vibe coding. And no, it’s not about writing code while listening to lo-fi beats (though that sounds nice too).

Vibe coding, as coined by Andrej Karpathy, is essentially “fully giving in to the vibes” and forgetting that code even exists. Instead of writing lines of code, you’re having a conversation with AI about what you want to build. It’s less about “how” and more about “what”.

Think about it: instead of googling Stack Overflow (that was so 2022, who’s still do that?) for the millionth time about that one CSS property you can never remember, you just tell an AI, “Make this button look cooler.” And it… just does it?

Even wild, you can make it independently execute 10 steps by itself.

The wild part is that it works. People are building entire applications without writing a single line of traditional code. It’s like having a really smart dev friend who does all the technical heavy lifting while you focus on the creative vision. I been using voice/STT as interface (because typing is slow) and AI IDE like Cursor since last year (even longer with voice as interface – almost 10 years till this date, can you believe it? **Dragon Dictate, hello!), and I agreed it was new paradigm even though I felt like I was cheating.

But here’s what fascinates me most: we’re moving from a world where coding was about speaking the computer’s language to one where computers are learning to speak ours. It’s not about syntax anymore—it’s about vibes.

Is this the future of software development? Maybe. Will it replace traditional coding? Probably not entirely. But it’s definitely changing how we think about building software. – I am firm believer the future is also agentic.

For now, I’m both excited and slightly terrified to see where this goes. After all, sometimes the best vibes come from understanding what’s happening under the hood.

What do you think about this shift? Are you ready to give in to the vibes?

ROI Over Use Cases

Posted: February 13, 2025 | Author: | Filed under: Product | Tags: , | Comments Off on ROI Over Use Cases

I’ve often found myself in what I now call “researcher’s syndrome” – that relentless urge to cover all angles, explore every possibility, and chase down every use case. As a PM, it felt natural: the more I knew, the better decisions I could make. Or so I thought. This is the story of how I learned that sometimes, less truly is more.

The Realization

In my early PM days, I was that person with sticky notes everywhere and a roadmap that looked like a tangled web of possibilities. I believed success meant creating products that solved every conceivable user need. My research was exhaustive, my feature sets were bloated, and honestly? My team was exhausted.

It wasn’t until a mentor @chuazm bluntly told me I was “trying to boil the ocean” that something clicked. The truth hit hard: in trying to solve everything, I was solving nothing particularly well. I also pickup new approach to first principal thinking with our EM @lsshawn.

Why Less Is More

Here’s what I’ve learned about focusing on what truly matters:

  1. Clarity Over Clutter
    When we focus on fewer features, we gain clarity about what our product actually stands for. It’s not about doing less work – it’s about doing better work. Apple’s approach to product design has been my north star here. Their relentless pursuit of simplicity isn’t just aesthetic; it’s strategic.
  2. Depth Over Breadth
    Think about Slack. They could’ve tried competing with full project management tools or email clients, but instead, they focused on one thing: making team communication seamless. This laser focus allowed them to excel where it mattered most.
  3. Strategic Alignment with ROI
    The shift from “What else can we add?” to “What will deliver the highest impact?” transformed my decision-making process. Not all features are created equal – some might delight users but barely move the needle on business metrics. Learning to differentiate between “nice to have” and “need to have” became crucial.

The Philosophy in Practice

Here’s how I’ve integrated this mindset into my work:

  • Start with Why: Every feature needs a clear purpose tied to user needs or business outcomes.
  • Kill Your Darlings: Regular roadmap audits are essential. Be ruthless about removing features that don’t add significant value.
  • Focus on Outcomes: Shift your thinking from features shipped to problems solved.

One of my proudest moments was when our team chose to improve an existing workflow used by 80% of our users instead of building a flashy new feature. The result? A 30% increase in user satisfaction. Sometimes the best solutions aren’t the most exciting ones.

A Closing Thought

Minimalism in product management isn’t about taking shortcuts – it’s about making deliberate choices that amplify impact. It’s recognizing that our resources are finite and choosing to use them wisely.

If you’re feeling overwhelmed by possibilities or paralyzed by options, remember this: success isn’t measured by how many features you ship, but by how well you solve real problems. Sometimes, doing less is the bravest – and smartest – choice we can make.

I’ve learned that my initial instinct to cover every base wasn’t just about thoroughness – it was about validation. But true impact comes from focusing on what matters most and executing it exceptionally well.

What could you achieve by doing less, but doing it better?

P/S: I got inspiration to write this after watch Arseny Shatokhin video on AI agent development.

To Code or Not to Code, Revisited

Posted: February 9, 2025 | Author: | Filed under: Uncategorized | Comments Off on To Code or Not to Code, Revisited

So, I ranted about code in static papers a while back (someone asked me about this – so I’d figure allow me to do a follow up), but what if your code is the real star of the show? Can you still sneak some in without drowning readers in curly braces?

Yes.

If your snippets are absolutely critical—like the secret sauce that everyone needs to see—fine, slip in a few lines. Just make them short and sweet. No one wants to navigate a labyrinth of semicolons; your readers only care about that one essential function or loop that proves your point. But don’t stop there: you still need to explain why those lines matter. If you’re showing off a special parsing trick or a brand-new algorithm, tell us why it’s special—don’t just paste it and pray.

Most importantly, provide a link to the full code in its natural habitat, whether that’s GitHub or another platform. Readers who truly want to dig deeper will thank you for letting them see—and run—the real thing, rather than forcing them to squint at a crammed PDF. Give context, give clarity, and keep the clutter to a minimum. After all, no one’s going to appreciate a code dump… not even your future self re-reading that paper.

Keep it stupid simple. KISS.

Living Dangerously

Posted: January 28, 2025 | Author: | Filed under: Wisdom | Tags: , | Comments Off on Living Dangerously

You know that feeling when you open your laptop in the morning, staring at the same desktop wallpaper you’ve had since 2016? That’s how many of us live our lives – in a comfortable, predictable loop that slowly drains the color from our days. I’ve been there, sitting in that ergonomic chair of safety, until I discovered something that changed everything: the art of living dangerously.

Now, before you picture me free-climbing Mount Bromo or swimming with dolphins, let me explain. Living dangerously isn’t about becoming an adrenaline junkie – it’s about embracing the electricity of uncertainty in our everyday choices. Think of it like upgrading from a basic smartphone to the latest model; sure, the old one works fine, but you’re missing out on features you didn’t even know you needed.

The Algorithm of Playing it Safe

We’re programmed to seek stability. Our brains run on what I call the “predictability protocol” – a set of neural pathways that prefer the known over the unknown. But just like any outdated software, this programming needs an upgrade. Living dangerously is about pushing that ‘update now’ button on your life, even when it’s inconvenient.

I remember when I was offered to lead a major tech project despite having zero experience with the core technology. My inner safety algorithm screamed “ERROR: INSUFFICIENT QUALIFICATIONS!” But here’s the thing about bold choices – they’re like quantum computers, operating in a space where traditional rules of success and failure don’t apply.

The Colorful Chaos of Bold Choices

When you start living dangerously, something magical happens. Life becomes high-definition, surround-sound spectacular.

Think about it: We’re floating on a rock through infinite space, orbiting a giant nuclear fusion reactor, and somehow we’ve convinced ourselves that playing it safe is the “logical” choice. It’s like having a ticket to the most spectacular show in the universe and spending the whole time scrolling through your phone.

Last year, I decided to embrace this absurdity. Instead of following my carefully plotted life trajectory (which, let’s be honest, was about as exciting as watching paint dry in slow motion), I started treating my existence like a series of thought experiments.

Think about the last time you took a real risk. Remember that flutter in your stomach? That’s not anxiety – it’s your internal GPS recalculating to accommodate new possibilities. The most vibrant moments in life often come wrapped in uncertainty, like mystery notifications you can’t ignore.

Your Personal Risk Operating System

Living dangerously doesn’t require a complete system override. Start with small program updates:

First, practice saying “yes” to the unknown. When I started attending random tech meetups outside my expertise, I felt like a MacBook at a Windows convention. But those uncomfortable moments led to some of my most valuable professional connections.

Learn to reframe fear as your personal beta testing phase. Every time you feel scared, you’re actually on the verge of a major upgrade in your capabilities. That presentation that terrifies you? It’s just your next feature release. That cereals 6 months past expiry date? probably nothing bad will happen.

Embrace failures as debug reports. Recently, I bombed a presentation so badly that someone actually started slow-clapping – and not in a good way. But that experience taught me more about public speaking than a dozen successful presentations ever could.

The Full Stack of Life

Here’s what I’ve learned: life is too short to run on safe mode. Living dangerously means becoming the beta tester of your own potential. It’s about running experimental code in the production environment of your life.

So, what’s your next bold commit going to be? What feature of yourself are you ready to push to production? Maybe it’s finally starting that side project, having that difficult conversation, or taking that class that intimidates you.

Remember: the most interesting bugs in life often lead to the most impressive features. The question isn’t whether you’ll encounter errors – it’s whether you’ll let them stop you from releasing your next version.

Your life is the most complex program you’ll ever run. Don’t let it become abandonware. Push updates regularly, test new features boldly, and never stop debugging your comfort zone. After all, the best software evolution happens outside the sandbox environment.

Ready to deploy your next bold choice? The command line is waiting for your input.

P/S: had fun with the copious SWE references in this post? I know, I know, so long with the quirkiness. It’s fun I’ll do it again next time. Thanks Claude.

Code in an Academic Paper? No, Thank You.

Posted: January 19, 2025 | Author: | Filed under: Musing | Comments Off on Code in an Academic Paper? No, Thank You.

Let’s be brutally honest here: there’s something painfully awkward about stuffing blocks of code into an academic paper. You know the type—pages upon pages of impenetrable black text, each line looking more threatening than the last. And for what? So that the 1.5 people who might care can grab a magnifying glass and attempt to decipher your curly braces?

Why It’s a Bad Idea:

  1. No One Reads It
    You think your readers are going to flip through your 40-page magnum opus and pause to admire your meticulously spaced code? No—people skim for the interesting bits, like your hypothesis, your findings, and maybe your conclusion. Detailed code is about as riveting in paper format as reading a phone book.
  2. Adds Bulk, Not Value
    Sure, code inflates your paper’s page count. But more isn’t more if it’s meaningless. If the real purpose is clarity and sharing, then a massive code dump does neither. You’re better off providing a link to a GitHub repo or a supplementary file.
  3. Low Readability
    Code that reads well in your favorite IDE doesn’t magically transform into a well-structured exposition when copy-pasted into a PDF. Syntax highlighting is minimal, line breaks get weird, and crucial context is lost.

What to Do Instead:

  1. Diagram the Process
    A picture is worth a thousand lines of code. Creating a clear flowchart or system diagram not only looks neat on your poster or slides, but also helps people understand the logic.
  2. Explain the Thought Process
    Your paper should be about the why rather than the what. Readers want to know the reasoning behind your methods, the decisions that led you to that final algorithm, and how it ties back to your research question. This context is what sparks interest and fuels further discussion.
  3. Link to Repos
    If you really want to share the code (and believe me, that’s awesome for reproducibility!), pop it on a version control platform. Stick a tiny URL in your paper or slide deck, and voilà—everyone can explore your code if and when they want, in its natural habitat.

Bottom Line
Stop cramming lines of C++ or Python into that gorgeous LaTeX doc just so you can say, “Look, it’s all here.” It’s not a show of strength—it’s a show of clutter. Diagram it, explain your process, and let your readers actually learn something from your research. Because at the end of the day, clarity beats extra pages every time.

Whether it’s a corporate white paper, a thesis, or your team’s internal project report, spare your readers (and yourself) from the headache of static code dumps. Show the bigger picture with diagrams, share your insights, and let them chooseto view the code in a dynamic, interactive space if they want. That’s how you really add value—and no one will ever complain about too few pages!

And if the code is truly that interesting, trust me: your audience will thank you for a link instead of a messy PDF labyrinth.

Limits

Posted: November 1, 2024 | Author: | Filed under: Diary | Comments Off on Limits

I remember 2017 vividly. It was the year that taught me what being human truly means. Time is relentless, marching forward without pause. Reality hit me hard – we all have limits.

Looking back at my younger self in 2004 and 2014, I smile at my naive enthusiasm. Rest seemed like a weakness then. I was that person who believed in pushing boundaries without breaks. The world was mine to conquer.

Let me share something I’ve never told many people: I once had a panic attack ten minutes before a major presentation. My heart raced, hands trembled, and breath shortened. In that moment, all my preparation, all my confidence, melted away. Standing in the bathroom, staring at my reflection, I realized how fragile our minds can be despite our best preparations.

These moments of vulnerability teach us more than success ever could. Some days, giving 0% is all you can manage. The younger me would stay awake for three days straight, fueled by ambition and coffee. What a fool I was. Those marathon sessions came with a price – days of mental fog and exhaustion.

Your body whispers before it screams. I learned to listen to those whispers. Now, in my older years, wisdom has finally settled in. My body isn’t just a vehicle for my ambitions. I’ve learned to celebrate small victories, understanding that the journey matters more than the destination.

Goals still drive me, but they don’t consume me. Each tiny step forward deserves recognition. Sometimes, retreating isn’t defeat – it’s strategy. You don’t have to win every single battle.

Here in 2024, I’m still a student of life. Each day brings new lessons. My spiritual journey has deepened, and I understand now that growth isn’t always visible. The greatest lesson? Being human means embracing both strength and weakness.

We’re not machines. We’re wonderfully imperfect beings, learning as we go. And that’s perfectly okay.

Form Follows Function

Posted: October 29, 2024 | Author: | Filed under: Wisdom | Tags: | Comments Off on Form Follows Function

As a product manager in a small team, I’ve learned to embrace simplicity. We don’t have dedicated UX researchers or product designers. But that’s okay.

The phrase “form follows function” has become our guiding principle. It’s more than just a design philosophy. It’s our survival strategy.

My journey here wasn’t straightforward. Previously, I was the typical overenthusiastic PM, trying to map out every user scenario before writing a single line of code. I’d spend weeks creating comprehensive requirement documents that attempted to address every edge case imaginable, only to find half of my assumptions were wrong.

Now, I’ve learned to start small and think bottom-up. We begin with the core problem and its simplest solution. Nothing more.

When resources are limited, you focus on what truly matters. What does the user need to accomplish? How can we make it work first, then make it beautiful?

Take our recent notification system redesign. Instead of planning for every notification type upfront, we started with just one: payment confirmations. We got it working perfectly, then gradually expanded to other types.

Each sprint teaches us something new about our users. Sometimes we get it wrong. That’s fine – we adjust and move forward.

Rather than conducting extensive user interviews, we now rely on quick feedback loops and usage data. When we launched our new dashboard, we started with just three essential metrics that users actually needed daily, rather than cramming in every possible data point.

Our software evolves like a sculpture. We start with rough shapes and basic functionality. Then we chip away at the unnecessary parts. We polish what remains.

The best solutions often emerge from constraints. Our limited resources push us to focus on essentials. Everything else is just decoration.

So we keep building, testing, and refining. Form follows function. Always.

Everyone is Now a Product Manager

Posted: September 16, 2024 | Author: | Filed under: Musing | Comments Off on Everyone is Now a Product Manager

I’ve been observing a curious shift in the world of programming. As powerful AI tools like Cursor and Copilot have emerged, the focus has moved away from the nitty-gritty of coding and towards a more strategic, product-centric approach.

Programmers are no longer just grunts toiling in the codebase. They’re now elevated to the role of product managers, responsible for crafting the vision and guiding the development of complex, AI-powered solutions.

I first noticed this transition when I found myself spending more time conceptualizing the bigger picture rather than hacking away at the keyboard. The actual coding felt almost secondary, like an implementation detail.

As AI-powered assistants take on more coding tasks, programmers must evolve their skillset and mindset. They must become part architect, part product visionary, embracing techniques like:

  1. Riding the wave of code-generating LLMs: I’ve had to embrace the power of large language models (LLMs) to generate code, freeing me up to focus on high-level design and problem-solving. It’s been a bit of a learning curve, but the efficiency gains have been undeniable.
  2. Becoming a big-picture architect: My role is now more about conceptualizing solutions, designing systems, and ensuring the overall coherence of the product, rather than getting bogged down in the details. It’s a welcome change, but it also requires a different mindset and skillset.
  3. Constantly switching to the best AI tools and models: I’ve had to stay agile and adaptable, continuously evaluating the latest AI tools and models to ensure I’m using the most effective ones for the task at hand. It’s like I’m constantly on the lookout for the latest and greatest tools to enhance my productivity.
  4. Designing with natural language first: I’ve started to leverage the natural language capabilities of AI tools to ideate, prototype, and refine my solutions, before diving into the technical implementation. It’s a more intuitive and collaborative way of working, and it’s helped me to be more creative and innovative.
  5. Avoiding competition with AI and using it to work better: I’ve realized that AI is not a threat, but a powerful ally. By collaborating with these tools, I’ve been able to enhance my own productivity and problem-solving abilities, rather than trying to compete with them.

This transformation is only just beginning. As AI continues to reshape product development, the successful programmers of the future will be those who can adapt and evolve from coders into strategic product managers.

This is how you 10x.

Git Reset Lifeline

Posted: January 4, 2024 | Author: | Filed under: Development | Comments Off on Git Reset Lifeline

Whoops! I got myself into a Git pickle yesterday. I was trying to pull some updates from upstream into my feature branch, a normal part of my workflow. But before I knew it, things spiralled out of control. Merges going every which way, commits piling up, extra branches multiplying like rabbits. After 7 or 8 hours of working time, I somehow ended up with 5 extraneous branches! 😅

Anyway, I decided to take a beat, have some chamomile tea, and turn this Git debacle into a teaching moment. Because if it happened to me, it can happen to you! So here’s the scoop on how to hit the reset button on a branch when things go awry.

Hitting the Git Reset Button: A Chill Tutorial

Say you want to revert a branch back to a previous state. The easiest way is to do a hard reset. Just make sure you know what commit you want to revert to first! Here’s how:

  1. Check out the troubled branch:
git checkout branch-backup
  1. Reset it to the desired commit to erase all changes after that point. Sayonara, buggy code!
git checkout main
git reset --hard branch-backup
  1. If you already pushed the branch, you’ve got to force push the changes:
git push origin main --force

And you’re done! Branch restored to commit bliss.

Just be cautious with that last step—it rewrites history, so use sparingly. And you may need to give your teammates a heads up.

Now I’m off to relax after my Git escapade with some more calming tea and a peanut butter toast.

Racing Against the Machine

Posted: November 9, 2023 | Author: | Filed under: Musing | Comments Off on Racing Against the Machine

The pace of new technology seems to get faster every year. In my job doing automation engineering, I’ve seen how once all the parts of a system are ready, progress can explode exponentially. I’m worried as AI and agent swarms get closer to generalized intelligence, they will quickly make many jobs and skills obsolete – including my own.

Just last week, I was telling my parents I’m concerned I may not have unique skills to offer anymore. Right now, connecting all the pieces of AI into a fully autonomous system is still complicated. But not for long. When those last key elements like agent coordination arrive, everything will work together and we’ll see sudden rapid advancement.

I’m not sure if most people are ready for this pace of change. I’m not even sure if I’m ready myself.

Multiple exponential technologies will boost each other, speeding things up even more. There may come an abrupt point where progress becomes so fast it’s hard to control and uses enormous resources.

I worry about new graduates entering a job market changed by AI. But I also know we humans don’t understand exponential change well. The future may look very different than we expect.

For now, I’m reassured that building AGI is like making an engine – it needs all parts to work seamlessly together. We still lack some essential pieces.

For now.

But once that last piece clicks into place, the engine of AI will roar to life and race ahead faster than we can foresee today. My goal is to enjoy the ride, and adapt my skills to stay ahead of the tech changes as long as I can.

← Older Entries