Coder Legion - Recent posts tagged beginner

A Beginner’s Guide to Git and GitHub: From Installation to Your First Push

Mon, 12 Oct 2026 16:20:10 +0000

Starting my journey in Data Science, Analysis, and AI at LUXDevHQ felt like learning a new language while trying to build a house. One of the most important tools I’ve discovered along the way is Version Control.

In this guide, I’ll walk you through:

Setting up Git Bash
Connecting Git to GitHub
Mastering essential push and pull commands

1. What Is Git and Why Does It Matter?

Git is a Version Control System (VCS). Think of it as a save-point system for your code.

Why is Git important?

⏪ Time Travel – If you break your code, you can roll back to a version that worked.
🤝 Collaboration – Multiple people can work on the same project without overwriting each other’s work.
🧪 Experimentation – You can create branches to try new features without affecting the main project.

2. Setting Up Your Environment

Step A: Install Git Bash

Go to Git and download Git for your OS (I used Windows).
Run the installer.
💡 Pro tip: You can keep the default settings for most options.
After installation, search for Git Bash in your applications. It looks like a terminal window.

Step B: Configure Your Identity

To let GitHub know who is uploading code, configure your global Git settings:

git config --global user.name "Your Name"
git config --global user.email *Emails are not allowed*

3. Secure Your Connection: Setting Up SSH Keys

Using SSH is the professional standard. It’s more secure and saves you from typing your password every time you push code.

Step 1: Generate Your SSH Key

Open Git Bash and enter (replace with your GitHub email):

ssh-keygen -t ed25519 -C *Emails are not allowed*

•File Location: Press Enter to use the default location.
•Passphrase: As a beginner, I left this empty for convenience.

Step 2: Add Key to the SSH Agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Step 3: Add the Public Key to GitHub

1.Copy the key:

cat ~/.ssh/id_ed25519.pub

2.Go to GitHub: Settings → SSH and GPG keys → New SSH Key.

3.Give it a name (e.g., "My Learning Laptop") and paste your key into the "Key" box.

Step 4: Test the Connection

Run:

ssh -T *Emails are not allowed*

Success Check! If you see "Hi [YourUsername]! You've successfully authenticated", you are ready!

4. Navigating and Creating Your Project

Learning to navigate via Git Bash makes you much faster than using a mouse! Use these commands to create your first repository:
•Check Location: pwd (Print Working Directory).
•Go to Desktop: cd Desktop
•Create Folder: mkdir my-first-repo
•Enter Folder: cd my-first-repo

5. Tracking Changes (The Core Workflow)

Before sending code to GitHub, Git needs to "track" it locally. Run these inside your project folder:
1.Initialize Git: git init (Starts tracking the folder).
2.Check Status: git status (See what files Git notices).
3.Add Files: git add . (Stages all changes to be saved).
4.Commit: git commit -m "My first commit" (Creates the "save point").

6. Pushing Code to GitHub

Pushing sends your local save points to the cloud.

Step A: Create the Repository on GitHub.com

1.Log into GitHub, click the + icon → New repository.
2.Name it (e.g., my-first-project) and keep it Public.
3.Important: Leave "Add a README" unchecked to avoid conflicts.
4.Click Create repository.

Step B: Connect and Push

On the GitHub setup page, click SSH and copy the URL. Then run these commands one by one:

git remote add origin *Emails are not allowed*:your-username/repo-name.git
git push -u origin main

7. Pulling Code from GitHub

If you work on a different computer, use Pull to download the latest updates from the cloud:

git pull origin main

📚 Resources to Keep Learning

•Official Git Documentation
•GitHub Skills: Interactive Courses
•Visualizing Git Commands (Game)

Conclusion: Congratulations! You've just set up a professional dev workflow. Git can be tricky at first, but keep practicing and it will become second nature. If you ran into any issues, drop a comment below and let's help each other out!

Understanding Backpropagation with micrograd — Principles, Intuition, and Pitfalls I Ran Into

Thu, 16 Jul 2026 11:48:52 +0000

I had heard about backpropagation many times, but I never really understood how it actually worked. When someone asked me what backpropagation was, all I could say was, "It's how neural networks learn… I guess?"

I'd seen the formulas, I knew the chain rule, but it always felt like there was a wall between me and true understanding.

So I spent two days reading Karpathy's micrograd project source code. It's honestly the best explanation of the core principles of neural networks I've ever come across!
👉 https://github.com/karpathy/micrograd

This post documents what I learned and how I understand it now.

Why This Post

I'd watched plenty of YouTube videos explaining backpropagation, but most of them just said:

Backpropagation is repeatedly applying the chain rule.

That's true, but for a beginner, it's basically saying nothing.
I was used to frameworks where a single line — loss.backward() — got the job done, with no idea what was actually happening under the hood.

The Key Code & What It Does

class Value:
    def __init__(self, data, _child = (), _op = "", label = ""):
        self.data = data
        self._prev = set(_child)
        self._backward = lambda: None
        self.grad = 0.0
        self._op = _op
        self.label = label
    
    def __repr__(self):
        return f"Value(data = {self.data})"

    def __add__(self, other):
        other = other if isinstance(other, Value) else Value(other)
        out = Value(self.data + other.data, (self, other), "+")

       def _backward():
            self.grad += out.grad * 1.0
            other.grad += out.grad * 1.0
        out._backward = _backward
        return out

     def backward(self):

        topo = []
        visited = set()
        def build_topo(v):
            if v not in visited:
                visited.add(v)
                for child in v._prev:
                    build_topo(child)
                topo.append(v)
        self.grad = 1.0
        build_topo(self)

        for node in reversed(topo):
            node._backward()

micrograd also defines __mul__, tanh, __pow__ and other methods — they all work the same way, each attaching a different _backward note. So I'm only showing the core code here.

Try this:
a = Value(1.0)
b = Value(2.0)
n = a + b
L = n.tanh()

You'll get this result:

How It Works

When you write n = a + b, here's what happens:

A new Value instance n is created.
A _backward function is attached to n._backward() but not executed yet.
When backward() is called, it traverses the graph in reverse topological order, executing each node's _backward() one by one.

Things You Should Know

Chain Rule:
∂e/∂a = (∂e/∂c)(∂c/∂a) + (∂e/∂d)(∂d/∂a)

At first I didn't accumulate gradients in _backward() — just assigned them. That led to some serious bugs.

Imagine you write:
a = Value(2.0)
b = a + a

What do you expect?
a.grad = 2, b.grad = 1? Or a.grad = 1, b.grad = 1?

If you run it, you'll find a.grad = 1 — which is completely wrong!

    def __add__(self, other):
    other = other if isinstance(other, Value) else Value(other)
    out = Value(self.data + other.data, (self, other), "+")
    def _backward():
        self.grad = out.grad * 1.0   # self = a, other = a;
        other.grad = out.grad * 1.0  # both set a.grad = 1
    out._backward = _backward
    return out

Here's another example:

Try this:
a = Value(2.0)
b = Value(3.0)
c = a + b
d = a b
e = c d

What are a.grad and b.grad this time?

Clearly, the gradients of a and b got overwritten!
So you MUST accumulate in _backward()!

My Confusion

For a long time I couldn't understand what def _backward() and out._backward = _backward were really doing. Sounds silly, I know.

I kept wondering: when Value c is created, out.grad defaults to 0 — how can it possibly backpropagate to find self.grad and other.grad? (Of course, back then I thought out._backward = _backward would immediately execute the _backward function 😅)

Now I finally get it:

After creating a new Value c, c._backward just stores the _backward function without running it. It only executes when backward() is called, traversing in reverse topological order.

It's a naive question that came from a naive assumption, but I hope it helps other developers who've been stuck on the same thing.

A Thought That Followed

Imagine this:
a = Value(2.0)
b = Value(3.0)
c = Value(2.0)
d = a + b
e = c + d

Do a, b, and c have their _backward executed?

Answer: All three have _backward set to lambda: None (an empty function). When backpropagation reaches them, nothing happens — their gradients have already been accumulated through the upstream path.

What I Gained

After carefully reading through Karpathy's micrograd source code, I was genuinely impressed. I'd never understood the core of backpropagation so intuitively before. Here's what I took away:

I now understand the core mechanism of backpropagation — .backward() is no longer a black box to me.
I finally truly understand what "backpropagation is just repeatedly applying the chain rule" means.
This has kicked off my deep dive into deep learning, and now I can better compare micrograd with PyTorch and modern neural network frameworks.

Closing Thoughts

Thanks for taking the time to read this. I wrote it right after going through the source code, so there may be mistakes in my understanding — corrections are very welcome.

If you're also a beginner in deep learning, feel free to reach out. I'd love to learn together with you.

If you enjoyed this post, don't forget to like, bookmark, comment, and follow! I'll be sharing my learning journey in deep learning, machine learning, backend development, and more from time to time.

Check out my Dev.to: https://dev.to/elysianx138
My GitHub will also track my learning progress: https://github.com/elysianx138

Noughts, Crosses, and Questionable Decisions

Sat, 11 Jul 2026 15:01:49 +0000

I made this Tic-Tac-Toe game when I was 14 and still a beginner programmer. At the time, I did not know much about using advance functions, so the code is not the most efficient and has some repeated parts. I made it to strengthen my coding ability and practise using loops, lists, user input, and basic game logic. It may be simple, but every great programmer starts somewhere.

The Good Stuff™

Interactive two-player Tic-Tac-Toe gameplay
Dynamic board updates after every move
Comprehensive win detection across rows, columns, and diagonals
Turn-based game logic
Built using core Python language features

What Beginner Me Missed

Reduce code duplication by refactoring repeated logic into reusable functions def
Prevent players from selecting board positions that have already been occupied
Provide clearer feedback when an invalid move is entered.
Improve code organisation and maintainability through a more modular structure
Add a replay option to allow multiple games without restarting the program


board = [ " 1 ", " 2 ", " 3 ", " 4 ", " 5 ", " 6 ", " 7 ", " 8 ", " 9 "]

line = "\n------------------"
straight_line = "|"

player_one = "X"
player_two = "O"
current_player = player_one
print(f"{current_player}, it's your turn")

row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "

print(f"\n{row_one}{line}{row_two}{line}{row_three}")
while True:
    play = int(input(f"\n{current_player}, enter your move (1-9): "))
    play -= 1
    if play == 0 :
        board[0] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 1 :
        board[1] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 2 :
        board[2] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 3 :
        board[3] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 4 :
        board[4] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 5 :
        board[5] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 6 :
        board[6] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 7 :
        board[7] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")
    elif play == 8 :
        board[8] = f" {current_player} "
        row_one =  f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two =  f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one , line , row_two , line, row_three)
        if board[0] == board[1] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[3] == board[4] == board[5]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[7] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[3] == board[6]:
            print(f"\n{current_player} wins!")
            break
        if board[1] == board[4] == board[7]:
            print(f"\n{current_player} wins!")
            break
        if board[2] == board[5] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[0] == board[4] == board[8]:
            print(f"\n{current_player} wins!")
            break
        if board[6] == board[4] == board[2]:
            print(f"\n{current_player} wins!")
            break
        if board[0] != " 1 " and board[1] != " 2 " and board[2] != " 3 " and board[3] != " 4 " and board[4] != " 5 " and \
            board[5] != " 6 " and board[6] != " 7 " and board[7] != " 8 " and board[8] != " 9 ":
            print("\nIt's a tie!")
            break
        if current_player == player_one:
            current_player = player_two
            print(f"\n{current_player} , it's your turn")
        else:
            current_player = player_one
            print(f"\n{current_player} , it's your turn")

    else :
        print("\nEnter Valid Number")
        row_one = f" {board[0]} {straight_line}  {board[1]} {straight_line} {board[2]} "
        row_two = f"\n {board[3]} {straight_line}  {board[4]} {straight_line} {board[5]} "
        row_three = f"\n {board[6]} {straight_line}  {board[7]} {straight_line} {board[8]} "
        print(row_one, line, row_two, line, row_three)

What I Wish I'd Known About Binary Search Trees Before Interviews

Mon, 25 May 2026 09:11:56 +0000

Three months of practicing binary search trees on paper. Search procedure memorised. Insertion procedure memorised. Three deletion cases memorised. Then came the onsite. The interviewer drew a tree on the whiteboard, asked for an insertion walkthrough, and the recall worked fine. Then she asked for a deletion of a node with two children, and the freeze lasted almost a full minute before the inorder successor steps came out without any real understanding of why they preserved the ordering. She let the explanation finish, then asked one followup: why does the inorder successor specifically work? There was no answer beyond "because the textbook says so." That was the moment the gap became obvious. The months spent memorising procedures had skipped the part the interview was actually testing.

What changed afterwards:

BST search, insert, and delete are not three procedures. They are the same recursive walk with three different terminal conditions.

The two child deletion case is the one interviewers probe because it is the only case where the invariant has to be explained out loud.

Memorising the inorder successor trick doesn't transfer. Being able to say why the inorder successor specifically works does.

Once the invariant becomes the unit of memory, every operation that preserves it becomes derivable on the spot.

Where the approach was breaking

What had been getting practiced wasn't the data structure. It was a list of procedures the invariant could have handed over for free.

The recall pattern looked like this. Open a BST problem. Recognise it as a BST problem. Try to recall the right procedure for whatever the question asked. Search? Walk down comparing target to current. Insert? Same walk, create a leaf at the bottom. Delete? Three cases, pick the matching one, run the steps. The recall worked fine for problems that matched the textbook exactly. It fell apart the moment the problem deviated, because there was no deeper rule available to derive a new procedure from.

The specific failure on that first interview was treating the two child deletion case as a separate procedure rather than a question about the invariant. The procedure said "find the inorder successor, copy its value, delete the original successor." Those steps executed fine. What didn't execute was the reason behind them, which was the actual signal the interviewer was checking.

The gap is small in concept and load bearing in practice. If you can recite the steps but can't explain why each one preserves the rule, you will lose the thread whenever the interview adds a constraint that doesn't appear in the textbook version. And interviews almost always add a constraint.

What started working differently

After that interview, the practice rebuild was small in shape and large in effect. Instead of "memorise the procedure, then run it," the new approach was "start from the invariant, then derive what has to happen to preserve it." Same problems, same operations, completely different relationship to the material.

The contrast looked like this:

Before (procedure first)	After (invariant first)
Memorise search as a walk down comparing values	Start from `left < node < right` and derive the walk as the consequence
Memorise insert as "find null pointer, create leaf"	Notice that insert is the same walk, only the terminal action changes
Memorise three deletion cases	Ask "what value can sit in this slot without breaking the invariant?"
Recall the inorder successor as a step	Derive the inorder successor as the answer to the slot question
Stall on novel problems	Answer novel problems by reasoning forward from the rule

The shift was to remember fewer things, more carefully. There is exactly one rule for a BST: every node's left subtree contains only smaller values, every right subtree contains only larger values. Every operation either preserves the rule or is incorrect. That framing made the procedures fall out naturally, because the question "what do I do here?" reduced to "what action keeps the rule intact?"

What that looked like on the next problem

A month later came a phone screen at a different company. The interviewer gave a tree with [8, 3, 10, 1, 6, 14] and asked for a search for 6 and then an insertion of 7.

Search started at the root. 6 < 8, so go left to 3. Then 6 > 3, so go right to 6. Found it.

def search(node, target):
    if node is None or node.value == target:
        return node
    if target < node.value:
        return search(node.left, target)
    return search(node.right, target)

Then inserting 7 was the same walk. From the root, 7 < 8, go left. Then 7 > 3, go right to 6. Then 7 > 6, go right again. Right pointer is null. Create node 7 there.

def insert(node, value):
    if node is None:
        return Node(value)
    if value < node.value:
        node.left = insert(node.left, value)
    elif value > node.value:
        node.right = insert(node.right, value)
    return node

What was different this time was the framing said out loud after the code finished. Search and insert are the same recursive walk. Search stops when the value matches or the pointer is null. Insert stops at a null pointer and writes a new leaf there. The walk is what the invariant requires. The terminal action is the only thing that changes between operations. The interviewer asked a few more questions and then moved on. The framing was the part that mattered, not the code.

The same shift made deletion easier too. Instead of three cases, the new mental model was one question: what value can sit in this slot without breaking left < node < right? For a leaf, the answer is no value. Drop the pointer. For a one child node, the answer is the child's value, because the child's subtree already satisfies the invariant against the parent. For a two child node, the answer is the smallest value larger than the deleted node (the inorder successor), which is what the slot requires after deletion. Three procedures collapsed into three answers to the same question.

Why this works (the invariant doing the heavy lifting)

The reason the invariant first framing holds up under interview pressure has a name in learning science: near transfer versus far transfer. Memorising a procedure builds a near transfer skill. The procedure applies to problems that look exactly like the one that got practiced. It doesn't apply to problems that look slightly different, because the procedure is tied to the specific form of the original.

Deriving a procedure from a rule builds a far transfer skill. The rule applies to any problem that respects the rule, regardless of how the form changes. The rule is what generalises. The procedure is what gets generated for the specific case.

BSTs make this concrete because there is exactly one rule and there are dozens of variant problems that ask you to apply it. BST validation. Conversion to sorted array. Conversion to sorted doubly linked list. Range queries. Kth smallest element. Lowest common ancestor in a BST. BST iterator. All derivable from "left subtree smaller, right subtree larger." None easy to memorise as individual procedures, because there are too many of them and they shade into each other.

The inorder successor lesson walks the two child deletion case from the invariant down, which is the framing that most first practice resources skip. The procedure becomes the easy part once the question is framed as "what value belongs in this slot?"

What I'd tell someone in the same spot

If your BST practice is at the point where the procedures feel memorised but the mock interviews aren't going well, the shift to make is to stop quizzing yourself on the steps and start quizzing yourself on the rule.

A practice protocol that worked for the rebuild:

Before solving any BST problem, write the invariant at the top of the page. left < node < right for every node, applied recursively to every subtree. Look at it for ten seconds.
Read the problem and ask: what action does the invariant require here? Not "what procedure do I run." What does the rule say has to happen.
Trace one example by hand on paper, narrating each step as "this preserves the rule because..." If that sentence won't finish, what's running is a memorised procedure, not a derivation from the rule.
Code it up. If the code falls out naturally from the narration, you have it. If a procedure shows up that you can't justify, stop and go back to step 2.

The protocol slows things down at first. Adding a thirty second pause to write the invariant and narrate the reasoning feels expensive under time pressure. The payoff is that the slow practice transfers. When the interview adds a constraint, the procedure that would have been recalled is wrong, but the rule still applies and the new procedure derives in real time.

That gap, between solving a BST problem and recognising why an operation works, is the thing that pushed me to build Codeintuition. Watching engineers grind through hundreds of tree problems without the invariant first framing was the pattern that wouldn't stop showing up. The tree courses now lead with the rule and let the procedures fall out, which is the ordering that would have saved months on the first attempt.

Originally posted on my own blog, a slightly longer version with the inorder traversal proof and the balanced construction algorithm.

What is a data structure that started making sense for you only after you stopped memorising the operations and started re-deriving them from the rule?

Big O Notation: What I Wish I'd Known Before My First Interview

Sat, 23 May 2026 11:29:05 +0000

The Big O table was memorised before the first onsite. Binary search logarithmic, merge sort linearithmic, hash insert constant amortised. All recitable. Then a senior engineer wrote a recursive function on the whiteboard, asked for an analysis, and almost a minute went by trying to match what was on the board to something on the cached table. The function was a naive recursive Fibonacci, seen before, implemented before. The freeze still happened, because nothing about the table told anyone how to count the recursive calls.

What I figured out afterwards

The table is the answer, not the method. Memorising it never builds the ability to derive complexity from code you haven't seen.
The thing the table hides is the counting. How many times the dominant operation runs as a function of input size.
Once four or five derivations have been traced by hand, the shape generalises. Unfamiliar code stops feeling opaque.
Space complexity has the same derivation shape, plus the call stack that's easy to forget.
The drill that actually builds the skill is deriving complexity on problems whose answer you don't already know.

Where the approach was breaking

The Fibonacci moment exposed the gap. The function had been seen. The function had been implemented. What hadn't happened was counting what the recursion actually does.

def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

The interviewer was patient. "How many calls does fib(5) make?" The whiteboard got a tree. fib(5) calls fib(4) and fib(3). fib(4) calls fib(3) and fib(2). fib(3) shows up twice. fib(2) shows up three times. The tree grew faster than the page it was being drawn on. The answer wasn't in cached memory because no one had asked for the count before. The answer is O(2ⁿ), roughly, and the reason is that each call branches into two and the depth is about n.

Big O had been treated as a label to attach after solving. The interview was treating it as a derivation to perform on unfamiliar code. Those are different skills, and the wrong one had been practiced.

What started working differently

The fix wasn't reading more articles. It was changing the drill. The new prompt was "given this code you haven't seen before, what's the complexity, and how would you justify it" instead of "what's the complexity of merge sort." Once the prompt changed, the way unfamiliar code reads changed with it.

Here's the shape that worked, side by side with the old habit:

Then	Now
Match the code to a memorised complexity.	Identify the dominant operation, the one that runs most.
Look up the answer when the match wasn't obvious.	Count how many times that operation runs, as a function of `n`.
Move on once a label was attached.	Sum the work across levels (loops, recursion depth, branching factor).
Forget about space until reminded.	Track space the same way: auxiliary memory plus the call stack.

The change is a habit, not a piece of knowledge. The Big O table doesn't get more correct over time. The way unfamiliar code gets read does.

What that looked like on the next problem

A few weeks after the Fibonacci interview, the same function came back out for re-derivation from scratch. No looking up the answer. Just the dominant operation and counting.

The dominant operation in fib(n) is the recursive call. fib(n) calls fib(n-1) and fib(n-2). Treat both as roughly fib(n-1) for the upper bound. So the call count T(n) ≈ 2 × T(n-1). That recurrence solves to T(n) = 2ⁿ. The depth of the tree is about n. The branching factor is 2. Total work is roughly the number of nodes in a binary tree of depth n, which is 2ⁿ.

That's why naive Fibonacci is unusably slow even at moderate n. fib(40) makes more than a billion calls.

Adding memoisation changes the shape entirely:

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n < 2:
        return n
    memo[n] = fib(n - 1, memo) + fib(n - 2, memo)
    return memo[n]

Now each subproblem fib(k) for k from 0 to n is computed exactly once. There are n distinct subproblems. Each one does constant work after its two subcalls return. Total: O(n) time, O(n) space from the memo plus the call stack.

The complexity went from O(2ⁿ) to O(n) because the structure of the work changed, and the derivation made that visible in a way the table never did. (For the longer walkthrough of how memoisation becomes the gateway to dynamic programming, the DP interview blog covers the recurrence-to-table-to-bottom-up progression.)

Why this works (the science behind it)

The learning science term for the swapped drill is elaborative interrogation. Asking yourself why each operation contributes the work it does, rather than accepting the labelled answer at face value. The literature on it is consistent: forcing yourself to construct the reason produces a more durable, more transferable understanding than reading the reason already constructed.

The other piece is near transfer versus far transfer. The old drill was near transfer practice (the same complexity question on the same code already memorised). The interview was a far transfer test (different code, same skill). Near transfer practice doesn't reliably move far transfer scores. Once that lands, the right drill picks itself: derive complexity on code you haven't seen.

What to tell someone in the same spot

Three things, in the order they mattered.

Stop quizzing yourself on named algorithms. "What's the complexity of merge sort" trains memory, not derivation. Quiz yourself on an unfamiliar function instead, and force yourself to count the dominant operation explicitly. If you have to count it out loud, that's the right intensity.
Trace at least one recursive call tree by hand per week. The first few feel slow. The fifth or sixth is where the shape generalises. Branching factor times depth gives nodes, nodes times work-per-node gives total work. The arithmetic is the same on every problem.
Track space the same way you track time. Auxiliary memory plus call-stack frames. Most engineers in interviews get time right and space wrong, and the difference is purely habit.

Before this shift, a solution would read as that looks fast and the analysis would stop there. After, the same solution reads as O(n log n) because the divide step and the merge step can be pointed at independently. Adding a hash map to a nested loop visibly drops the complexity from quadratic to linear, with the derivation right there in the code. Unfamiliar code becomes analysable because the analysis is something you do, not something you recall.

Originally posted on my own blog, with the amortised analysis derivation for hash-map resize and the space-complexity traps skipped over in this retrospective.

What's a piece of complexity analysis that finally clicked for you only after deriving it by hand, where the textbook label had never really stuck?

Bash exit codes 0-255: what they mean and how to write the handler

Wed, 06 May 2026 22:27:13 +0000

`$?` holds the exit code of the last command that ran. You've seen it. You've probably checked it. What you might not have is a reliable reference for what each value actually means — and more importantly, what to do about it in your script.

Here's the most common codes with the detail that's usually missing from quick-reference tables.

0 — Success

The command exited cleanly. Zero is the only value that means success. Everything else is some form of failure or interruption.

1 — General error

This is the catch-all. A lot of programs use 1 to signal "something went wrong but I'm not going to be more specific." When you see 1, you need to look at the command's own output or error messages to find out what actually failed.

2 — Misuse of shell built-in

You called a bash built-in with wrong arguments. Common cause: `if [ $var = ]` with a missing right-hand operand. The `[` command exits 2 when the syntax is wrong.

126 — Command found, not executable

The binary exists but can't be run. Most common cause: missing execute permission. Fix: `chmod +x yourscript.sh`. Worth noting: this is different from 127. The system found the file — it just can't execute it.

127 — Command not found

The binary doesn't exist or isn't in PATH. Most common causes: typo in command name, package not installed, or PATH issue in cron (see the cron job post above). When you see 127 in a cron job context, check PATH first.

130 — Killed with Ctrl-C (SIGINT)

The formula is 128 + signal number. SIGINT = signal 2. 128 + 2 = 130. If your script sees 130 from a subprocess, someone hit Ctrl-C (or the process received SIGINT programmatically).

137 — Killed with SIGKILL

128 + 9 (SIGKILL). This is the OOM killer. When Linux runs out of memory and needs to reclaim it fast, SIGKILL is what it uses. If your script exits 137 unexpectedly on a server, check available memory — `free -h` and `dmesg | grep -i kill`.

139 — Segmentation fault

The process tried to access memory it wasn't allowed to access. In a bash context, this usually means a compiled binary your script called has a bug. You're not going to fix the segfault from bash — but you can detect it and handle it cleanly.

143 — Killed with SIGTERM

128 + 15 (SIGTERM). This is the polite kill — what `kill PID` sends by default, and what systemd sends when stopping a service. Unlike SIGKILL, SIGTERM can be caught and handled.

The error handler problem

Knowing what a code means is step one. Writing a handler that does something useful with it is step two. Most bash error handling I see in the wild looks like this:

if [ $? -ne 0 ]; then
  echo "error"
  exit 1
fi

Which logs nothing meaningful and loses the original exit code. A better pattern:

if [ $? -eq 127 ]; then
  echo "ERROR: command not found — check PATH or installation" >&2
  exit 127
fi

Log to stderr, preserve the original exit code, be explicit about what went wrong.

Free tool that generates these handlers

I built [Bash Exit Code Lookup][(https://bashsnippets.xyz/tools/bash-exit-code-lookup.html)]1 to remove the "Google it, then write the handler by hand" step. You type a code (or click one of the common ones), pick a handler style — if/else block, case statement, or inline `||` fallback — and copy the generated handler directly into your script.

→ https://bashsnippets.xyz/tools/bash-exit-code-lookup.html

The Ultimate Guide: Installing Ollama on Fedora 43

Tue, 31 Mar 2026 04:49:25 +0000

Running large language models (LLMs) locally isn’t just for the privacy-obsessed anymore—it’s for anyone who wants a snappy, custom coding assistant without a monthly subscription. If you’re rocking Fedora 43, you’re already using one of the most cutting-edge distros out there.

Here is how to get Ollama up and running with full NVIDIA acceleration and hook it into VS Code for a seamless dev experience.

There’s something uniquely satisfying about seeing your GPU fans spin up because your local AI is thinking. Let’s get you there in eight steps.

Step 1: Open the Gates (RPM Fusion)

Fedora is known for its commitment to free, open-source software, which means the proprietary NVIDIA drivers aren't there by default. We need to add the RPM Fusion repositories to get the "non-free" goodies.

Run this in your terminal:

sudo dnf5 install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm 
sudo dnf5 install https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Note: We’re using dnf5 here, which is the faster, shinier version of the package manager standard in Fedora 43.

Step 2: The Driver Dance

Now, we install the NVIDIA drivers and the CUDA toolkit. This is what allows Ollama to talk to your GPU instead of making your CPU do all the heavy lifting.

sudo dnf5 install akmod-nvidia xorg-x11-drv-nvidia-cuda

A word of caution: Fedora moves fast. Sometimes, when the kernel updates, the NVIDIA modules need a moment to "catch up" (rebuild). If you update your system and things look wonky, it’s usually because the driver is still compiling in the background.

Step 3: The Classic Reboot

You know the drill. For the kernel to start using those new NVIDIA drivers, you need a fresh start. sudo reboot

Step 4: The Moment of Truth

Once you’re back in, let’s make sure Fedora and your GPU are on speaking terms. Run this command,

nvidia-smi

If you see a table showing your GPU name and VRAM usage, congratulations—you’ve passed the hardest part.

Step 5: Installing Ollama

Ollama makes installation incredibly easy with a one-liner script. This script handles the heavy lifting: it downloads the binary, creates an ollama user/group, and sets up a systemd service so it starts automatically.

curl -fsSL https://ollama.com/install.sh | sh

Step 6: Verifying the GPU Link

Just because Ollama is installed doesn't mean it’s using your GPU. It might be falling back to your CPU if it can't find the drivers. Let's check the logs:

journalctl -u ollama -b | grep "NVIDIA"

You’re looking for a line that confirms an NVIDIA GPU was detected. If you see it, you're golden.

Step 7: Your First Local Run

Let's test it with a lightweight, high-performance model. Qwen 2.5 Coder (0.5B version) is tiny but surprisingly "smart" for its size, making it perfect for a quick test.

ollama run qwen2.5-coder:0.5b

Once it downloads, you can chat with it directly in your terminal. Ask it to write a Python script; you'll be impressed by the speed.

Integrating with VS Code (The "Continue" Extension)

Running AI in a terminal is cool, but having it inside your IDE is where the real productivity happens. We’ll use the Continue extension, which is an open-source powerhouse for local AI.

Install the Extension: Search for "Continue" in the VS Code Marketplace and install it.
Configure Local Access: Open the Continue sidebar, click the gear icon (settings), and select your local config file.
Edit the Config: Replace or add the following to your config.yaml (or config.json depending on your version) to point it toward your local Ollama instance:

name: Local Config
version: 1.0.0
schema: v1
models:
  - name: Qwen2.5-Coder 0.5B
    provider: ollama
    model: qwen2.5-coder:0.5b
    apiBase: http://localhost:11434
    roles:
      - chat
      - edit
      - apply
      - autocomplete
      - embed

Final Thoughts

You now have a fully private, incredibly fast AI coding assistant running on your local hardware. No data leaving your machine, no latency issues, and total control.

How to teach yourself coding without losing your mind

Tue, 03 Mar 2026 02:47:54 +0000

Teaching yourself how to code is easier than ever, but it can still feel overwhelming at the start. There are tutorials everywhere, endless opinions online, and about a thousand different “best” ways to learn. The people who actually stick with it usually do a few simple things really well. They focus on solid beginner friendly resources and ignore the noise.

One of the best ways to learn coding on your own is through well made video lessons. Good videos let you watch someone write code from scratch, mess up, fix it, and explain what just happened. That alone can save hours of frustration. Instructors who have spent years teaching beginners know exactly where people get confused, so they slow down when it matters and explain things in plain language. The strongest video courses also push you to code along instead of just sitting back and watching.

Books still matter more than people think. A good programming book gives you structure and depth that videos sometimes skip. Authors who have taught beginners for a long time tend to write like they are sitting next to you, not lecturing from a podium. They explain why things work, not just what to type. When you get stuck or forget something, a solid book becomes the place you go back to again and again.

The real magic happens when you use both videos and books together. Videos help you get comfortable and see the big picture. Books help everything click and stick. A lot of successful learners watch a lesson, try it themselves, then read about the same topic to reinforce it. That back and forth makes learning feel more natural and a lot less stressful.

It also pays to learn from people with real teaching experience. Someone who has guided beginners for years knows how to pace lessons and avoid unnecessary complexity. You can usually spot these instructors by long running courses, well reviewed books, and students who actually go on to build things.

Above all, consistency wins. Coding a little every day with good resources beats cramming once a week. Stick with trusted instructors, practice often, and be patient with yourself. That is how beginners turn into confident programmers.

Troy Tuckett is an author with 20 years of experience helping beginners become great coders.More information here:

CPU - Traditional Version (2)

Tue, 03 Feb 2026 09:10:33 +0000

Continue on how CPU works. As we already know that CPU only knows numbers and calculate number. And So a natural question is "how CPU loops and create condition if the CPU only know how to calculate?".

To put it simply, CPUs have special instructions that allow them to jump between instructions. We can "emulate" loop and condition, for example in my CPU simulation i have this instruction called JZ (jump if zero). As the name suggests, it jumps to another instruction if a certain value is zero.

example:

LOAD A, 1
LOAD B, 1

CMP A, B
JZ exit
STOREM A, 0 ; store value register A to memory
exit:

HALT

At this point, a question appears: "what value does JZ actually check?" we know that exit is just a label on which line it's referring to, not a value. So how does JZ know when to jump, and This is where branching flags come in.

Before JZ instruction, there's called CMP instruction As the name implies is a compare instruction, like example above it compare register A value and register B value.

During this comparison, the CPU updates special internal flags. The most important ones are:

Z (Zero flag): true if the result is zero
N (Negative flag): true if the result is negative

In my simulation, I explicitly store these flags. In real CPUs, these flags are stored in a special register (often called a status register or flags register).

After the calculation for CMP complete the CPU updates the Z and N flags. And when JZ instruction start they will look at Z flag. And if the the Z flag is true (or 1), execute the jump to chosen location.

Same as Loop, like example below

LOAD A, 4
LOAD B, 1
LOAD C, 1

loop:
SUB A, B ; substract A with B
CMP A, C
JZ exit ; if A == C
JMP loop ; not equal than repeat
exit:

HALT

As you see can see above this instruction is the simplest loop where if A is equal to B exit loop.

To create the loop, we need two jump instructions:

JZ for the conditional jump.
JMP for the unconditional jump back to the loop.

If the JZ condition is not satisfied, the CPU moves to the next instruction, which is JMP. Since JMP has no condition, the CPU will always follow it.

In my simulation, the code for CMP looks like this:

// get value from register and substract
int temp = reg.r[inst.operandA] - reg.r[inst.operandB];
// check if zero or negative 
flag.zero = (temp == 0);
flag.negative = (temp < 0);
programCounter++;

The important rule is that the CMP instruction should not store any new value in registers or memory. It only updates the flags.

Of course there is other instruction other than JZ such as:

JG (jump if greater),
JL (jump if less),
JNZ (jump if not zero),

and many others, depending on the CPU design.

So when you see a code like:

int valueA = 2
int valueB = 3

if (valueA == valueB) {
    // do stuff
}

in CPU it basically try to subtract valueA and valueB and if zero condition fulfill (ignoring compiler optimizations).

And from this branching flags alone, there are many possibility you can create in here because from my experience no matter the fancy code is inside are just bunch of condition and loop.

CPU - Traditional Version

Thu, 29 Jan 2026 05:57:40 +0000

I've been building quite a few projects and one of them is this CPU Simulation. I've been in the web world for 4 years, but i still did not understand what CPU is. So in the past week i start to build a small project CPU-Simulation that follow the behavior in the CPU.

Why the sudden interest in CPUs? Curiosity. There was a trigger after reading an article on how CPU work and they the work is quite simple, that got me thinking "hey, i can build that".

Note: This is the article CPU and this one CPU

So, in CPU they have two important component called Control Unit and ALU (Arithmetic Logic Unit). At a high level, they follow a simple idea often described as “fetch and execute.” In more detail, the cycle looks like this:

Control Unit
This Control Unit responsible for fetch instruction from memory and decode the instruction into something ALU can read. by decoding means they translate the instruction into control signal that the ALU can act on.
Arithmetic Logic Unit (ALU)
ALU is responsible for execution the instruction that producing a result and storing the result in register or memory.

So to put it simple it more like fetch -> decode -> execute -> store -> next. That's the whole cycle, the cycle repeat until all instruction is complete.

From this it's tell me that, the computer work in a simple and predictable manner. The CPU does not care what program it given, it only cares whether an instruction is valid and whether it can be executed.

So i did manage to build the simulation using java, and it can be improve later. Here some code Github.

I use web browser to interact with the cpu, the cpu have 4 register index and 100 bytes of memory. But right now i only create small portion on how CPU work.

Here gist code CU & ALU

As you can see from github code the CU or Control Unit have it's own class. The class contain few important part and there is fetch the program convert to stream and decode it, to something that Simulation ALU can read.

  private int resolveInstruction(Operand op) {

    // Convert to Number
    if (op instanceof LabelRef label) {
      Integer addr = labels.get(label.name());

      if (addr == null) {
        throw new IllegalStateException("Unknow Label :" + label.name());
      }

      return addr;
    }

    // Convert to Number
    if (op instanceof HexCode hx) {
      return Integer.decode(hx.value());
    }

    // Convert to Number
    if (op instanceof Immediate imm) {
      return imm.value();
    }

    // Convert to Number
    if (op instanceof RegisterCode rc) {
      return parseRegister(rc.value());
    }

    return 0;
  }

  private Instruction resolver(RawInstruction ins) {
    var instruction = new Instruction();
    instruction.opcode = ins.opcode;
    switch (ins.opcode) {
      case HALT:
        break;
      case JMP:
        instruction.dest = resolveInstruction(ins.dest);
        break;
      case STOREM:
      case LOADM:
        instruction.dest = resolveInstruction(ins.dest);
        instruction.src = resolveInstruction(ins.src);
        break;
      case LOAD:
        instruction.dest = resolveInstruction(ins.dest);
        instruction.src = resolveInstruction(ins.src);
        break;
      case CMP:
      case ADD:
        instruction.dest = resolveInstruction(ins.dest);
        instruction.src = resolveInstruction(ins.src);
        break;
      case JZ:
        instruction.dest = resolveInstruction(ins.dest);
        break;
      case null:
      default:
        break;
    }

    return instruction;
  }

You can see from function called resolver it convert every value into number. Because CPU does not talk other than number.

  void execute(Register reg, Memory mem, ArrayList<Instruction> program) {
    if (programCounter < 0 || programCounter >= program.size()) {
      halted = true;
      fault = CpuFault.INVALID_PC;
      return;
    }

    Instruction inst = program.get(programCounter);

    switch (inst.opcode) {
      case LOAD:
      case STOREM:
      case LOADM:
      case ADD: // register to register
        this.store(inst, reg, mem);
        break;
      case CMP:
        int temp = reg.r[inst.dest] - reg.r[inst.src];
        flag.zero = (temp == 0);
        flag.negative = (temp < 0);
        programCounter++;
        break;
      case JMP:
        programCounter = inst.dest - 1;
        break;
      case JZ:
        if (flag.zero) {
          programCounter = inst.dest - 1;
        } else {
          programCounter++;
        }
        break;
      case HALT:
        halted = true;
        break;
      case null:
      default:
        fault = CpuFault.ILLEGAL_INSTRUCTION;
        halted = true;
    }
  }

  private void store(Instruction inst, Register reg, Memory mem) {
    switch (inst.opcode) {
      case LOADM:
        if (inst.src > mem.ram.length) {
          halted = true;
          fault = CpuFault.INVALID_MEM;
          break;
        }
        reg.r[inst.dest] = mem.ram[inst.src];
        programCounter++;
        break;
      case STOREM:
        if (inst.src > mem.ram.length) {
          halted = true;
          fault = CpuFault.INVALID_MEM;
          break;
        }
        mem.ram[inst.src] = reg.r[inst.dest];
        programCounter++;
        break;
      case ADD:
        int res = reg.r[inst.dest] + reg.r[inst.src];
        reg.r[inst.dest] = res;
        flag.zero = (res == 0);
        flag.negative = (res < 0);
        programCounter++;
        break;
      case LOAD:
        reg.r[inst.dest] = inst.src;
        programCounter++;
        break;
      default:
        break;
    }
  }

And above code block is an important function in ALU Class, which contain execute function where it take the decoded instruction from Control Unit Class and execute it. And of course i add an error handler, the error handler in CPU are quite similar to most program, if there some illegal instruction or incorrect instruction they halted the program from execute. If you ever use a tool like sudo or other linux command it's the same, if it's error stop the program.

And other interesting part is the label tag like loop: or exit:. That label are just for parser to remember what line are they referring to. For example:

LOAD A, 1
LOAD B, 1

loop:
ADD A, B
CMP A, 7
JZ exit
JMP loop

exit:
HALT

above instruction are a simple instruction for loop if value reach zero stop the loop. Equivalent with:


int A = 1
while (A != 7) {
    A += 1
}
return

If i swap the JZ exit with JMP loop it can cause infinite loop.

There are many more modern concepts in CPU design, but for now, I think a traditional CPU model is enough to understand the fundamentals.

How I Discovered I Love Tech as a 26-Year-Old Sous Chef

Tue, 08 Jul 2025 07:22:52 +0000

"At 8 PM, I was plating the second-to-last course of a wine dinner for 70 guests. At 3 AM, I was spinning up virtual machines and tearing apart old laptops."

Intro
I’ve been cooking for as long as I can remember. When real life hit, I jumped straight into the kitchen — and almost never looked back. I tried a few other jobs here and there, but nothing ever really stuck. They paid the bills, sure, but they didn’t interest me.

Cooking, though? I had the skills. I could make decent money doing it, and I loved it — so dealing with the chaos and the long hours felt worth it.

But somewhere in the middle of all that, something shifted.

The Shift
I’d had a few conversations about IT over the years. My father-in-law teaches it and manages one of the server rooms at Promedica Hospital. Naturally, he likes to talk shop. The chats were insightful, but I never thought it was something for me.

By then, I’d built a few gaming PCs for myself, friends, and family. Tinkering was fun. Researching? Even more fun. But that’s where it stopped.

I used to think anything beyond basic setup — like OS knowledge or software deep-dives — was for hardcore enthusiasts. Then I started fixing Windows blue screens and got intrigued.

“Why the hell are we even getting BSODs when we barely use our rigs for anything but games?”

While researching those issues, Linux videos started popping up in my feed. I’d heard the name before, but didn’t know what it was. Curiosity kicked in. I figured I’d dip my toes in a little.

I was wrong. I fell straight down the rabbit hole — and didn’t mind at all.

Curiosity Peaks
At this point, my curiosity was boiling. I wanted to try these tools, break things, fix them, and see what this world was all about.

It started with my wife’s old Lenovo Ideapad. That thing hadn’t booted in years. The last time it did, it took 12 minutes just to reach the login screen — so we tossed it in a tote and forgot it existed.

I swapped the HDD for an SSD, threw on Linux Mint, and... BAM.

It worked. Like, actually worked. It booted to the desktop in 25 seconds. Buttery smooth and snappy compared to before.

“Wait, I made this run again? Okay... terminal, here I come.”

Mint didn’t last long. It was solid, don’t get me wrong, but I realized I was craving more. The dopamine hit. I needed to understand how this stuff worked, not just click around.

My First Server
So I hopped online, did more research, and pulled the trigger on a Dell Optiplex 7040 with an I7 6700 CPU 16GB RAM and a 128GB internal SSD.

To this day im not sure if i could have done better, after the computer showed up not posting properly I got a partial refund from the seller before diving into it to see what was wrong. Replaced the Ram first, and it booted right up!

$25 spent TOTAL! On what was going to be the foundation of my learning getting started in this journey.

I threw a few parts in I had around and ended up with these specs:
Dell Optiplex 7040:

i7 6700 Cpu
32 GB RAM
128 GB m.2 SSD
2 x 1 TB HDDs
Operating System: Windows 10 Pro switched to ProxmoxVE
Enter Proxmox
Proxmox was an absolute blessing. It’s a full-blown virtualization platform that let me spin up Linux distros and operating systems like candy. No need to dual-boot or nuke my daily driver — I could just run whatever I wanted, whenever I wanted.

So what did I do? I downloaded all the things.

Ubuntu, Mint, Fedora, Kali... I didn’t even care if I used them for more than a few minutes — I just wanted to see them all, boot them all, and feel them all.

At this point I was still a total newbie, but Proxmox made it stupid easy. It wasn’t long before I started seeing what other people were using Proxmox for.

That’s when I really started playing:

✅ OpenMediaVault VM → My own little NAS!

✅ Pi-hole VM → Hosted my own ad blocker!

And man, that was fun.

But after a while... I noticed something.

I wasn’t really learning how things worked. I was installing powerful tools, sure, but it felt like I was just following steps — like learning how to use apps more than actually understanding the systems underneath.

So I shifted focus.

I didn’t just want to run cool stuff.
I wanted to know what made it all tick.

Que montage of hours of researching linux and coding, setting up environments and learning how they work, using the terminal for everything i could until i became comfortable.

Where I Am Now
Today, I’m still cooking full-time — long hours, late nights — but something’s changed.
When I clock out, I don’t shut down. I shift gears.

My daily driver is a full Linux rig now — no dual boot, no fallback, just me and Nobara (a Fedora-based distro), handling everything from gaming to system tweaks to writing code. I’ve got my terminal customized, dotfiles synced, Starship prompt glowing — and I finally feel like my setup is mine.

I’ve also got a second laptop running Fedora Workstation, built specifically for coding. Clean, focused, distraction-free. Python, VSCode, and a growing list of projects that are teaching me how things really work under the hood. Every new function, class, or tool I learn gets saved, tested, and turned into something real.

And that old OptiPlex I snagged for $25?
Yeah, I’m still using it — but now it’s running Fedora Server and acting as my self-hosted AI playground. I’ve got Ollama set up, playing with local models, using Docker to manage containers, and testing new tools that feel like straight-up magic. It’s wild how far I’ve come from just wanting to “see what Linux looks like.”

This isn’t just curiosity anymore — it’s becoming craft.
And I’m still just getting started.

Final Thoughts
I'm not trying to sell you a bootcamp or tell you I’ve made it. As much as I hope I can make something out of this, I don't have a timeline. I’m still in the kitchen. Still debugging things I broke. Still learning how to code, how to build, how to think like an engineer.

But now I feel like I belong in this space. What I've learned I've learned forever.

I used to think tech was locked behind a degree or a job title — it’s not.
It's built by people like me. People like you.
People who stay up way too late fixing things just to see if they can.

So if you’ve been curious, start. Break your laptop. Fix it. Google everything.
Spin up your own weird little server.
Customize your terminal until it feels like home.
Build something nobody asked you to build — and keep going.

There’s no finish line.
Just more to learn — and that’s the best part.

I'm a full-time sous chef chasing down a second passion in tech.

Currently learning Linux, Python, and AI self-hosting — one late night at a time.

Let’s connect — I’d love to hear your story too.

Learn All Seaborn Graphs in One Blog (With Code + Output)

Tue, 24 Jun 2025 19:00:45 +0000

Introduction

Have you ever looked at beautiful graphs in data science projects and wondered how do I create them myself? If yes, you're not alone and Seaborn is the perfect tool to help you get started.

Seaborn is a powerful Python library built over Matplotlib that makes it easier to create more informative, cleaner, and visually appealing statistical graphs. Whether you're presenting insights from a dataset, analyzing sales data, or visualizing customer behavior, Seaborn does it all with just a few lines of simple code.

In this easy-to-learn blog, I will walk you through all the important Seaborn charts with code, visuals, and when and where to use these graphs. By the end, you’ll be able to create stunning plots that make your data come alive.

Setting Up Your Environment

Before we dive into the graphs, let’s set up our environment:

# Install seaborn
pip install seaborn

Now, import the necessary libraries:

import seaborn as sns
import matplotlib.pyplot as plt

Loading the dataset:

# View available datasets
sns.get_dataset_names()

This piece of code will provide you with a list of all the datasets present.Some of the datasets present are iris,tips,penguins etc.

We’ll use the tips dataset, which contains information about restaurant tips.

# Load the dataset
df = sns.load_dataset('tips')

# View the first few rows
df.head()

This dataset includes features like total bill amount, tip amount, and customer info like sex, smoker, day, time, size, etc.

Types of Plots in Seaborn

After going through all these graphs, you'll be ready to make clean and stylish graphs in Seaborn.

Function-Level vs. Axes-Level Interface

The two primary plotting interfaces offered by Seaborn are Function-level and Axes-level.Although both are useful for efficiently visualizing data but their structure and degree of control vary.
Example:Lets say we have to plot a scatterplot so if you want to do it using:
Function-level interface: You simply use a generic function like sns.relplot() and specify the type of the plot using the kind parameter.This instructs Seaborn to use the relational plot function to produce a scatter plot

sns.relplot(data=tips, x='total_bill', y='tip', kind='scatter')

Axes-level interface: In this instance, you use the plotting function's name, sns.scatterplot(), to call it directly.This increases your control and makes it possible to integrate with the figure/axis objects in Matplotlib.

sns.scatterplot(data=tips, x="total_bill", y="tip")

Hence the function-level approach is quicker and simpler. Seaborn takes care of setting up the figure and axes, so you don't have to worry about it. Simply call a single function, such as relplot(), and use the kind parameter to specify the type of plot you want. This approach is excellent for beginners or for rapidly exploring your data.
You have more control with the axes-level approach. Before calling the particular Seaborn function, such as scatterplot() or boxplot(), you first create the figure and axes using Matplotlib. Although it requires a little more effort, this is very helpful when you want to alter the layout and design or create multiple plots in a single figure.
So, if you want something quick and simple, use the function-level interface. But if you need more flexibility and want to create detailed or customized plots, the axes-level method is better.
Now that we’ve understood how Seaborn’s interfaces work, let’s explore some of the most commonly used plots. These will help you visualize different types of data — from comparisons to distributions and relationships.

1. Relational Plots

It is used in Seaborn to visualize relationships between two variables i.e. it is used for Bivariate Analysis.The plots under this section are scatter plot and lineplot.

a.(i) Scatter Plot

It is used to visualize the relationship between two numerical variables.

sns.scatterplot(data=tips, x='total_bill', y='tip', hue='sex', style='time', size='size')

Output:

This axes level scatter plot code contains-
data=tips – We specify the dataset we are gonna be using.
x='total_bill' – The values on the x-axis represent the total bill.
y='tip' – The values on the y-axis represent the tip amount.
hue='sex' – Points are colored based on the gender (male/female) of the customer.
style='time' – The shape of each point depends on whether it was lunch or dinner.
size='size' – The size of every point represents the number of individuals at the table.

(ii) Scatter Plot (Function-level)

sns.relplot(data=tips, x='total_bill', y='tip', kind='scatter', hue='sex', style='time', size='size')

Output:

If you notice the difference between these two graphs the function level gives us a kind of a rectangle shaped graph whereas in axes level is square shaped and the details of the graph have shifted to the right.The code is the same just you mention the type of plot and in the kind property you give the name of the graph.You have more control in axes level graphs and hence we will be continuing with it.

b. Line Plot

A line plot is employed in illustrating the relationship between two variables, particularly when one variable signifies a sequence such as time, order, or continuous values. It is used in Trend Analysis,Comparisons,Patterns to identify growth, decline, spikes, or seasonality in data and for Smooth Transitions.

sns.lineplot(data=tips, x="size", y="total_bill")

Output:

2. Distribution Plots

A distribution plot allows you to visualize how your data is distributed. It displays the frequency of values as a histogram, and sometimes includes a smoothed curve to indicate overall shape. This is helpful for identifying patterns, such as whether your data is normally shaped or skewed.The plots under this section are histplot,kdeplot and rugplot.

a. Hist Plot

Shows the distribution of a single numeric variable.Useful for understanding how values are spread out.

sns.histplot(data=tips, x="total_bill", bins=10)

Output:

This piece of code employs Seaborn's histplot() to plot a histogram of the distribution of the total_bill column of the tips dataset.
Data=tips indicates which dataset to use
x="total_bill" indicates the column you would like to graph on the x-axis.

The bins=10 argument indicates that the total bill values will be split into 10 ranges (or bins), and the graph will indicate how many entries are in each range. It serves to enlighten you as to how restaurant bills are distributed — whether most of them are small, high, or somewhere in between.

b. KDE Plot

A KDE plot draws a smooth curve to show how your data is spread out. It’s like a smoother version of a histogram and helps you see the overall shape or pattern in the data more clearly.

sns.kdeplot(data=tips, x="total_bill")

Output:

c. ECDF Plot

An ECDF plot shows how the data accumulates over values. It helps you understand what proportion of values are less than or equal to a certain amount. It is useful for spotting medians, percentiles, and spread.

sns.ecdfplot(data=tips, x="total_bill")

Output:

3. Categorical Plots

They are used when you want to compare values that fall into distinct categories, such as gender, day of week, or product category. These plots show how data is binned together and what each bin does. Seaborn makes it really easy to plot categories like bar plots, box plots, violin plots, and more with functions like catplot(). These are especially useful when working with survey data, customer segments, or anything that falls into distinct groups.The types of plots in this category are barplot,boxplot,violinplot,countplot and swarmplot.

a. Bar Plot

They are used to show average (or other statistics) of a numerical value across categories.You must give both x and y values (category and numeric data).It calculates and plots the mean of the y values for each category in x.

sns.barplot(data=tips, x='day', y='total_bill')

Output:

b. Count Plot

It is used to count how many times each category appears in your data.You only need to give the x (or y) value — just the category.It’s like a bar chart of value counts (similar to value_counts() in pandas).

sns.countplot(data=tips, x='day')

Output:

c. Box Plot

A box plot summarizes the distribution of a numeric variable using five values: minimum, lower quartile (25%), median (50%), upper quartile (75%), and maximum. It also highlights outliers — data points that are unusually high or low.

sns.boxplot(data=tips, x='day', y='total_bill')

Output:

x='day', y='total_bill': For each day, Seaborn shows how the total bills are distributed.
You can clearly see the median line inside the box, the box itself (middle 50% of data), and points outside (outliers).
It’s a powerful tool to detect variation and inconsistency in your data.

d. Violin Plot

The violin plot builds on the box plot and adds a KDE (Kernel Density Estimate) on both sides to show the distribution shape of the data.While a box plot shows the summary, a violin plot shows where the data is concentrated.Each “violin” shows the density of data — wider sections mean more data points. You also get a central line and mini box inside that shows quartiles like a box plot.Great when you want both summary and distribution together.

sns.violinplot(data=tips, x='day', y='total_bill')

Output:

e. Swarm Plot

A swarm plot is like a smarter strip plot ,it adjusts the positions of points so that they don’t overlap and all are visible.It shows each data point clearly, while also giving a good sense of density (how many points are close together) and variation.

sns.swarmplot(data=tips, x='day', y='total_bill')

Output:

4. Matrix Plots

Matrix plot is a chart for visualizing relationships between two numerical variables or showing how multiple variables relate to each other across matrix/grid layout.These diagrams are especially beneficial for Correlation analysis and Pairwise relationships.This type consist of heatmap and clustermap.

a. Heatmap

-The heatmap derives its name from the concept that it is an affinity based fusion of a correlation matrix and the original visibility data. Each cell of the matrix is the pairing of two variables. Darker/lighter hues correspond to higher/low strength of association.

corr = tips.corr(numeric_only=True)
sns.heatmap(corr, annot=True, cmap='coolwarm')
plt.show()

Output:

b. Clustermap

A clustermap is similar to a heatmap, but in addition, it uses clustering algorithms (such as hierarchical clustering) to cluster together similar variables.It reorders rows and columns so that highly correlated variables are positioned close to one another.

corr = tips.corr(numeric_only=True)
sns.clustermap(corr, annot=True, cmap='viridis', figsize=(6, 4))
plt.show()

Output:

Variables that are more correlated (such as total_bill and tip) will be clustered closer on the axes. It helps you identify patterns and automatically arrange your data visually.
sns.clustermap(corr, annot=True, cmap='viridis'): Works just like a heatmap but adds dendrograms (tree diagrams) to show clustering.

The color bar still shows the correlation values.

Great when your dataset has many variables.
figsize=(6, 4) makes the figure 6 inches wide and 4 inches tall.

5. MultiPlots

Plotting several charts in a single figure or layout is known as a multiplot in data visualization. This is very helpful in situations when you wish to compare various visualizations side by side,The same data is being examined from several angles and for dashboards or reports.

a. FacetGrid

The Seaborn library includes the FacetGrid class which helps you display data through multiple plot grids. Through its functionality you can generate multiple plots that organize data according to category levels which reveals variable interactions and condition-based variations.

g = sns.FacetGrid(tips, col="sex", row="time")
g.map(sns.scatterplot, "total_bill", "tip")
plt.show()

Output:

b. Catplot

It is a higher-level function built on FacetGrid that lets you create categorical plots in grids quickly.

sns.catplot(data=tips, x="day", y="total_bill", kind="box", col="sex")
plt.show()

Output:

c. Pairplot

It creates a matrix of scatter plots for all combinations of numerical variables. It's not a FacetGrid but still shows multiple plots in one figure.

sns.pairplot(tips, hue="sex", height=2, aspect=1)
plt.show()

Output:

Conclusion

Thanks so much for stopping by and reading this blog! I hope it gave you a good and straightforward introduction to Seaborn and how to employ its various types of plots and I have only made graphs using axes level you can visit my github repo to explore function level too.

If you're brand new to data visualization or want to enhance your skills, I’m happy you came along for the ride! If you liked this, please do share it, and look out for more beginner-friendly guides like this and if you have any doubts feel free to message me.

View the complete code on GitHub: github.com/Aaryan-Lunis

Happy plotting!

Coder Legion - Recent posts tagged beginner

A Beginner’s Guide to Git and GitHub: From Installation to Your First Push

1. What Is Git and Why Does It Matter?

Why is Git important?

2. Setting Up Your Environment

Step A: Install Git Bash

Step B: Configure Your Identity

3. Secure Your Connection: Setting Up SSH Keys

Step 1: Generate Your SSH Key

Step 2: Add Key to the SSH Agent

Step 3: Add the Public Key to GitHub

Step 4: Test the Connection

4. Navigating and Creating Your Project

5. Tracking Changes (The Core Workflow)

6. Pushing Code to GitHub

Step A: Create the Repository on GitHub.com

Step B: Connect and Push

7. Pulling Code from GitHub

📚 Resources to Keep Learning

Conclusion: Congratulations! You've just set up a professional dev workflow. Git can be tricky at first, but keep practicing and it will become second nature. If you ran into any issues, drop a comment below and let's help each other out!

Understanding Backpropagation with micrograd — Principles, Intuition, and Pitfalls I Ran Into

Why This Post

The Key Code & What It Does

How It Works

Things You Should Know

My Confusion

A Thought That Followed

What I Gained

Closing Thoughts

Noughts, Crosses, and Questionable Decisions

The Good Stuff™

What Beginner Me Missed

What I Wish I'd Known About Binary Search Trees Before Interviews

Where the approach was breaking

What started working differently

What that looked like on the next problem

Why this works (the invariant doing the heavy lifting)

What I'd tell someone in the same spot

Big O Notation: What I Wish I'd Known Before My First Interview

What I figured out afterwards

Where the approach was breaking

What started working differently

What that looked like on the next problem

Why this works (the science behind it)

What to tell someone in the same spot

Bash exit codes 0-255: what they mean and how to write the handler

$? holds the exit code of the last command that ran. You've seen it. You've probably checked it. What you might not have is a reliable reference for what each value actually means — and more importantly, what to do about it in your script.

Here's the most common codes with the detail that's usually missing from quick-reference tables.

The command exited cleanly. Zero is the only value that means success. Everything else is some form of failure or interruption.

This is the catch-all. A lot of programs use 1 to signal "something went wrong but I'm not going to be more specific." When you see 1, you need to look at the command's own output or error messages to find out what actually failed.

You called a bash built-in with wrong arguments. Common cause: if [ $var = ] with a missing right-hand operand. The [ command exits 2 when the syntax is wrong.

The binary exists but can't be run. Most common cause: missing execute permission. Fix: chmod +x yourscript.sh. Worth noting: this is different from 127. The system found the file — it just can't execute it.

The binary doesn't exist or isn't in PATH. Most common causes: typo in command name, package not installed, or PATH issue in cron (see the cron job post above). When you see 127 in a cron job context, check PATH first.

The formula is 128 + signal number. SIGINT = signal 2. 128 + 2 = 130. If your script sees 130 from a subprocess, someone hit Ctrl-C (or the process received SIGINT programmatically).

128 + 9 (SIGKILL). This is the OOM killer. When Linux runs out of memory and needs to reclaim it fast, SIGKILL is what it uses. If your script exits 137 unexpectedly on a server, check available memory — free -h and dmesg | grep -i kill.

The process tried to access memory it wasn't allowed to access. In a bash context, this usually means a compiled binary your script called has a bug. You're not going to fix the segfault from bash — but you can detect it and handle it cleanly.

128 + 15 (SIGTERM). This is the polite kill — what kill PID sends by default, and what systemd sends when stopping a service. Unlike SIGKILL, SIGTERM can be caught and handled.

Knowing what a code means is step one. Writing a handler that does something useful with it is step two. Most bash error handling I see in the wild looks like this:

Which logs nothing meaningful and loses the original exit code. A better pattern:

Log to stderr, preserve the original exit code, be explicit about what went wrong.

Free tool that generates these handlers

All codes 0-255 are in there. Free, no login.

The Ultimate Guide: Installing Ollama on Fedora 43

Step 1: Open the Gates (RPM Fusion)

Step 2: The Driver Dance

Step 3: The Classic Reboot

Step 4: The Moment of Truth

Step 5: Installing Ollama

Step 6: Verifying the GPU Link

Step 7: Your First Local Run

Integrating with VS Code (The "Continue" Extension)

Final Thoughts

How to teach yourself coding without losing your mind

CPU - Traditional Version (2)

CPU - Traditional Version

How I Discovered I Love Tech as a 26-Year-Old Sous Chef

Learn All Seaborn Graphs in One Blog (With Code + Output)

Introduction

Setting Up Your Environment

Types of Plots in Seaborn

`$?` holds the exit code of the last command that ran. You've seen it. You've probably checked it. What you might not have is a reliable reference for what each value actually means — and more importantly, what to do about it in your script.

You called a bash built-in with wrong arguments. Common cause: `if [ $var = ]` with a missing right-hand operand. The `[` command exits 2 when the syntax is wrong.

The binary exists but can't be run. Most common cause: missing execute permission. Fix: `chmod +x yourscript.sh`. Worth noting: this is different from 127. The system found the file — it just can't execute it.

128 + 9 (SIGKILL). This is the OOM killer. When Linux runs out of memory and needs to reclaim it fast, SIGKILL is what it uses. If your script exits 137 unexpectedly on a server, check available memory — `free -h` and `dmesg | grep -i kill`.

128 + 15 (SIGTERM). This is the polite kill — what `kill PID` sends by default, and what systemd sends when stopping a service. Unlike SIGKILL, SIGTERM can be caught and handled.