guest@monty.sh:/public$ cat /home/monty/about

Welcome to my personal blog, where I write about computers and operating systems and weird stuff that may or may not fit into the previous two categories.

I’m an avid fan of Tabletop Gaming, RISC-V, and taking things apart with screwdrivers and pry-bars, all of which I’m liable to write quite a lot about on my blog. I have a degree in Software Engineering that I wield for both good (writing useful software) and evil (making computers do strange things). I also enjoy writing short stories, primarily sci-fi, which you can read by clicking the link on the navigation menu above.

All the opinions expressed on this site are mine and mine alone, and do not reflect the opinions of any of my employers past or present.

guest@monty.sh:/public/posts$ f="Magic for Programmers; or, The lost art of Casting Spells with Computers"; "date -r $f -u +"%Y-%m-%d" && cat $f

Recently, I was asked for advice by someone building a personal portfolio website. They wanted to avoid the bloat and rampant monetization of modern CMS platforms (a noble goal!) but their solution was… confusing, to say the least: a Next.js server dynamically pulling data from MongoDB via some custom API translation middleware, all to host a few static images and a Unity game. They were prepared to hemorrhage time and effort learning frameworks they’d never used, convinced that rolling their own full-fledged Web CMS was the only option. When I suggested a static site generator like Hugo or Jekyll, they recoiled. “But I’d have to learn Go or Ruby!” they protested, as if writing a config.yml file was akin to reverse-engineering the Necronomicon.

To be clear, I’m not dismissing modern software frameworks outright — Next.js’s hybrid generation features are excellent for web applications that need them, and React’s ecosystem shines when interactivity is required and time is short. But for a formulaic portfolio website? You’re not just leveraging a framework’s strengths; you’re inheriting its entire taxonomy. Why manually wire up templating engines, hydration logic, and cached contexts in JavaScript when most SSGs bake these concerns into their design? It’s not that you can’t use a flamethrower to light a birthday candle, but why singe your eyebrows when a matchstick suffices? The cognitive and infrastructural overhead adds up, even if the framework itself is “free.”

This isn’t a diatribe about the state of modern web tooling. It’s about the cult of novelty that conflates “modern” with “necessary” and “scalable” with “robust”. We’ve all been there. You see a job posting demanding “serverless experience,” panic, and spend a weekend deploying a Kubernetes cluster to host your TODO app. But when the scaffolding eclipses the structure, you’re no longer an architect, just a janitor sweeping up abstraction leaks.

I learned this the hard way. When I was little, I decided to build an IRC MUCK in Java (the only language I knew at the time, besides Assembly). My mentors — a small online community of programmers who’d all survived the Browser Wars — refused to help until I could explain how TCP handshakes worked, why SQLite was a better fit than rolling my own file parser, and what the hell a firewall was. It was agony! I wanted to code, not read RFCs! But by the time I’d mapped the problem space, the code wrote itself. I didn’t need magic; I needed to know where the pipes were buried.

Today’s developers face a different agony: too much magic, not enough pipes. Bootcamps prioritize learning frameworks over plain HTML, raw JS, simple CSS. Job boards prioritize “AWS experience” over “can explain TLS.” And why not? When your resume gets parsed by an AI trained on keyword bingo, “rebuilt Kubernetes in Rust” sounds better than “read the fucking manual.” But this is how we end up with portfolios hosted on serverless Postgres clusters — a triumph of cargo cult programming.

Now, I’m not saying to abandon frameworks, that’d be silly. Frameworks are very useful, when applied judiciously, for good reason. The fix, as it were, is to peel the stickers off the black boxes. Before you npm install next, write a raw Node server that serves “Hello World” over HTTP. Then ask: What does Next add? Is it routing? Caching? A 300MB node_modules? If the answer is “I don’t know,” you’ve just identified a learning opportunity.

To my IRC friend (replace “IRC” with “Discord” if you’re under 30): your mistake wasn’t choosing Next.js. It was letting Next.js choose the problem for you. A CMS for a portfolio updated quarterly? A custom API to avoid writing three MongoDB queries? This is the digital equivalent of building a nuclear reactor to power a flashlight. If your goal is to learn React’s internals, godspeed! But call it what it is: a learning exercise, not a solution.

Here’s the rub: computers are not magic. They’re layers of logic wrapped in abstraction foil. When your “serverless” function times out, it’s not the cloud gods punishing you — it’s a TCP socket somewhere gasping for SYN-ACK. Debugging isn’t witchcraft; it’s archaeology. The deeper you dig, the fewer surprises there are.

So cast your spells — but know the incantations. Deploy that Next.js app. Use serverless, edge workers, AI-generated commit messages. But when the magic fades (and it will), be ready to get your hands dirty. Read an RFC. Skim the SQLite docs. Host your site on GitHub Pages for free instead of overpaying for a “scalable” VPS.

And if you take nothing else from this rant: the ancient texts are shorter than you think. RFC 9110 (HTTP/1.1) is 15 pages. The SQLite spec is a weekend read. Compare that to Next.js’s docs, which balloon like a necromancer’s spellbook. Fundamentals don’t change; they just wait for you to catch up.

The irony? That Java IRC server I built is long dead. But the HTTP specs I cursed while writing it? They’re still here, lurking beneath every “modern” framework. When it comes time to apply your knowledge, Magic fizzles. Protocols persist. And when your beautifully overengineered Next.js monolith crumbles under the weight of its own abstractions, you’ll thank your past self for learning how DNS works instead of just chanting npm install into the void.