Most of my experience comes from personal projects rather than production codebases, but the approach hasn't changed: figure out who the problem actually affects, solve it simply, then clean it up. I try to write code that someone else can read and modify without having to track me down.
{We've probably never met before, so here goes}
hello world, I'm Marq.
Navy vet, ex-sales, now CS. I got here a different way and I’m okay with that.
I spent most of my early career in enterprise tech sales and before that the Navy, getting decently skilled at digesting what people actually need while lacking any ability to build it myself. That gap bugged me enough to return to school. Now, 4 years later, I’m a senior at UC Davis completing my CompSci degree.
Sales taught me that people don’t actually care about bells, whistles, and fancy doodads. Most users want a tool that simplifies their workflow and is easy enough for even their least tech-savvy coworker to pick up in a few days. The extras are nice but they can be hidden. It also taught me how to work with disagreeable people and calmly find a solution that works for everyone, which turns out to be a useful skill whether you’re closing a deal or untangling a messy codebase with a team.
The Navy taught me how to actually debug a problem: Starting by figuring out exactly what the problem is, then working backwards through what changed. Sometimes the issue is that the problem we were trying to solve was too big and needed to be broken into smaller pieces. Other times we were solving problems that didn’t even exist.
I’ve always thought about things in systems. Films, recipes, human psychology, code, it’s all the same process. Break down what you’re solving, understand the rules of that environment, find the edge cases, then solve it simply even if it’s not perfect, and improve from there. When I don't know something, my first instinct is to admit it, my second is to figure it out. That’s just how I think. I came to this later than most but when something is genuinely new for everyone I tend to learn and adapt pretty quick. I care about building things that actually solve problems for people, the kind of stuff that makes someone’s day a little easier. That’s enough for me to feel rewarded.
I care about how AI systems are built more than what they can do. Giving agents direct database access and calling it done is how you get fast, confident data corruption. I'm interested in safe interfaces, scoped permissions, audit trails, the distributed systems discipline applied to AI. Also the longer question: if AI replaces junior engineers, who trains the seniors of 2040?
Actively learning. CI/CD, containerization, Kubernetes. The infrastructure that makes software run in the real world and I want to understand it properly.
Email me for opportunities, collaborations, or to talk creative tech.