Why You Shouldn't Hire Me

Let me be completely honest with you. I'm about to tell you exactly why you shouldn't hire me as a software engineer.

Unless, of course, you actually want software that works.

Look, I get it. You're probably looking for someone who can seamlessly blend into your existing team culture of shipping fast, moving faster, and asking questions never. Someone who won't rock the boat. Someone who treats "it works on my machine" as a valid deployment strategy.

That's not me. And here's why you should probably keep scrolling past my resume.

I Write Hand-Artisanal Code

While your other candidates are churning out code like a factory farm produces chicken nuggets, I'm over here hand-crafting each function like the fate of the multiverse depends on it.

I know, I know. It's 2026. We're supposed to be using AI to generate code faster than we can say "technical debt." But here I am, actually thinking about variable names. Writing comments that explain not just what the code does, but why it exists. Structuring things so that when some poor soul opens this file at 2 AM in three years, they don't immediately start updating their LinkedIn profile.

My code comes with a warning label: May actually be readable by humans. It might even, brace yourself, stand the test of time.

Now, I understand this is deeply suspicious in an industry where "legacy code" means "anything written last quarter." But I can't help myself. I was raised to believe that code should be a love letter to your future self, not a passive-aggressive sticky note that just says "good luck lol."

I have strong opinions

Here's the thing that really makes me unemployable: software has become terrible in recent years, and I aim to rectify that one line of code at a time.

Remember when apps didn't require 8GB of RAM just to display a to-do list? Remember when updates actually fixed things instead of breaking three unrelated features? Remember when software loaded in less time than it takes to brew coffee?

I do. And I can't forget it.

I'm on a personal crusade to make software that doesn't suck. Is this quixotic? Absolutely. Is it marketable? Questionable. Will I bore you at the team lunch with rants about how Slack shouldn't use more memory than Photoshop? Definitely.

If I can only make one piece of software great and bug-free, like they used to do back in the 90s when Netscape Navigator was considered cutting-edge technology and software shipped on physical disks so you had to get it right, it won't be curing cancer, It probably won't even be that interesting. But I'd rest knowing I made a difference to the world. Somewhere, someone will open an application I worked on, it will launch in under two seconds, and they will experience a brief moment of joy in our dystopian hellscape of spinning loading wheels.

This makes me dangerously passionate about my work. I might actually suggest we fix bugs instead of marking them as "won't fix" or "works as intended." I could potentially recommend we spend an extra day making something robust instead of shipping it and dealing with the consequences when it inevitably crashes in production during the Super Bowl.

Revolutionary, I know.

I'm Actually Competent (In This Economy?)

Now that everyone is chasing abstraction layers like they're Pokémon cards, I've become that weird person who's actually competent at the fundamentals.

I learned to code before "vibe coding" was a thing. Before you could just describe what you wanted to ChatGPT and pray. I actually understand what's happening beneath the seventeen layers of frameworks, abstractions, and middleware that modern development has become.

Can I write a for-loop without Googling the syntax? Yes, and I'm not afraid to admit it.

Do I know what a pointer is? Disturbingly, yes.

Can I debug an issue without immediately opening a new tab to ask an AI what's wrong? I mean, I'll eventually ask the AI, but I'll at least try to figure it out first like some kind of cave person.

I realize this makes me sound like I'm a thousand years old and about to start a sentence with "back in my day." But here's the truth: understanding the fundamentals means I actually know why something isn't working, not just that it isn't working. It means when someone suggests adding another framework to our already-tottering Jenga tower of dependencies, I might, and I'm sorry in advance, ask if we really need it.

I know. Awkward.

I Believe In Testing (The Audacity)

I write tests. Not because someone makes me. Not because it's in the ticket. But because I have this wild idea that code should do what we think it does.

Automated tests. Unit tests. Integration tests. The whole embarrassing suite.

"But the code is self-documenting!" you cry. Cool. The tests are self-validating. We can both be right.

I Actually Read Documentation

For fun. I know that makes me sound like a serial killer, but it's true.

I read release notes. I peruse changelogs. I have opinions about semantic versioning. When a library updates, I don't just blindly upgrade and hope for the best—I actually check what changed.

I'm basically a liability at this point.

I Will Actually Clean Up The Vibe Slop Your Team Has Been Churning Out

Let's address the elephant in the room: that codebase you've been building for the last four years.

You know the one. The "we'll clean it up later" one. The "it was a hackathon project that somehow became production" one. The one where every file starts with // TODO: refactor this and ends with // I'm so sorry.

The codebase where half the functions are named doTheThingV2Final_actuallyFinal_USE_THIS_ONE().

I'm not here to judge. Well, okay, I'm a little here to judge. But mostly I'm here to fix it.

Because here's what happened: for the last four years, your team has been vibing. They've been in the flow state. They've been shipping features faster than you can say "technical debt." And bless their hearts, they've created what can only be described as "vibe slop"—code that works (mostly) but reads like it was written by a random word generator having a fever dream.

I get it. Deadlines were tight. The CEO wanted that feature yesterday. "We'll refactor it later" seemed like a reasonable compromise at 11 PM on a Thursday.

But now "later" is here, and that code is still there, lurking in your repository like a cursed artifact that no one wants to touch.

Here's my pitch: I will roll up my sleeves and venture into that haunted codebase. I will decipher the variable names that seem to be inside jokes from 2021. I will untangle the functions that are 800 lines long because "it's all related, technically." I will find out what utilsHelperFinalV3.ts actually does (spoiler: probably way too much).

And then, and this is the dangerous part, I will clean it up.

Not a full rewrite. I'm not a monster. But a steady, methodical campaign of making things better. Extracting functions. Adding types. Writing those tests that everyone agreed were important but nobody had time for. Removing the commented-out code from 2022 that's been sitting there "just in case."

Will this make me popular? Probably not. Will I have to have awkward conversations about why we have three different date formatting utilities? Absolutely. Will someone say "but it works fine, why change it?" every single standup? You bet.

But six months from now, when a new feature takes days instead of weeks because the code is actually maintainable, when bugs stop appearing in "completely unrelated" parts of the system, when new hires don't immediately start looking for new jobs, you'll thank me.

Or you'll fire me. It's really a coin flip.

I Think "Move Fast and Break Things" Should Only Apply to Your Fitness Routine

Look, I appreciate the hustle culture as much as the next anxiety-ridden millennial. But maybe—and hear me out—we could move at a reasonable pace and break fewer things?

I know this makes me sound like a dinosaur. Next I'll be suggesting we have meetings about meetings and require three levels of approval to change a button color. But there's a middle ground between "cowboy coding directly to production" and "six-month approval process for a typo fix."

That middle ground is called "having literally any process at all," and I'm a big fan.

So Here's The Deal

If you've made it this far and you're thinking "this person sounds insufferable," you're probably right. We wouldn't be a good fit.

But if you're tired of software that crashes more often than it runs, if you've ever stayed up at night wondering why a simple app needs permission to access your contacts and your firstborn child, if you've ever whispered to yourself "there has to be a better way"—then maybe, just maybe, my particular brand of insufferable is exactly what you need.

I'm not promising to revolutionize your codebase overnight. I'm not claiming to be a 10x engineer (though I am definitely a 1x engineer, which in this market might actually be impressive). I won't rewrite everything in Rust or suggest we migrate to microservices for your blog.

What I will do is write code that works. Code that's maintainable. Code that won't make the next developer curse your name and mine. Code that might—if we're very lucky—still be running in five years without requiring a full-time archaeologist to maintain it.

I'll make software a little less terrible, one semicolon at a time.

And if that sounds like a problem to you, well, there are plenty of other candidates out there who are perfectly happy shipping fast and apologizing later.

But if you want to build something that actually lasts?

Let's talk. [e-mail]

---

P.S. — Yes, I know semicolons are optional in some languages. That's not the point. The point is I care about the details. See? Already insufferable.