Succeeded With Errors: Why This Blog Exists

The pipeline ran. The build took 47 seconds. Then it printed exactly this:

Job succeeded with errors.

Not failed. Not skipped. Succeeded with errors. A middle state that shouldn’t theoretically exist but absolutely does in practice: the job finished, something is technically running, but the logs have smoke in them and I’m not entirely sure from which fire.

I stared at it for a second. Then I thought: that is the most accurate summary of most software I have ever worked on. It also describes most of the code I’ve shipped personally. Possibly most of me, if I’m being honest.

So that’s the name.

The Less Glamorous Origin Story

I didn’t grow up planning to be a software engineer. I went to school for electrical engineering, graduated, and got a job doing hardware work, the kind where bugs don’t come with stack traces.

Software kept pulling me in anyway. I started as the technical resource everyone called when software got weird, and quickly spiralled into a full-blown software engineering role.

My dad was a network architect. He never pushed me toward software, but the disposition for systems thinking was always around the house. Software engineering turned that disposition into a profession.

I was the second software engineer at a company that has since grown into a SaaS platform complex enough that “it’s complicated” qualifies as a complete architecture explanation. I’ve been climbing the ladder of scope ever since, finding out that “Software Architect” mostly means I’m the person expected to have opinions about things that don’t exist (yet).

That path, from constraint-heavy embedded work into loosely-coupled distributed systems, shapes how I write here. I came up in environments with real constraints: memory limits, execution ceilings, hardware that would just stop responding if something went wrong. I’m always slightly suspicious of abstractions I didn’t earn by hitting the wall they were built to replace.

Why Write It Down

Honest reason: I forget things. More flattering reason: so do my colleagues, and someone is always going to ask.

Every few weeks I solve something or teach myself something I know will come up again: an Azure behavior that isn’t in the docs, an architecture pattern that only makes sense once I’ve hit it from the wrong direction, something about agentic development that I need to put into actual words before I can know whether I believe it yet.

Writing is how I figure out what I think. Usually that means messy margin notes on whatever notepad is nearby, or countless ill-formatted markdown files scattered across my desktop. Shipping the post forces clarity that private notes never quite do, because someone else will read it and find where I skipped a step.

The Contract

Here’s what this blog is: a personal tech diary. Instructional when I can make it instructional. Honest when being honest is uncomfortable.

Posts will have wrong turns in them. I’ll document the first approach I tried before the one that worked, because the first approach is where most people are when they land on something like this. I’ll say “I don’t know exactly why this worked” when I don’t know, because pretending otherwise helps no one.

The name is the thesis. Most software ships in the succeeded-with-errors state. Most learning happens there too. I’d rather document it honestly than wait until I have a clean story.

The pipeline is green. The logs have some smoke in them.

That’s fine. Let’s go.