Forem: Moon Light

PowerShell Scripts Every MSP Should Use

Moon Light — Fri, 03 Apr 2026 06:36:22 +0000

If you work in an MSP environment, you already know the truth:

👉 Repetitive tasks will slowly destroy your soul.

Checking disk space
Monitoring services
Logging into multiple machines
Fixing the same issues again and again

At some point, you realize:

“I’m not being paid to click the same thing 50 times.”

That’s where PowerShell saves you.

But…

After a few “learning experiences” (a.k.a. breaking things in production 😅), I realized:

👉 Automation is powerful… but dangerous.

So here are 5 PowerShell scripts every MSP should use—written in a safe, production-friendly way.

🛠️ 1. Disk Space Check (Prevent Tickets Before They Happen)

This is one of the most common MSP issues.

Instead of waiting for:

“My computer is slow”

You can detect problems early.

```powershell id="disk01"
$computers = @("PC1","PC2","PC3")

foreach ($computer in $computers) {
try {
$disks = Get-CimInstance Win32_LogicalDisk -ComputerName $computer -Filter "DriveType=3"

    foreach ($disk in $disks) {
        $freePercent = [math]::Round(($disk.FreeSpace / $disk.Size) * 100, 2)

        if ($freePercent -lt 20) {
            Write-Output "$computer - Low disk space on $($disk.DeviceID): $freePercent%"
        }
    }
}
catch {
    Write-Output "Failed to check $computer"
}

}




👉 **Why this matters:**
You fix issues *before* users notice.

---

# 🔄 2. Safe Restart Script (No More Accidental Chaos)

Let’s be honest…

👉 We’ve all restarted the wrong machine at least once.

Here’s a safer version:



```powershell id="restart01"
$computers = @("PC1","PC2")

foreach ($computer in $computers) {
    if (Test-Connection -ComputerName $computer -Count 1 -Quiet) {
        Restart-Computer -ComputerName $computer -WhatIf
    } else {
        Write-Output "$computer is offline"
    }
}

👉 Key feature: -WhatIf
This shows what would happen without actually doing it.

🧠 3. Service Health Check (Catch Hidden Problems)

Some services fail silently.

This script helps you detect them quickly:

```powershell id="service01"
$services = @("Spooler","W32Time")

foreach ($service in $services) {
$status = Get-Service -Name $service

if ($status.Status -ne "Running") {
    Write-Output "$service is NOT running"
}

}




👉 **Upgrade idea:** Automatically restart failed services (carefully!)

---

# 🔐 4. Local Admin Audit (Security Must-Have)

This is huge for cybersecurity.

You should always know:

👉 **Who has admin access?**



```powershell id="admin01"
$admins = Get-LocalGroupMember -Group "Administrators"

foreach ($admin in $admins) {
    Write-Output $admin.Name
}

👉 Why this matters:
Unauthorized access = major security risk

📋 5. Script Logging (The Thing Everyone Skips 😅)

This is not optional.

Seriously.

```powershell id="log01"
Start-Transcript -Path "C:\Logs\msp_script.log"

Write-Output "Script started..."

Your script here

Write-Output "Script completed."

Stop-Transcript




👉 **Why this matters:**

* Debug faster
* Track actions
* Prove what happened

---

# ⚠️ The Most Important Rule

All these scripts are useful.

But the real difference is:

👉 **How you run them**

---

## 🧠 My Safety Checklist (Always Follow This)

Before running any script:

* Use `-WhatIf` whenever possible
* Test on ONE machine first
* Check permissions
* Add logging
* Assume something will fail

---

# 😂 Real Talk

PowerShell doesn’t make mistakes.

👉 **We do.**

PowerShell just executes our bad ideas… very efficiently.

---

# 🚀 Final Thought

If you use these scripts correctly:

* You save hours
* You reduce errors
* You look like a hero

If you use them incorrectly:

👉 You create a story for your next blog post 😅

---

# 👇 Your turn

* What’s your go-to PowerShell script?
* Ever automated something that went… very wrong?

Let’s share 👇

# I Accidentally Rebooted Every Client Machine at 2PM (And Watched Chaos Unfold)

Moon Light — Thu, 02 Apr 2026 21:06:28 +0000

There are mistakes.

There are bad mistakes.

And then there are:

👉 “Career-defining MSP mistakes.”

This is one of those.

😌 The Calm Before the Disaster

It was a normal day.

Tickets were under control.
Clients were quiet.
Nothing was on fire.

Which, in MSP life, usually means:

👉 Something is about to go very wrong.

💡 The “Brilliant” Idea

I had a simple goal:

👉 Reboot a few machines that hadn’t restarted in weeks.

You know the type:

47 days uptime
Weird performance
“Have you tried restarting?” always works

So I thought:

“Let’s automate this with PowerShell. Easy win.”

🧠 The Plan (What I thought I wrote)

Identify machines with high uptime
Reboot only those machines
Do it safely
Look like a hero

😎 The Script (What I actually wrote)

```powershell id="oops01"
$computers = Get-ADComputer -Filter *

foreach ($computer in $computers) {
Restart-Computer -ComputerName $computer.Name -Force
}




Yes.

No filtering.

No conditions.

No mercy.

---

## 🖼️ My Brain at That Moment

---

## 🚀 Deployment

I ran the script.

Sat back.

Expected… nothing dramatic.

---

## ☎️ Minute 1: Silence

Everything seemed fine.

I thought:

> “Nice. Clean execution.”

---

## ☎️ Minute 2: The First Message

> “Did our system just reboot?”

Hmm.

Weird.

---

## ☎️ Minute 3: More Messages

* “My computer just restarted??”
* “We lost our work!”
* “Is there an outage?”

---

## ☎️ Minute 5: Full Panic Mode

Slack exploded.

Phones ringing.

Clients confused.

Managers asking questions.

And me?

👉 Staring at my script like it personally betrayed me.

---

## 🖼️ Reality Sets In

---

## 💀 The Realization

I didn’t reboot *a few* machines.

I rebooted:

👉 **ALL. OF. THEM.**

* Active users
* Servers (thankfully not critical ones… barely)
* Machines in the middle of work

Basically:

👉 If it existed… it restarted.

---

## 🤦 The Root Cause (a.k.a. My Brain Failed)

The issue was painfully simple:

👉 I skipped the filtering step.

No uptime check.

No targeting.

Just:

> “Hey PowerShell, restart EVERYTHING.”

And PowerShell said:

👉 “Say less.”

---

## 🛠️ Emergency Response

At this point, there was nothing to stop.

The damage was already done.

So I switched to:

👉 **Damage control mode**

* Apologize internally
* Check critical systems
* Make sure everything comes back online

And most importantly:

👉 Never make this mistake again

---

## 🧠 The Fix (What I SHOULD Have Done)

Here’s the corrected version:



```powershell id="fixreboot01"
$computers = Get-ADComputer -Filter *

foreach ($computer in $computers) {
    $uptime = (Get-Date) - (Get-CimInstance Win32_OperatingSystem -ComputerName $computer.Name).LastBootUpTime

    if ($uptime.Days -gt 14) {
        Restart-Computer -ComputerName $computer.Name -Force -WhatIf
    }
}

🔐 Even Better (Safe Mode)

```powershell id="fixreboot02"
$confirm = $true

if ($confirm) {
Restart-Computer -ComputerName $computer.Name -Force -Confirm
}




---

## 😂 What I Learned (Painfully)

### 1. Never trust yourself at 2PM

That’s peak overconfidence hour

---

### 2. Always use `-WhatIf` first

If you skip this:

👉 You’re gambling

---

### 3. Filtering is NOT optional

“Run on all machines” is rarely the right choice

---

### 4. PowerShell does exactly what you tell it

Not what you *meant*

---

## 🧘 Final Thought

That day, I didn’t just reboot machines.

👉 I rebooted my ego.

Now, every time I write a script, I ask:

> “Would I bet my job on this?”

If the answer is no…

👉 I don’t run it.

---

## 👇 Your turn

* Ever deployed something you instantly regretted?
* Ever taken down more systems than you intended?

Tell me your worst story 😅

The Day My PowerShell Script Took Down a Client (And Taught Me a Lesson I’ll Never Forget)

Moon Light — Thu, 02 Apr 2026 20:41:24 +0000

Every MSP engineer has that moment.

The one where you confidently deploy something…

…and immediately regret your life choices.

This is mine.

😎 The Confidence Phase (A.K.A. “What Could Go Wrong?”)

It started with a simple idea:

👉 “Let’s clean up unused services across all client machines.”

Sounds harmless, right?

I wrote a PowerShell script that:

Identified unnecessary services
Stopped them
Disabled them

Efficient. Clean. Beautiful.

Tested on my machine?

👉 Worked perfectly.

🖼️ The Vision vs Reality

Expectation:
Everything gets optimized. Client loves me. I get promoted. Maybe even a raise.

Reality:
Chaos. Absolute chaos.

🚀 Deployment Time

I pushed the script across multiple client machines.

Sat back.

Took a sip of coffee.

Waited for success messages.

Instead…

☎️ The Calls Start Coming In

“Our system is acting weird.”
“We can’t access some tools.”
“Something just stopped working.”

And my personal favorite:

👉 “Did you guys change something today?”

At that moment, I knew.

👉 I messed up.

🖼️ My Emotional State

🔍 The Investigation

I quickly checked the script logs.

Everything looked… normal.

Which is never a good sign.

Then I dug deeper.

And found it.

💣 The Bug That Caused Everything

My script had a “simple” logic:

```powershell id="fail01"
if ($service.Status -eq "Running") {
Stop-Service $service.Name -Force
Set-Service $service.Name -StartupType Disabled
}




Looks fine, right?

Except for one tiny detail:

👉 I didn’t properly filter *which* services were “safe” to disable.

So the script happily disabled:

* Important system services
* Client-specific services
* Things that should NEVER be touched

Basically:

👉 If it was running… it was gone.

---

## 🤦 The Classic Mistake

I assumed:

> “If I don’t recognize it, it must not be important.”

The system disagreed.

Strongly.

---

## 🛠️ Emergency Fix Mode

Now I had to:

* Identify affected machines
* Re-enable critical services
* Apologize internally (a lot)

And most importantly:

👉 Fix the script properly

---

## 🧠 The Correct Approach (Lesson Learned)

This time, I slowed down.

---

### ✅ 1. Whitelist instead of blacklist

Instead of “disable unknown services”:

👉 I defined **safe-to-disable services only**



```powershell id="fix01"
$safeServices = @("ServiceA", "ServiceB")

foreach ($service in $safeServices) {
    Stop-Service $service -Force
    Set-Service $service -StartupType Disabled
}

✅ 2. Add confirmation logging

```powershell id="fix02"
Write-Output "Disabling service: $service"




Now I could track exactly what happened.

---

### ✅ 3. Add a “dry run” mode (GAME CHANGER)



```powershell id="fix03"
$dryRun = $true

if ($dryRun) {
    Write-Output "Would disable: $service"
} else {
    Stop-Service $service -Force
}

This saved me from future disasters.

✅ 4. Test like a paranoid engineer

Different machines
Different environments
Worst-case scenarios

No more “it works on my machine.”

😂 What I Learned (The Hard Way)

1. PowerShell is powerful… and dangerous

One wrong script = big impact

2. Never trust “simple scripts”

Simple scripts cause complex problems

3. Always test at scale (safely)

One machine ≠ real environment

4. Dry run is your best friend

Seriously. Use it.

🧘 Final Thought

That day was painful.

But it made me better.

Now, before I deploy anything, I ask:

👉 “What’s the worst thing this script could do?”

Because trust me…

👉 It will find a way to do it.

👇 Your turn

Ever broken something in production?
Ever deployed a script you instantly regretted?

Let’s share the pain 😅

🚀 Build a Full-Stack Python Web App (No JS Framework Needed)

Moon Light — Thu, 02 Apr 2026 00:30:35 +0000

Most developers assume you need React, Next.js, or Vue for modern web apps.

But what if you could build a full-stack app using just Python?

In this post, I’ll show you how to build a real web app using Reflex — a framework that lets you create frontend + backend entirely in Python.

🧠 What You’ll Build

We’ll create a simple Task Manager App with:

Add tasks
Delete tasks
Reactive UI (auto updates)
Clean component-based structure

⚙️ Setup

First, install Reflex:

pip install reflex

Create a new project:

reflex init task_app
cd task_app
reflex run

📁 Project Structure (Simplified)

task_app/
├── task_app/
│   ├── state.py
│   ├── pages/
│   │   └── index.py
│   └── components/

🧩 Step 1: Create State (Backend Logic)

import reflex as rx

class State(rx.State):
    tasks: list[str] = []

    def add_task(self, task: str):
        if task:
            self.tasks.append(task)

    def remove_task(self, task: str):
        self.tasks.remove(task)

👉 This is your backend + state management in one place.

🎨 Step 2: Build UI (Frontend in Python)

import reflex as rx
from task_app.state import State

def index():
    return rx.container(
        rx.heading("Task Manager", size="lg"),

        rx.input(
            placeholder="Enter a task...",
            on_blur=State.add_task
        ),

        rx.foreach(
            State.tasks,
            lambda task: rx.hstack(
                rx.text(task),
                rx.button(
                    "Delete",
                    on_click=lambda: State.remove_task(task)
                )
            )
        )
    )

🔥 Step 3: Run the App

reflex run

Open your browser →
You now have a fully working web app 🎉

💡 Why This Is Interesting

🐍 One language (Python) for everything
⚡ Reactive UI without writing JavaScript
🧱 Component-based design
🚀 Faster prototyping for startups

⚠️ When NOT to Use This

Be realistic:

Large-scale frontend apps → still better with React/Next.js
Highly custom UI/animations → JS ecosystem is stronger

🧪 Bonus: Improve the App

Try extending it:

✅ Add persistence (SQLite / Postgres)
🔐 Add authentication
🌐 Deploy it (Railway, Vercel backend, etc.)

🧭 Final Thoughts

Frameworks like Reflex are changing how we think about web development.

For:

indie hackers
MVP builders
AI startup founders

This can be a huge speed advantage.

👇 What do you think?

Would you build a full-stack app using only Python?

Let me know in the comments 👇

# How I Automated My MSP Tasks Using PowerShell (And Saved Hours Every Week)

Moon Light — Tue, 24 Mar 2026 19:30:49 +0000

When I first started working with MSP environments, I thought the hardest part would be technical complexity.

I was wrong.

The hardest part was:

👉 Doing the same boring tasks… over and over again.

Checking system status
Managing users
Running repetitive fixes
Monitoring machines manually

At some point, I realized:

“I’m not doing engineering work… I’m doing copy-paste work.”

And that’s when I turned to PowerShell.

⚡ The Turning Point

One day, after manually checking 20+ machines, I asked myself:

👉 “Why am I doing this manually?”

Everything I was doing:

Followed the same steps
Used the same commands
Produced the same outputs

Which meant:

👉 It was perfect for automation

🧠 What MSP Work Really Needs

In an MSP environment, you don’t just need scripts.

You need scripts that are:

Reliable across multiple machines
Safe to run remotely
Easy to troubleshoot
Consistent in output

Because one small mistake can affect:

👉 Dozens (or hundreds) of endpoints

🔧 My First Useful PowerShell Automation

I started simple:

👉 A script to collect system information from multiple machines.

Instead of logging into each device, I built this:

$computers = @("PC1", "PC2", "PC3")

foreach ($computer in $computers) {
    Write-Output "Checking $computer..."

    try {
        $os = Get-WmiObject -Class Win32_OperatingSystem -ComputerName $computer
        $uptime = (Get-Date) - $os.LastBootUpTime

        [PSCustomObject]@{
            ComputerName = $computer
            LastBoot     = $os.LastBootUpTime
            UptimeDays   = $uptime.Days
        }
    }
    catch {
        Write-Output "Failed to connect to $computer"
    }
}

🤯 Why This Changed Everything

Before:

5–10 minutes per machine
Manual login
Human error

After:

Seconds for all machines
Centralized output
Consistent results

👉 That’s when it clicked.

Automation isn’t just faster.

👉 It’s scalable.

😈 The Problems I Didn’t Expect

Of course… it wasn’t all smooth.

1. Remote access issues

Some machines:

Didn’t allow remote connections
Had firewall restrictions

👉 Result: Script failed randomly

2. Permissions nightmare

Different environments = different permissions

👉 Some commands worked… some didn’t

3. Silent failures (the worst)

Sometimes:

No output
No error
Just… nothing

🛠️ How I Fixed These Issues

This is where things got serious.

✅ 1. Added proper error handling

try {
    # your command
}
catch {
    Write-Output "Error on $computer: $_"
}

Now, instead of guessing:

👉 I knew exactly what failed

✅ 2. Used logging (game changer)

Start-Transcript -Path "C:\Logs\msp_script.log"

# script runs here

Stop-Transcript

Now I had:

Full visibility
Debug history
Proof of execution

✅ 3. Validated connectivity first

if (Test-Connection -ComputerName $computer -Count 1 -Quiet) {
    # proceed
} else {
    Write-Output "$computer is offline"
}

No more wasted time on unreachable machines.

✅ 4. Standardized outputs

Instead of messy text:

👉 I used structured objects (PSCustomObject)

This made it easy to:

Export to CSV
Integrate with dashboards
Analyze results

🚀 Taking It Further

Once I saw the impact, I expanded automation to:

Disk space monitoring
Service health checks
User account audits
Basic remediation scripts

Eventually:

👉 Most repetitive MSP tasks were automated

⚖️ The Real Impact

Let’s be honest.

Automation didn’t just save time.

It changed how I worked:

Less manual effort
Fewer mistakes
Faster response times
More focus on real problems

And the biggest one:

👉 I stopped being reactive… and became proactive

🧠 What I Learned

1. Start simple

You don’t need a perfect script.

You need a working one.

2. Always expect failure

MSP environments are unpredictable.

Plan for it.

3. Logging is not optional

If you don’t log it:

👉 You don’t control it

4. Automation is a multiplier

One script = impact across many systems

🔥 Final Thought

PowerShell didn’t just make my job easier.

👉 It made me better at my job.

Because instead of doing repetitive tasks…

I started solving real problems.

👇 What about you?

Are you still doing manual MSP tasks?
Have you tried automating them with PowerShell?

Let’s share ideas 👇

I Thought My System Was Secure… Until I Found This One Mistake

Moon Light — Fri, 20 Mar 2026 20:43:59 +0000

I used to think my system was secure.

Not “enterprise-grade security team” secure.

But definitely:

👉 “I know what I’m doing” secure.

Strong passwords? ✅
Firewall enabled? ✅
Antivirus installed? ✅

I mean… what could possibly go wrong?

😌 The Confidence Phase

Like many developers, I believed security was something like:

“If nothing bad has happened yet, I must be doing it right.”

And honestly?

For a while… that seemed true.

No breaches.
No alerts.
No weird activity.

Just peaceful ignorance.

🧪 The Curiosity That Started It All

One day, out of pure curiosity, I decided to run a basic security check on my own setup.

Nothing fancy.

Just:

Reviewing open ports

Checking running services

Looking at logs

You know… the stuff we all say we do regularly.

😐 The Moment Everything Changed

That’s when I saw it.

An open port.

Not just any port.

👉 A port that should NOT have been open.

At first, I thought:

“That’s probably nothing.”

(Yes… I was still in denial.)

🔍 Digging Deeper

I checked what was running behind that port.

And there it was:

👉 A service I had installed weeks ago… and completely forgotten about.

No restrictions.
No proper configuration.
Accessible from outside.

Basically:

👉 An open door with a welcome sign.

😳 Why This Was Dangerous

Here’s the scary part:

That service:

Had weak default settings

Was not updated

Didn’t log access properly

Which means:
👉 If someone found it… I wouldn’t even know.

Let that sink in.

🤦 The Real Mistake

The issue wasn’t just the open port.

It was this:

👉 I assumed “installed = secure.”

But in cybersecurity, that’s completely wrong.

Installed means:
👉 Potentially exposed.

🛠️ What I Did Immediately

Panic? A little.

But mostly action.

Here’s what I did:

Closed unnecessary ports

If it didn’t need to be public:

👉 It was shut down.

Removed unused services

If I wasn’t actively using it:

👉 It was gone.

No “maybe later.”

Updated everything

Outdated software is basically an invitation.

So I:

Updated all services

Patched known vulnerabilities

Added proper monitoring

No more blind spots.

Now:

Logs are enabled

Alerts are configured

Changed my mindset

This was the biggest shift.

I stopped thinking:

“Am I secure?”

And started asking:

👉 “What am I missing?”

🧠 What This Taught Me

Security is not a one-time setup

It’s ongoing.

Always.

Forgotten things are the most dangerous

Old scripts. Old services. Old configs.

👉 They don’t disappear—they become risks.

Silence does NOT mean safety

No alerts ≠ no problems

Basic checks go a long way

You don’t need advanced tools to find real issues.

Just awareness.

⚠️ A Simple Checklist (You Should Do This Today)

If you’re reading this, take 10 minutes and check:

What ports are open?

What services are running?

What did you install and forget?

What hasn’t been updated?

You might be surprised.

Or uncomfortable.

Probably both.

🚀 Final Thought

I didn’t get hacked.

But I easily could have been.

And honestly?

👉 That’s worse.

Because it means the only thing protecting me…

was luck.

👇 What about you?

Have you ever found a security issue by accident?

Do you regularly check your own setup?

Let’s talk 👇

Why My Script Only Worked Halfway (And How I Finally Fixed It)

Moon Light — Wed, 18 Mar 2026 17:53:55 +0000

Let me tell you a story about confidence.

Not the good kind.

The dangerous kind.

The kind where you write a script, test it once, see it working… and immediately think:

“Yeah, I’m basically a genius.”

🚀 The Beginning: “It Works!”

I had built what I thought was a beautiful automation script.

Clean logic ✅
No errors (at least… none visible) ✅
Ran perfectly on my machine ✅

I tested it once.

Then twice.

Then I proudly shipped it.

And for a brief, glorious moment, everything worked.

😈 The Problem: “It… kinda works?”

Then the reports started coming in:

“It didn’t run on my machine.”
“Only part of it worked.”
“It stopped halfway.”
“Nothing happened.”

Which is developer language for:

👉 “Your script is broken.”

But here’s the weird part:

It wasn’t completely broken.

It worked…

👉 About 50% of the time.

Which is honestly worse than 0%.

Because now it’s not obviously broken—it’s mysteriously unreliable.

🧠 My First Reaction: Denial

Naturally, I did what any developer would do:

Blamed the environment
Blamed the user
Blamed the machine
Blamed… everything except my code

“It works on my machine” — the most dangerous sentence in software engineering.

🔍 Step 1: Reproducing the Chaos

Eventually, reality forced me to investigate.

I ran the script on:

Different machines
Different user accounts
Different environments

And then I saw it.

The failure.

Not always.

Not consistently.

But just enough to ruin my day.

🧨 The Real Issue: Silent Failures

The script wasn’t crashing.

It wasn’t throwing errors.

It was just… stopping quietly.

No logs.

No warnings.

No explanation.

Just:

👉 “I’m done here. Good luck.”

🕵️ Step 2: Adding Logs Everywhere

So I did what I should’ve done from the start:

I turned my script into a talkative monster.

I added logs to:

Every function
Every condition
Every important step

Suddenly, instead of silence, I had:

“Step 1 complete”
“Step 2 complete”
“Step 3… oh.”

Now I knew exactly where things stopped.

⚠️ The Hidden Bug

Here’s what I found:

A condition that sometimes failed
A dependency that wasn’t always available
A permission issue on certain machines

Individually, these were small.

Together?

👉 Chaos.

🤦 The Mistake That Caused Everything

The real problem wasn’t just one bug.

It was this:

👉 I assumed the environment would always be the same.

It wasn’t.

Not even close.

Different machines had:

Different permissions
Different configurations
Different states

And my script handled exactly one scenario:

👉 The perfect one.

🔧 Step 3: Fixing It (Properly This Time)

This time, I didn’t “patch” the script.

I rebuilt it with defensive thinking:

I handled failures explicitly

Instead of ignoring errors:

I checked results
I added fallback logic
I stopped pretending everything was fine

I validated everything

Before doing anything, I checked:

Permissions
Required files
Environment conditions

I made errors visible

No more silent failures.

If something broke:
👉 It screamed.

I tested like a paranoid person

Different machines
Different users
Worst-case scenarios

Basically, I became my script’s worst enemy.

🎯 The Result

After all that?

The script finally worked.

Not just halfway.

👉 Completely. Consistently. Reliably.

And more importantly:

I actually trusted it.

😂 What I Learned (The Hard Way)

“Works on my machine” means nothing

If it only works for you, it doesn’t work.

Silent failures are evil

No errors = no clues = long debugging nights

Logs are your best friend

Future you will thank past you.

Assume everything will go wrong

Because it will.

🚀 Final Thought

The problem wasn’t that my script was bad.

The problem was:

👉 I trusted it too early.

Now, I trust nothing.

Not even my own code.

Especially not my own code.

👇 Have you been there?

Ever had a script that “kind of” works?
Ever debugged something that made no sense?

Tell me your story—I know I’m not the only one 😅