DEV Community: Christopher Semler

The Chaotic History of "GOTO" (and How I Learned It on an IBM PS/2)

Christopher Semler — Thu, 03 Sep 2026 00:06:48 +0000

Every programming language has that one feature everyone warns you about.
In QBASIC, C, C++, and C#, that feature is goto.

It’s the original source of spaghetti code, infinite loops, debugging nightmares, and childhood trauma. And yes — I learned it the same way many of you did:

On an IBM PS/2 with a 286 CPU, running DOS, with QBASIC baked right in.

This post is a mix of history, nostalgia, and a reminder that sometimes the best way to learn control flow is to break everything.

🧱 C — The Original Chaos Engine (1972)
C introduced goto because early systems programming needed raw, unfiltered control over execution. No exceptions. No structured error handling. Just: jump here, jump there, jump anywhere and try not to crash the kernel

In C, goto is fast, simple, and dangerous. It literally moves the instruction pointer to a labeled location.

This is the birthplace of infinite loops and spaghetti code.
C didn’t discourage it. C basically said:

“Here’s a chainsaw. Don’t cut your leg off.”

Spoiler: everyone cut their leg off.

🧱 C++ — The Sinner With Classes (1985)
C++ inherited goto from C because backward compatibility mattered. But C++ also introduced: exceptions, RAII, ~destructors, and structured control flow

So goto became less necessary and more of a “you probably shouldn’t” tool.

Still valid. Still dangerous. Still used in: kernel code, embedded systems, performance‑critical loops, and error cleanup paths

But in normal C++ code?

“If you see goto, someone is either a genius or a criminal.”

🧱 C# — The Modern Language That Kept It (2002)
C# kept goto for two reasons:

✔️ 1. Switch‑case control
C# doesn’t allow implicit fallthrough like C/C++.
So you can do:

csharp case 1: goto case 3; This is actually legit.

✔️ 2. Label jumps inside methods
C# allows:

csharp START: Console.WriteLine("Menu"); goto START;

But the official vibe is:

“We put it here for completeness. Please don’t use it unless you’re doing something weird.”

It’s rarely used outside: switch navigation, state machines, code generation, intentionally cursed demos, and nostalgia trips

🧱 QBASIC — Learned on an IBM PS/2 Because It Literally Came With It
Here’s the part that matters to me — and maybe to you too.

I learned goto on an IBM PS/2 with a 286 CPU — one of those chunky CRT‑powered machines that booted straight into DOS. The PS/2 came with QBASIC because DOS came with QBASIC, so all you had to do was type QBASIC at the prompt and suddenly you were writing code that should’ve been illegal.

The glow of that CRT, the hum of the power supply, and the clack of the Model M keyboard made every GOTO STARTMENU feel like real magic. QBASIC didn’t teach me good habits, but it taught me how control flow really works — and how to debug spaghetti nightmares decades before I ever touched C#.

This was programming in the wild.
No functions.
No structure.
Just labels, jumps, and pure DOS‑gremlin energy.

🧠 What I Learned From All This

It’s not a keyword I use in real production code — but it’s a keyword that shaped how I think about code.

And honestly?
I’m glad I learned it the messy way.

🔚 Conclusion
goto is one of the oldest, weirdest, most controversial features in programming languages. It’s been around for 50+ years, survived multiple generations of languages, and still exists today — even if most people pretend it doesn’t.

And for many of us, it started on machines like the IBM PS/2.
With a CRT.
With DOS.
With QBASIC.
With a blinking cursor and a dream.

If you’ve got your own goto stories, debugging nightmares, or childhood programming chaos — drop them in the comments. I’d love to read them.

Are AI Auto‑Apply Job Tools Actually Helping Anyone Get Hired? I Want Real Stories.

Christopher Semler — Mon, 31 Aug 2026 03:46:16 +0000

AI job‑application tools are everywhere right now — “auto‑apply to 200 jobs,” “AI‑optimized resume,” “AI cover letters,” “AI job matching,” all of it.

And honestly?
I’m skeptical.

I’m not considering using them.
Two reasons:

They cost money, and usually the things that promise “apply to hundreds of jobs automatically” end up being low‑effort spam.

There’s a heavy marketing push, which usually means “stay away” in tech. If something is good, devs talk about it. If something is bad, companies advertise it aggressively.

But I’m also realistic:
Breaking into the job market efficiently is hard, especially right now. So I’m trying to figure out whether anyone has actually used these AI auto‑apply tools successfully — not hypothetically, not theoretically, not “AI is the future,” but real results.

What I want to know:
Did you use an AI auto‑apply service?

Which one?

Did it send decent applications or garbage?

Did it get you interviews?

Did it get you an actual job?

Was it worth the money?

Would you recommend it or avoid it?

I’m not looking for hype or marketing talk.
I want real experiences from real devs who tried these tools and either:

landed a job

got scammed

wasted money

or found a better method entirely

Why I’m asking
I’m trying to find a better way to break into the job market efficiently — something that actually works, not just burns time or money.

If AI auto‑apply tools are useless, fine.
If they’re secretly effective for some people, I want to hear that too.
If there’s a better strategy entirely, I want to hear that most of all.

If you’ve used one (or found a better method), drop your experience below.
Good, bad, neutral — doesn’t matter.
I just want honest feedback from people who’ve actually been through it.

Visual Studio 2026 Debugger Detection Failure

Christopher Semler — Fri, 14 Aug 2026 03:21:38 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Background

I was building a Coding Activity Tracker to give me realistic timing for how long I actually spend coding — typing, reading, debugging, idle, everything. For that to work, it needed to know when Visual Studio was debugging anything, because breakpoints completely change how an app behaves.

Running the tracker standalone meant it had to detect external debugging sessions.

Debugger.IsAttached only detects debugging of the current process, so standalone mode always reported “no debugger,” even when Visual Studio was actively debugging another project.

That single limitation broke the entire purpose of the tracker.

The tracker had to detect debugging even when it wasn’t the app being debugged.

What Was Tried

Once it became obvious that Debugger.IsAttached was useless for standalone mode, I started trying every simple, reasonable approach that should have worked but didn’t.

Parent‑process tracing

int parentPid = GetParentProcessId(targetProcess);

Fails because Visual Studio doesn’t always launch the debug target. Sometimes the user launches it manually. Sometimes VS attaches to an already‑running process.

WMI queries

var query = new ManagementObjectSearcher("SELECT * FROM Win32_Process WHERE ProcessId = " + pid);

Slow, stale, inconsistent, and occasionally wrong. Not usable in real‑time tracking.

Process‑tree walking

var children = GetChildProcesses(vsProcess.Id);

Visual Studio’s process tree is chaos. Helper processes spawn and die constantly. None reliably indicate debugging.

Handle inspection

var handles = GetProcessHandles(targetProcess);

There is no stable “debugging handle” pattern. Different projects produce different handle sets.

Thread‑freeze detection

bool frozen = targetProcess.Threads.Cast<ProcessThread>() .Any(t => t.ThreadState == ThreadState.Wait);

Breakpoints freeze the debugger, not the tracker. And threads freeze for normal reasons too. Tons of false positives.

CPU sampling

float cpu = GetCpuUsage(targetProcess);

Breakpoints sometimes drop CPU, sometimes don’t. Idle apps already sit at zero. No reliable pattern.

Window‑class correlation

IntPtr hwnd = FindWindow("HwndWrapper", projectName);

Visual Studio creates and destroys windows constantly. No stability.

Tracking devenv.exe child lifecycles

var children = GetChildProcesses(vsProcess.Id);

VS spawns random helper processes for IntelliSense, diagnostics, test runners, service hubs, etc. None of them reliably indicate debugging.

The solution

The solution ended up being stupidly simple compared to all the garbage we tried. Visual Studio always puts the active project name in the window title when it’s debugging. That’s the one reliable external signal we actually get. So the tracker reads the Visual Studio window title, extracts the project name, and then checks if a process with that name is running. If both are true, Visual Studio is debugging.

private bool DetectDebugger()
    {
    // Ignore debugging of CodeActivityTracker itself
    if (Debugger.IsAttached)
        return false;

    // Find Visual Studio
    var vs = Process.GetProcessesByName("devenv").FirstOrDefault();
    if (vs == null)
        return false;

    // Get VS window title
    string title;
    try
        {
        title = vs.MainWindowTitle;
        }
    catch
        {
        return false;
        }

    if (string.IsNullOrWhiteSpace(title))
        return false;

    // Example title:
    // "VoidPulse (Running) - dev_notes.txt - Microsoft Visual Studio"
    // We want: "VoidPulse"

    // Split at " - "
    var parts = title.Split(new[] { " - " }, StringSplitOptions.None);
    if (parts.Length == 0)
        return false;

    string projectPart = parts[0]; // "VoidPulse (Running)"

    // Remove " (Running)" or " (Debugging)" or similar suffixes
    int idx = projectPart.IndexOf(" (");
    if (idx > 0)
        projectPart = projectPart.Substring(0, idx);

    string projectName = projectPart.Trim();

    if (string.IsNullOrWhiteSpace(projectName))
        return false;

    // Now check if the debug target process exists
    // If the project is "VoidPulse", the process is "VoidPulse.exe"
    try
        {
        var debugTargets = Process.GetProcessesByName(projectName);
        return debugTargets.Any();
        }
    catch
        {
        return false;
        }
    }

Summary

After trying every detection trick we could think of — parent‑process tracing, WMI queries, process‑tree walking, handle inspection, thread‑freeze detection, CPU sampling, window‑class correlation, and even tracking devenv child lifecycles — all of them failed for different reasons. They were slow, inconsistent, unreliable, or flat‑out wrong depending on how Visual Studio decided to behave that day.

The only method that consistently worked was the simplest one: read the Visual Studio window title, extract the active project name, and check if the matching process is running. If both line up, Visual Studio is debugging. It’s not fancy, it’s not magical, but it’s stable, predictable, and it actually works in the real world.

That’s the solution the tracker ships with, because it’s the only one that didn’t fall apart the moment Visual Studio did something weird.