Forem: Gold roger

I'm Getting Lazy, and AI Is Letting Me

Gold roger — Thu, 26 Mar 2026 19:48:38 +0000

Okay, so I need to be real with myself about something.

I've been building a lot lately with AI in the tab next to my editor. And somewhere along the way, something shifted. I don't think it's good.

How it starts:

I'll begin a project feeling confident. I write some code. Actually understand what I'm doing. Then I hit a bug or need the next feature, and instead of sitting with the problem for five minutes, I just... describe it to Claude. Tab-tab-tab. Copy. Paste. Next.

It feels efficient. Except I'm not actually coding anymore. I'm describing what I want and waiting.

Then it gets worse.

After a few features, I realize I don't actually know what my own app does anymore. Not really. I can describe the vision, sure. But the logic? The way the pieces fit together? I'm fuzzy on it. And that's when I catch myself asking the AI "what should I do next?" instead of thinking.

That moment sucks. It's like my brain just... checked out.

Here's what I think is happening:

There's something people call "LLM brain poisoning." Sounds dramatic, but hear me out. Every time you skip the struggle — the debugging, the thinking, the figuring it out — your brain doesn't build that understanding. You're outsourcing the hard part. And the hard part is where learning lives.

Your problem-solving atrophies. Your memory gets worse. Critical thinking becomes... optional.

And the wild part? You feel more productive. You shipped three features today. But did you understand them? Or did the AI understand them and you just watched?

So what am I doing about it?

I'm forcing myself to code first. Sit with the problem. Get frustrated. Figure it out. Then if I want, I'll let AI review or clean it up.

Because the code I write myself — even the messy, inefficient code — that's my code. I know it. I own it. And next time I see that pattern, I won't need to ask.

That's the difference between using AI and letting AI use you.

Git Explained: From Mental Models to Production Workflows

Gold roger — Mon, 09 Mar 2026 23:44:21 +0000

Introduction

If you're like me, you started using Git because someone told you to. You learned the magic words—git add, git commit, git push—and they kinda worked. But you didn't really understand what was happening underneath.

This article is for you. I'm going to walk you through Git the way it finally clicked for me: starting with a mental model that actually makes sense, then building up to real-world workflows that professionals use every day.

Part 1: The Mental Model

Commits: Snapshots in Time

Forget thinking of commits as "saves." Think of them as photographs of your entire codebase at a moment in time.

When you make a commit, Git takes a picture of all your files—exactly as they exist right now. That photo is stored in Git's database forever. You can always go back and look at it, or restore your code to exactly how it was in that moment.

Key insight: Every commit is complete. If you want to see what your code looked like 5 commits ago, Git can show you the entire state—all files, all changes.

The Commit Train: Building History

Now imagine linking these commits together in a chain. The first commit has no parent. The second commit points back to the first. The third points to the second. And so on.

This chain is your history. It's a train of commits, each one building on the last. This is why Git is powerful—you can see the entire journey of how your code evolved.

Commit 1 → Commit 2 → Commit 3 → Commit 4
(Initial)  (Feature)  (Bug fix)  (Refactor)

You can move back along this train whenever you want. Go back to Commit 2? Your code looks exactly as it did then.

The Staging Area: Selective Commits

Here's where most people get confused. Why does Git have two steps—git add and git commit—instead of just one?

Answer: Control.

Imagine your project has 4 files, but you only want to commit 3 of them right now. The staging area lets you do this:

git add file1.py file2.py file3.py — Add the 3 files you want
git commit -m "your message" — Commit only those 3 files

The fourth file stays out of the commit. It's still changed on your computer, but it's not part of this snapshot.

This matters because it lets you organize your commits logically. One commit = one logical piece of work. Not a jumble of unrelated changes.

Part 2: Branches—Parallel Universes of Code

The Problem with One Timeline

Imagine you're building a repair shop app. You're working on Feature A (booking system). Then your boss says "we need Feature B (payment processing) shipped tomorrow."

If you just keep committing to the same line, you'll have:

Commits for Feature A (incomplete)
Commits for Feature B (complete)
All mixed together on the same branch

Now you can't deploy just Feature B without Feature A. You're stuck.

Branches: Separate Timelines

A branch is a pointer to a commit. It's a separate line of development that doesn't interfere with other branches.

Here's how it works:

        Feature A (commits 2, 3, 4)
       /
Main (commit 1) → Feature B (commits 2, 3) → Merged back
       \
        Hotfix (commit 2)

Now:

Feature A can develop independently
Feature B can develop independently
Main stays stable and production-ready
When Feature B is done, merge it into main and ship it
Feature A keeps developing without blocking anything

Main Branch: Your Safety Net

Main branch = production code. It's the code you trust. It's tested, it's stable, it's live in the world.

You never build directly on main. You build on feature branches, and only merge into main when the code is ready for production.

This is how teams prevent disasters. Main is always deployable. Always.

Part 3: Real-World Workflows

The Standard Feature Branch Workflow

Here's how a professional team uses Git:

Step 1: Start a new feature

git checkout main          # Make sure you're on main
git pull origin main       # Get the latest code
git checkout -b feature/booking-system  # Create and switch to feature branch

Step 2: Build the feature

# Edit files, test, repeat
git add file1.py file2.py
git commit -m "feat: add booking form validation"

git add database.py
git commit -m "feat: connect booking form to database"

git add tests.py
git commit -m "test: add booking system tests"

Notice: Multiple commits, each representing one logical piece of work.

Step 3: Feature is done and tested

git push origin feature/booking-system  # Push to GitHub

Then create a Pull Request (PR) on GitHub. Your team reviews the code. If it looks good, merge it.

Step 4: Merge into main

git checkout main
git pull origin main
git merge feature/booking-system
git push origin main

Your feature is now live. Delete the feature branch (you don't need it anymore):

git branch -d feature/booking-system

The Hotfix: Emergency Bug Fixes

Production is live. Users find a bug. You need to fix it NOW.

Important: You fix it on a hotfix branch, not directly on main.

git checkout main
git checkout -b hotfix/email-double-send

# Fix the bug
git add email.py
git commit -m "fix: prevent double email sends"

# Merge back to main immediately
git checkout main
git merge hotfix/email-double-send

# Push to production
git push origin main

# Delete the hotfix branch
git branch -d hotfix/email-double-send

Now main is fixed and deployable. Production is patched. Crisis averted.

Merge Conflicts: When Humans Decide

Say two people changed the same line of code in different branches. When you try to merge them, Git can't automatically decide which version is correct.

Git will show you something like:

<<<<<<< HEAD (main branch)
version of code from main
=======
version of code from feature branch
>>>>>>>>

You manually edit the file, pick the version you want, and commit.

Git is asking you: "Which version is right?" Because only a human knows the answer.

Part 4: Commit Message Best Practices

Your commit messages tell a story. Future you (and your teammates) will read them to understand why a change was made.

Bad commit messages:

git commit -m "stuff"
git commit -m "fixed things"
git commit -m "changes"

Good commit messages:

git commit -m "feat: add booking form validation"
git commit -m "fix: prevent double email sends in confirmation"
git commit -m "refactor: simplify database query logic"

The Pattern

Start with a type:

feat: A new feature
fix: A bug fix
refactor: Code cleanup (no feature change)
test: Adding tests
docs: Documentation changes
style: Formatting (no logic change)

Then describe what you did in present tense: "add", "fix", "simplify", not "added", "fixed", "simplified".

Why? Because when you read the git log, it reads like a series of actions:

feat: add booking form
fix: validate email in form
refactor: clean up form code
test: add form validation tests

Part 5: When to Commit

This is the question that trips people up: When should you actually make a commit?

The Rule

Commit when you've completed one logical unit of work that is testable and works.

Not "perfect"—just complete and functional. One reason to commit.

Examples

Good commits:

✅ "Add email validation to booking form" — One feature, complete
✅ "Fix typo in error message" — One bug, fixed
✅ "Refactor database queries" — One improvement, done
✅ "Add tests for booking system" — One logical piece

Bad commits:

❌ "Add email validation + refactor database + fix typo + update tests" — Too many things
❌ "Work in progress" — Not complete
❌ "Stuff" — Not clear what you did

The Test

Ask yourself: If I had to revert this commit, would it break something?

If yes, you've bundled too much together. Split it into multiple commits.

If no, it's a good commit.

Part 6: The Complete Workflow (From Start to Finish)

Here's a real-world scenario: You're building a repair shop app with a teammate.

Initial Setup

git clone <repository-url>
cd repair-shop-app

You: Building the Booking System

# Create a feature branch
git checkout -b feature/booking-system

# Work and commit logically
git add booking_form.py
git commit -m "feat: create booking form component"

git add database.py
git commit -m "feat: add booking to database"

git add tests.py
git commit -m "test: add booking system tests"

# Push to GitHub
git push origin feature/booking-system

Your Teammate: Building Payment Processing

git checkout -b feature/payment-processing

git add payment.py
git commit -m "feat: integrate Stripe payment"

git add error_handling.py
git commit -m "feat: handle payment errors"

git push origin feature/payment-processing

Both of you are working independently. No interference.

Feature B (Payment) is Done First

# Your teammate creates a Pull Request on GitHub
# Team reviews it
# Looks good, merge it

git checkout main
git pull origin main
git merge feature/payment-processing
git push origin main
git branch -d feature/payment-processing

Payment processing is live. Feature A is still developing independently.

Bug in Production

Users report that confirmation emails send twice.

git checkout main
git checkout -b hotfix/email-double-send

git add email.py
git commit -m "fix: prevent double email sends"

git checkout main
git merge hotfix/email-double-send
git push origin main
git branch -d hotfix/email-double-send

Bug is fixed. Production is patched.

Feature A is Done

git checkout feature/booking-system

# Feature A has been developing this whole time
# Now it's done and tested

git push origin feature/booking-system

# Create Pull Request, team reviews
# Merge it

git checkout main
git pull origin main
git merge feature/booking-system
git push origin main
git branch -d feature/booking-system

Both features are now live. All commits are in history. All branches are cleaned up.

Part 7: The Commands You Actually Need

Here are the essential Git commands for this entire workflow:

# Clone a repository
git clone <url>

# Create and switch to a new branch
git checkout -b feature/name

# Switch to an existing branch
git checkout branch-name

# Check what branch you're on
git status

# Stage files for commit
git add filename
git add .  # Add all changed files

# Commit
git commit -m "type: description"

# Push to remote (GitHub)
git push origin branch-name

# Pull latest from remote
git pull origin branch-name

# Merge another branch into current branch
git merge branch-name

# Delete a branch
git branch -d branch-name

# View commit history
git log

# See what changed in a commit
git show commit-hash

That's it. Those 12 commands cover 95% of what you'll do.

Conclusion

Git isn't magic. It's a system for:

Taking snapshots of your code (commits)
Building a history of those snapshots (the commit train)
Working on multiple features in parallel (branches)
Merging them back together safely (merges)
Keeping production stable (main branch as safety net)

The mental model is simple. The commands are simple. The power comes from using them consistently.

Start with small commits. One logical piece of work per commit. Keep main stable. Work on branches. Review before merging. Keep history clean.

Do that, and you'll be ahead of most developers.

Try it: Create a test repository. Make some branches, commit some stuff, merge them back. Get comfortable with the commands.
Read the docs: GitHub has great guides on branching strategies and workflows.
Work with a team: The real value of Git shows up when you're collaborating. Push your branches, create Pull Requests, review each other's code.
Keep learning: Once you're solid on basics, look into rebasing, squashing commits, and more advanced workflows.

Happy coding. 🎯

My Thoughts on AI Code Agents & Assistance

Gold roger — Mon, 09 Mar 2026 23:40:11 +0000

Let's begain...

AI is powerful no doubt. But here’s something I believe:

Write the code yourself first. Then allow AI to review.

When you write your own logic, you understand your boundaries, your creativity, and your solutions better than anyone else. That’s how you grow. That’s how you build confidence for your next project.

If you rely too early on AI, you might get working code…
but will you understand it?

A Quick Reality Check…
Let’s be real, have developers (you and me) ever coded without help?

Even before AI, we had:

Google
Stack Overflow
Documentation
Books
Personal notes and templates

Personally Google fits my vibe 😁.

Every generation of developers had tools to assist them. AI is just the next evolution.

So yes, AI is here to stay, but that doesn’t mean it should replace our minds.

Your AI Sidekick
The best way to use AI is simple:

You lead
AI assists
You learn
You improve

AI accelerates
Let AI reflect your thinking, your style, your creativity, not the other way around!!

You’re the captain. AI is just your loyal sidekick — not your dad. 😂

My Final Advice?
Just write the code!!

Don’t wait for permission.
Don’t overthink the perfect solution.
Start, then refine with AI.

Because the more you create, the sharper you become.

Why Computer Vision Isn’t the Best Choice for Control Systems

Gold roger — Wed, 19 Nov 2025 21:10:22 +0000

I truly believe computer-vision powered control systems are inefficient.

Listen to me…

Computer vision takes more compute power than necessary in the sense that it does more work just to get something simple done. Like imagine I just want to “click” a button. It sounds futuristic and cool, but the world of engineering is not about “cool”, it’s about efficiency. It’s about the cleanest, most reliable, most deterministic way to get something done.

But CV?
You need a camera, a processor running at a constant frame rate, and then a full CV model sitting on top. And these models are heavy — even the optimized ones take more resources than something like a simple switch, an IR sensor, or a muscle-signal reader. That’s the truth. Research literally shows vision models often burn orders of magnitude more energy than basic sensors, even when compressed or run on microcontrollers.

And then we want to make this whole stack the “OS” of the system?
As in… the foundation we’re supposed to trust?

The moment you make CV dynamic, you’re telling the model to deal with noise — light changes, shadows, random movement in the background, mistakes where the model thinks your hand is a command you didn’t mean, etc. Even industry papers emphasize how camera-based gesture systems get false positives in messy environments. And a control layer that triggers stuff you didn’t intend is the fastest way to create a very unreliable system.

An OS should be accurate more often than not.
You should feel safe that the base system gives the same output every time under the same input. Deterministic. Repeatable. Zero surprises. That’s how engineers design systems that people can build experiments on top of.

CV doesn’t give you that consistency unless you freeze the environment — fixed lighting, fixed angle, fixed setup — and that’s not how normal people use computers.

So for me, CV fits more into monitoring roles, not control roles.

Monitoring = “watch the scene, tell me what’s happening.”
Control = “do something based on my action, immediately and reliably.”

CV excels at monitoring. That’s where it shines. Surveillance, object detection, anomaly spotting, robotics feedback loops — the research literally shows CV thrives when it’s observing and reporting.

But controlling an OS?
Triggering actions like a click or command?
That’s when you really want low-latency, low-noise, low-power sensors that give clean signals.

You might ask: “What about VR?”
Well VR actually proves my point — those systems don’t rely on heavy vision models for basic inputs. They use IMUs, IR markers, muscle sensors (EMG), flex sensors, etc. Even the fancy VR gloves combine simple sensors first and then sprinkle in CV only for extra precision. Because those basic sensors are faster, cleaner, and more reliable for moment-to-moment control.

In simple terms:
Computer vision is amazing… just not for everything.
And trying to make it the primary way we control systems just feels like the wrong engineering choice right now.

Developing and AI

Gold roger — Fri, 07 Nov 2025 14:06:04 +0000

My Thoughts on AI Code Agents & Assistance

Artificial intelligence has evolved quickly, especially in the world of software development. Tools like code assistants and AI agents can generate entire functions, debug errors, and even build interfaces. It’s impressive. It’s helpful. It’s accelerating the way we work.

But I believe the best approach is this:

Write the code yourself first. Then allow AI to review, improve, and enhance it.

When you start by writing your own logic, you build understanding. You strengthen problem-solving. You define your creativity and boundaries as a developer. That foundation is what sets you up for success on future projects.

If you rely on AI too early, there’s a risk:
You might get working code, but you may not understand it — and that slows down growth.

Development Has Always Used Assistance

Some people ask: “Is it still real programming if AI helps?”

Let’s think back. Did developers ever code without any form of assistance?

Even long before AI, we relied on:

Books and manuals

Google searches

Stack Overflow answers

Documentation and cheatsheets

Personal notes and snippets

The truth is: no developer has ever built in isolation.

Tools have always existed to help us learn, recall, and move faster. AI is just the next step in that evolution — more advanced, more accessible, and far more powerful.

The Right Balance

AI should not replace your thinking. It should strengthen it.

The ideal workflow looks like this:

You attempt the solution
You think through the logic
You write the code
Then AI reviews, corrects, and optimizes

This balance gives you:

Ownership over your knowledge

Confidence in debugging your own work

A deeper understanding of what’s happening inside your code

Creativity that isn’t limited by templates or patterns generated by AI

You are the one building your career. AI is a tool to help you build faster — not a shortcut to skip learning.

The Developer’s Role Hasn’t Changed

Code assistants don’t eliminate the need for developers.
They just shift our responsibilities:

From memorizing everything

To understanding concepts

From writing boilerplate

To focusing on architecture and innovation

We gain the freedom to explore, to test ideas, to push boundaries — without getting slowed down by repetitive tasks.

Final Thought

AI can accelerate your productivity, guide your learning, and help you discover stronger solutions. But the true power still lies in your willingness to experiment, to write, and to learn through doing.

So, the advice is simple:

Just write the code!!.
Start with your own logic.
Then let AI become the trusted assistant that sharpens the edges of your craft.

Writing Clean Code Without Losing Your Mind

Gold roger — Sun, 19 Oct 2025 00:36:28 +0000

Writing Clean Code with a Strict Mindset to the Rules

When you’re just starting out as a programmer, it’s easy to get caught up in the hype of writing clean code. Every tutorial, blog, or YouTube video seems to emphasize naming conventions, indentation, comments, and all the other “good practices.”

But here’s the thing — when you’re still learning, that shouldn’t be your main focus.

Focus on Getting the Logic Right First

When I first started writing code, I read tons of articles about how to write clean, maintainable, and scalable code. To be honest, that was one of my early mistakes. I thought writing clean code was the same as writing scalable or optimized code — but it’s not.

I found myself fussing over the little things that didn’t matter at that stage, instead of focusing on solving the problem. Writing clean code is important — it helps you read and fix bugs easily — but your priority as a beginner should be getting the logic down and making your program work first.

If you skip that and just follow every “rule” you read online, you’re not really developing your own style or creativity. You’re just memorizing and repeating — or as I like to call it, “chew and pour.”

Don’t Worry About “Code to Scale” Yet

Another common trap beginners fall into is coding “for scale.” You’ll often hear about software patterns, best practices, or how to design code that can handle thousands of users. But ask yourself — how many people are actually going to use the small project you’re building right now?

When you overthink scalability at the beginner stage, you take away the fun of learning. Bugs can be fun. They teach you how to think, debug, and improve. You can’t learn those lessons if you’re constantly trying to code like a senior engineer.

Reading Optimized Code Isn’t Easy

Optimized code is often hard to read — even for experienced developers. You can have a perfectly working program with solid logic and no bugs, but rewriting it to be optimized is a whole different challenge. It doesn’t just require understanding your own logic — you need to deeply understand the programming language itself.

Optimized code isn’t just better-written code; it’s usually the best out of many possible ways to solve the same problem. That takes experience — and you’ll get there, but only after you’ve built the foundation.

Final Thoughts

So here’s my advice to all beginners:
Stick to one programming language. Focus on how you solve problems. Turn your thoughts into algorithms and build your logic first — then worry about making it cleaner or faster later.

In the long run, this mindset not only makes you a better coder but also helps you truly understand what clean and optimized code means — because you’ve earned that understanding through experience.