About

About This Blog

I’m a professional engineer by training, but the majority of what I know wasn’t taught to me in a classroom. I learned by building things — and by breaking them, and then figuring out why they broke. It’s called life experience.

The kind of engineering that gets measured on a resume — degrees, titles, years of experience — it doesn’t mean much if you can’t deploy something that works. The kind that matters is the kind you build yourself: a server you configured from scratch, an API that handles real traffic, a pipeline that turns code into a live service without someone holding your hand. This blog is about that second kind of learning. The self-taught kind. The kind that doesn’t come from a syllabus but from curiosity, stubbornness, and the willingness to spend three hours debugging something that turns out to be a typo.

Why This Exists

There’s no grand strategy here. No content calendar, no growth hack, no plan to monetize the traffic. This is a place to capture the decisions that felt right at the time and the ones that didn’t, to explore ideas before they crystallize into anything worth publishing elsewhere.

Writing about something is the fastest way to figure out whether you actually understand it. When you can explain a concept clearly to an imaginary reader, you either know it well or you’ve found the gap in your own understanding. Either way, it’s useful. This blog is as much for me as it is for anyone else reading it.

Sometimes it’ll be a step-by-step walkthrough of something I spent three days figuring out. Sometimes it’ll be a deep dive into why a particular architecture decision makes sense (or doesn’t). Sometimes it’ll be a rant about a trend I think everyone else is too polite to question. And sometimes it’ll be nothing more than “here’s what I built this weekend and here’s what went wrong.” No theme, no agenda, just what’s on my mind.

What You’ll Find Here

The topics bounce around because that’s how my attention works. The blog is rooted in practice — what works, what doesn’t, and what was learned in between.

I write about whatever catches my interest — no specialty, no niche, no agenda to master anything in particular. I just follow the things that grab my attention and document what I learn along the way. If I need to look something up to write about it, that’s part of the process. Most of the best posts are written by people who just figured it out yesterday.

How This Works

This blog runs on Hugo, a static site generator. The workflow is about as simple as it gets: build locally, push the static files to Netlify. No database, no backend, no CMS to manage, no CI/CD pipeline to set up. No git hooks, no automation, no surprises.

There’s a good reason for that simplicity. I don’t want the mechanics of publishing to get in the way of the writing. Every extra tool or step between “I have something to say” and “it’s live on the internet” is friction. Minimal tooling means more writing, less tooling. It’s also the kind of setup that reflects the kind of engineering I care about — reliable, simple, and something I can troubleshoot at 2am without needing to call someone else.

A Note on the Name

The title — Mad Blog — isn’t just a name. It’s meant to reflect the kind of thinking that produces results: obsessive, iterative, occasionally reckless but never careless. It’s the kind of mindset that takes a half-formed idea at 2am and spends the next week proving whether it holds water. Engineering is full of people who’ve never broken anything in production, and their post-mortems are always more interesting than their success stories. The “mad” part is the willingness to break things to learn from them, to say “I have no idea why this works” and publish it anyway because someone else might have the same question.

The quote on the homepage — “No fate but what we make” — is about defiance against a predetermined future, but that’s also what building anything is about. There’s no blueprint for what you want to create. No one hands you a finished system. You make it through experiments that work, infrastructure that holds, and the kind of experience you earn by getting your hands dirty. The blog is that process, written down.

What’s Next

Nothing predetermined. I follow what’s interesting, one thing at a time, no schedule. Whatever catches my attention next ends up in this blog, whether it’s a tutorial for something I just set up, a teardown of a tool I tried and regretted, a project log from something I’m building, or just a thought I couldn’t shake off.

If you want to know what I’m currently working on, there’s a Projects page — though it’s under construction, which is to say, so am I.